From simonp at opera.com  Fri Jul  1 01:26:52 2011
From: simonp at opera.com (Simon Pieters)
Date: Fri, 01 Jul 2011 10:26:52 +0200
Subject: [whatwg] Using footer in blockquote for attribution
In-Reply-To: <BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>
	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
Message-ID: <op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>

On Thu, 30 Jun 2011 22:56:11 +0200, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> On Thu, Jun 30, 2011 at 11:50 AM, Oli Studholme <whatwg.org at boblet.net>  
> wrote:
>> <blockquote>
>>  <p>[block quote]</p>
>>  <footer>? <cite><a href="?">[title of work]</a></cite></footer>
>> </blockquote>
>
> This is incorrect according to the current definition of <footer>.
>
>> Footer definition:
>>  ?The footer element represents a footer for its nearest ancestor
>> sectioning content or sectioning root element. A footer typically
>> contains information about its section such as who wrote it, links to
>> related documents, copyright data, and the like.?
>
> This means it's tied to the nearest <section> or <article> or such.
> It's not supposed to be specifically related to any other type of
> ancestor, like <blockquote>.

<blockquote> is sectioning root.

>> Simon felt that ?Content inside a blockquote must be quoted from
>> another source? excludes footer.

s/footer/attribution/

Indeed since it's a conformance requirement, in valid documents the  
content inside blockquote is quoted from another source. If the spec were  
to allow attribution inside blockquote, the above conformance requirement  
would need to be changed to allow it.


>> However the footer definition reads
>> to me that footer is basically metadata *about* content (the
>> non-footer or -header content of the sectioning or sectioning root
>> element).
>
> Correct, but it's supposed to be metadata about the whole section, not
> about just its parent.
>
> However, I don't know if there's any specific way to mark this up.
> It's a common pattern, so it would be a good candidate for adding
> here:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#common-idioms-without-dedicated-elements
>
> It's useful to be able to put the author info in its own element so
> that you can style it differently.


-- 
Simon Pieters
Opera Software

From acolwell at google.com  Fri Jul  1 07:51:57 2011
From: acolwell at google.com (Aaron Colwell)
Date: Fri, 1 Jul 2011 07:51:57 -0700
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
Message-ID: <CAA0c1bBkbYh1dSbBQUWsRF1ChL_VBRkXfhjnwh72MkMAfTfMGg@mail.gmail.com>

Hi Robert,

comments inline.

On Thu, Jun 30, 2011 at 4:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Jul 1, 2011 at 4:59 AM, Aaron Colwell <acolwell at google.com> wrote:
>
>> I've also been looking at the WebRTC MediaStream API and was wondering if
>> it
>> makes more sense to create an object similar to the LocalMediaStream
>> object.
>> This has the benefits of unifying how media streams are handled
>> independent
>> of whether they come from a camera or a JavaScript based streaming
>> algorithm. This could also enable sending the media stream through a
>> Peer-to-peer connection instead of only allowing a camera as a source.
>> Here
>> is an example of the type of object I'm talking about.
>>
>
> I think MediaStreams should not be dealing with compressed data except as
> an optimization when access to decoded data is not required anywhere in the
> stream pipeline. If you want to do processing of decoded stream data (which
> I do --- see
> http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html),
> then introducing a decoder inside the stream processing graph creates all
> sorts of complications.
>
> Nice spec. If I understand correctly, your position is that MediaStreams
should only represent uncompressed media? In the case of camera/mic data
they represent the uncompressed bits before they go to the codec for
transmission over a PeerConnection or before they are rendered by a
<audio>/<video>. In the case of standard <audio>/<video> playback they would
represent the uncompressed audio before it is sent to the audio card and the
uncompressed video before it is blitted on the screen. From a stream
processing point of view I can see how this makes sense.  I was just
thinking that LocalMediaStream is just a wrapper around a source of media
data and all I was doing was providing a mechanism to provide media data
from JavaScript instead of from hardware.

I think the natural way to support the functionality you're looking for is
> to extend the concept of Blob URLs. Right now you can create a binary Blob,
> mint a URL for it and set that URL as the source for a media element. The
> only extension you need is the ability to append data to the Blob while
> retaining the same URL; you would need to initially mark the Blob as "open"
> to indicate to URL consumers that the data stream has not ended. That
> extension would be useful for all sorts of things because you can use those
> Blob URLs anywhere. An alternative would be to create a new kind of object
> representing an appendable sequence of Blobs and create an API to mint URLs
> for it.
>

> I thought about that, but I saw an earlier WHATWG thread<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032221.html> which
lead me down this MediaStream path. Using MediaStreams made more sense to me
because my use case felt similar to the live capture case except that I'm
using compressed media and it comes from JavaScript instead of hardware.
Also MediaStream already had a way to pass stream URLs to <audio> & <video>
for camera and remote peer stream data so I figured I could just leverage
that.


> Note that with my API proposal above, you can get a MediaStream from a
> media element that's using any URL and send that through a PeerConnection.
>
 I see that. Interactions with PeerConnection were not a primary concern for
me. I was only mentioning it as a side benefit of using MediaStream.

Thanks for your comments. I appreciate them.

Aaron

From acolwell at google.com  Fri Jul  1 07:58:11 2011
From: acolwell at google.com (Aaron Colwell)
Date: Fri, 1 Jul 2011 07:58:11 -0700
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <BANLkTikTj0uOXrDstnoLvfhgWz1jvSqffA@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
	<BANLkTikTj0uOXrDstnoLvfhgWz1jvSqffA@mail.gmail.com>
Message-ID: <CAA0c1bASr+WxTVVKT_kiP94avM-74nSTPuYCm_C43foJgc-gaw@mail.gmail.com>

Hi Adam,

On Thu, Jun 30, 2011 at 5:20 PM, Adam Malcontenti-Wilson <adman.com@
gmail.com> wrote:

> @acolwell:
> Is the appendData method one your suggesting or one already
> specified/existing?
>
> I'm suggesting it. It was a quick and dirty way to try out some ideas I had
while working on a prototype for Chromium. Now that I actually want to take
this out of the prototype stage, I'm trying to get a sense of whether
appendData() or a MediaStream based solution is more desirable.


> @robert:
> Some problems with concept of blobs being appended to, or as I have
> previously described as "Streaming Blobs" was mentioned at
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032221.html
> I'm not exactly sure what that meant - but I'd expect the ideas
> discussed are similar.
>
> I saw this thread as well which is why I went down the MediaStream path.
:)

Aaron

From B.Lund at CableLabs.com  Fri Jul  1 08:40:08 2011
From: B.Lund at CableLabs.com (Bob Lund)
Date: Fri, 1 Jul 2011 09:40:08 -0600
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D030170FBFD@srvxchg>

Hi Aaron,

Here are some other aspects of script controlled adaptive bit rate that occur to me, perhaps you have already considered these.

1) I guess script will be responsible for maintaining its own playback buffer, monitoring buffer behavior and selecting the appropriate bit rate for new fragments. Are there any other network related events/metrics script might need to determine which bit-rate to fetch for the next segment? Is there any other information from the user agent about playback performance that script might need?

2) If a media resource is a multi-track resource then it would seem script will also have to fetch fragments for those tracks which implies that the audio element would need the append method. Timed text tracks would also need to be processed and Cues appended.

There is a new media pipeline task force in the Web and TV IG (http://www.w3.org/2011/webtv/wiki/MPTF) that is also planning to examine this topic. You may want to participate.

Regards,
Bob Lund


> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
> bounces at lists.whatwg.org] On Behalf Of Aaron Colwell
> Sent: Thursday, June 30, 2011 10:59 AM
> To: whatwg at whatwg.org
> Subject: [whatwg] Extending HTML 5 video for adaptive streaming
> 
> Hi,
> 
> I've been working on an adaptive streaming prototype that uses
> JavaScript to fetch chunks of media and feeds them to the video tag for
> decoding. The idea is to let the adaptation algorithm and CDN
> interactions happen in JavaScript so that they can evolve without the
> need for browser changes. I'm looking for some guidance about the
> preferred method for adding this type of functionality. I'm new to this
> process so please bear with me.
> 
> My initial implementation is built around WebM, but I believe this could
> work for Ogg & MP4 as well. The basic idea is to initialize the video
> tag with stream initialization data (ie WebM info & tracks elements) via
> the <video> src attribute and then send media chunks (ie WebM clusters)
> to the tag via a new appendData() method on <video>. Here is a simple
> example of what I'm talking about.
> 
>   <video id="v" autoplay> </video>
>   <script>
>     function needMoreData(e) {
>       e.target.appendData(getNextCluster());
>     }
> 
>     function onSeeking(e) {
>       var video = e.target;
>       video.appendData(findClusterForTime(video.currentTime));
>     }
> 
>     var video = document.getElementById('v');
> 
>     video.addEventListener('loadstart', needMoreData);
>     video.addEventListener('stalled', needMoreData);
>     video.addEventListener('seeking', onSeeking);
> 
>     video.src = URL.createObjectURL(createStreamInitBlob());
>   </script>
> 
> AppendData() expects to recieve a Uint8Array that contains WebM cluster
> elements. The first cluster passed to appendData() initializes the
> starting playback position. Also after a seeking event fires the first
> appendData() updates the current position to the seek point.
> 
> I've also been looking at the WebRTC MediaStream API and was wondering
> if it makes more sense to create an object similar to the
> LocalMediaStream object.
> This has the benefits of unifying how media streams are handled
> independent of whether they come from a camera or a JavaScript based
> streaming algorithm. This could also enable sending the media stream
> through a Peer-to-peer connection instead of only allowing a camera as a
> source. Here is an example of the type of object I'm talking about.
> 
> interface GeneratedMediaStream : MediaStream {
>   void init(in DOMString type, in UInt8Array init_data);
>   void appendData(in DOMString trackId, in UInt8Array data);
>   void endOfStream();
> 
>   readonly attribute MultipleTrackList audioTracks;
>   readonly attribute ExclusiveTrackList videoTracks; };
> 
> type - identifies the type of stream we are generating(ie video/x-webm-
> cluster-stream or video/ogg-page-stream) init_data - Provides
> initialization data that indicates the number of tracks, codec configs,
> etc. (ie WebM info & tracks elements or Ogg header
> 
> pages)
> trackId - Indicates what track the data is for. If this is an empty
> string than multiplexed data is being passed in. If not empty trackId
> matches an id of a track in the TrackList objects.
> data - media data chunk (ie WebM cluster or Ogg page). Data is expected
> to have monotonically increasing timestamps, no gaps, etc.
> 
> Here are my questions:
> - Is there a preference for appendData() vs new MediaStream object?
> - If the MediaStream object is preferred, should this be constructed
> through Navigator.getUserMedia()? I'm unclear about what the criteria is
> for adding this to Navigator vs allowing direct object construction.
> - Are there existing efforts along these lines? If so, please point me
> to them.
> 
> Thanks for your help,
> 
> Aaron

From Simetrical+w3c at gmail.com  Fri Jul  1 10:30:39 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 1 Jul 2011 13:30:39 -0400
Subject: [whatwg] Using footer in blockquote for attribution
In-Reply-To: <op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>
	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
	<op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
Message-ID: <BANLkTimub7c-zdQW06oqR02FVNuRJs_mCg@mail.gmail.com>

On Fri, Jul 1, 2011 at 4:26 AM, Simon Pieters <simonp at opera.com> wrote:
> <blockquote> is sectioning root.

Oops.  I stand corrected, never mind me.

From acolwell at google.com  Fri Jul  1 12:06:47 2011
From: acolwell at google.com (Aaron Colwell)
Date: Fri, 1 Jul 2011 12:06:47 -0700
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D030170FBFD@srvxchg>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<114DAD31379DFA438C0A2E39B3B8AF5D030170FBFD@srvxchg>
Message-ID: <CAA0c1bDBZo2Lwk-eoniAcT2iz4dmC2JGfr5F_Dd7gYXDt20BnQ@mail.gmail.com>

Hi Bob,

Comments inline

On Fri, Jul 1, 2011 at 8:40 AM, Bob Lund <B.Lund at cablelabs.com> wrote:

> Hi Aaron,
>
> Here are some other aspects of script controlled adaptive bit rate that
> occur to me, perhaps you have already considered these.
>
> 1) I guess script will be responsible for maintaining its own playback
> buffer, monitoring buffer behavior and selecting the appropriate bit rate
> for new fragments. Are there any other network related events/metrics script
> might need to determine which bit-rate to fetch for the next segment? Is
> there any other information from the user agent about playback performance
> that script might need?
>
>
The script would be responsible for managing buffering. It can use the
currentTime & buffered attributes on the video tag to monitor the
consumption of the data passed in via appendData(). I believe the attributes
being proposed in the video metrics
proposal<http://wiki.whatwg.org/wiki/Video_Metrics#Proposal> could
also be helpful. Right now I'm just using XMLHttpRequest to fetch WebM
clusters and measuring how long it takes to fetch them to create a bandwidth
estimate. I haven't spent much time on the BW measurement & adaptation
algorithms yet. I'm just trying to nail down mechanism for passing the media
data to the browser first.


> 2) If a media resource is a multi-track resource then it would seem script
> will also have to fetch fragments for those tracks which implies that the
> audio element would need the append method. Timed text tracks would also
> need to be processed and Cues appended.
>
>
The idea is that appendData() can receive media for multiple tracks. In the
case of WebM each cluster can have blocks from different tracks multiplexed
together. The initial stream config information contains the the track
mappings necessary to demux the cluster. I was also planning to allow both
multiplexed and demultiplexed clusters. Cluster timecodes must be in
monotonically increasing order, but it would be possible to call
appendData() with an cluster with only audio data followed by a cluster with
only video data. This would allow straight forward support for deployments
where audio & video tracks for a single presentation are in separate WebM
files.


> There is a new media pipeline task force in the Web and TV IG (
> http://www.w3.org/2011/webtv/wiki/MPTF) that is also planning to examine
> this topic. You may want to participate.
>
>
I have signed up to the mailing list and will take some time to catch up
with the archives.

Thanks for your comments.

Aaron

From michaeln at google.com  Fri Jul  1 12:33:34 2011
From: michaeln at google.com (Michael Nordman)
Date: Fri, 1 Jul 2011 12:33:34 -0700
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
Message-ID: <CAHpoE=irx0MVLZwvJRCyB3Rc+qNOb6dTF=GJyPjmk__7Hz6VUg@mail.gmail.com>

A common request that maybe we can agree upon is the ability to list the
manifests that are cached and to delete them via script. Something like...
  String[] window.applicationCache.getManifests();  // returns appcache
manifest for the origin
  void window.applicationCache.deleteManifest(manifestUrl);

I think it's clear from this discussion (and others) that the overall
appcache feature set leaves something to be desired, but it's less clear how
to best satisfy the "desirements". Until there is some clarity, it's hard to
see how the community is going to make progress. Personally, I think whats
needed to move things forward is for browser vendors to do some independent
innovating to see what works and what doesn't work.

>> @Hixie... any idea when the appcache feature set will be up for a growth
>> spurt? I think there's an appetite for another round of features in the
>> offline app developers that i communicate with. There's been some recent
>> interest here in pursuing a means of programatically producing a
>> response instead of just returning static content.
>
> Who implements it currently? Is there a test suite? Those are the main
> things that would gate a dramatic addition of new features.

Well, nobody yet; but I have a roadmap in mind that builds up to that. Much
of the discussion in this thread has been on the second item. Mobile
developers are particularly interested 2 to avoid HTTP cache churn and the
cost of HTTP cache validation. In this roadmap, you can see that it would
also allow pages vended from servers to make use of "executable intercept
handlers".


-1. [DONE] Support for cross-origin HTTPS resources.
http://code.google.com/p/chromium/issues/detail?id=69594

0. [DONE] A means of not invoking the fallback resource for some error
responses that would generally result in the fallback resource being
returned. An additional response header would suite they're needs...
something like...
x-chromium-appcache-fallback-override: disallow-fallback
If a response header is present with that value, the fallback response would
not be returned.
http://code.google.com/p/chromium/issues/detail?id=82066

1. [UNDER CONFUSING DISCUSSION] Allow a syntax to associate a page with an
application cache, but does
not add that page to the cache. A common feature request also mentioned on
the whatwg list, but it's not getting any engagement from other browser
vendors or the spec writer (which is kind of frustrating). The premise is to
allow pages vended from a server to take advantage of the resources in an
application cache when loading subresources. A perfectly reasonable
request, <http useManifest='x'>.

2. Introduce a new manifest file section to INTERCEPT requests into a prefix
matched url namespace and satisfy them with a cached resource. The resulting
page would be free to interpret the location url and act accordingly based
on the path and query elements beyond the prefix matched url string. This
section would be similar to the FALLBACK section in that prefix matching is
involved, but different in that instead of being used only in the case of a
network/server error, the cached INTERCEPT resource would be used
immediately w/o first going to the server.
  INTERCEPT:
  urlprefix redirect newlocationurl
  urlprefix return cachedresourceurl

Here's where the INTERCEPT namespace could fit into the changes to the
network model.
   if (url is EXPLICITLY_CACHED)  // exact match
     return cached_response;
   if (url is in NETWORK namespace) // prefix match
     return network_response_as_usual;
   if (url is in INTERCEPT namespace) // prefix match <---- this is the new
section
     return handle_intercepted_request_accordingly
   if (url is in FALLBACK namespace) // prefix match
     return network_response_but_fallback_where_needed;
   if (ONLINE_WILDCARD)
     return network_response;
   otherwise
     return synthesized_error_response;

3. Allow an INTERCEPT cached resources to be "executable". Instead of simply
returning the cached resource or redirect in response to the request, load
it into a
background worker context (if not already loaded) and invoke a function in
that context to asynchronously compute response headers and body based on
the request headers (including cookie) and body. The background worker would
have access to various local storage facilities (fileSystem, indexed/sqlDBs)
as well as the ability to make network requests via XHR.
  INTERCEPT:
  urlprefix execute cachedexecutableresourceurl

4. Create a syntax to allow FALLBACK resources to be similarly executable in
a background worker context.

5. Some kind of auto-update policy where the appcache is refreshed w/o the
app running.

There are a couple of features that are not on this list that I want to call
out:

* The ability to add(url) and remove(url) the appcache is not on the list.
FileSystem urls cover a lot of this already, and the ability to cache adhoc
resources and later load them via http urls could be composed out of the
filesystem and executable handlers. Although having add(url) and remove(url)
could probably make for a friendlier API, so maybe this should be squeezed
somewhere inbetween 1 and 3. Or maybe an intercept handler directive could
bind a url prefix to a directory in the origins FileSystem?
   INTERCEPT:
   urlprefix filesystem_temp /path/to/dir/in/temp/web_file_system
   urlprefix filesystem_pers /path/to/dir/in/persistent/...

* A Gears-like 'querymatching' capability is not on the list, executable
handlers subsume that in a much better way.



On Thu, Jun 30, 2011 at 8:22 PM, Felix Halim <felix.halim at gmail.com> wrote:

> On Fri, Jul 1, 2011 at 12:40 AM, timeless <timeless at gmail.com> wrote:
> > It's possible to build a main page so that it can update its content
> > using a subresource. You can use iframes, javascript (including json),
> > xmlhttprequests, or other things to do this.
>
> Those are another option besides using localStorage.
> Again, those things requires restructuring your website.
> I'm looking for a solution that doesn't require modifying anything
> except adding a manifest.
>
>
> > Nothing requires you to have a monolythic main page which is incapable
> > of dynamically updating itself. ... If I visit your page on May 1st
> > and sit there for two months, does your page really just want to
> > continue to show me the same content when I glance at it on July 1st?
> > It can show other content if it wants to, and in order to save
> > bandwidth costs, it should avoid resending the framework which
> > shouldn't be changing. Once your page works well for this case, it
> > should work well for app-cache.
>
> As I said before, separating dynamic from the static will work,
> however, if we don't have "pageStorage", even we have a clean dynamic
> separation, it will quickly run out of space if we use "localStorage"
> since the localStorage quota is per domain.
>
> Let's see an example:
>
> I have a dynamic page with this url:
>
> http://bla/page?id=10
>
> The content inside is changing very frequently, lets say every hour.
> Of course, I want the browser to cache the latest version.
> So, it seemed that AppCache is a perfect fit...
>
> I then add the manifest to enable the App Cache, and what do I get?
>
> Everytime I open that URL every hour, I ALWAYS see the STALE version
> (the 1 hour late version). Then few seconds (or minutes) later (depend
> on when the AppCache gets updated), I refresh, then I got the latest
> content. Annoying, right?
>
> In this case, I better off NOT to use App Cache, since it brings the
> old content everytime.
>
> This is why most people says please "DON'T cache the main page".
>
>
>
> Now, let see the alternative: I build a framework to separate the
> dynamic from the static.
> I have to make it so that only ONE MAIN PAGE get cached by the app cache.
> So, my URL can NO LONGER BE:
>
> http://bla/page?id=10
>
> But it has to change to:
>
> http://bla/page#!id=10
>
> Why do I have to do this? it's because if I DON'T, then each page will
> be stored on different App Cache, and the "stale by one" still occurs!
> That is,
>
> http://bla/page?id=10
>
> and
>
> http://bla/page?id=11
>
> Will be on DIFFERENT AppCache!
>
> In that case, my cleanly separated static and dynamic will have no effect!
> Because all the statics get duplicated for each App Cache.
> It will be the same as if I don't have the framework!
>
> So, to make the AppCache only cache one static framework, I have to
> make my page such that it is served under ONE url:
>
> http://bla/page
>
> Then take the "#!id=10" as non url (or ajax bookmark). This way, the
> AppCache will only cache ONE of my static framework, and MANY dynamic
> content inside it.
>
> Guess what? All the incoming links from other blogs are now broken!
> Of course I can make a redirect, but redirect is AGAINST making the web
> faster!
>
> I think Facebook did the #! thing a while ago, then they abandoned it, why?
>
> Ok now I'm happy with my framework and the redirect, and guess what?
> Soon, I have other pages with #!id=11, #!id=12, ...,  #!id=10000.
> All of them are important and I wan't to cache them and I uses the
> localStorage (or indexedDB) to cache the dynamic content of those
> pages.
> Note that even though the dynamic content is "dynamic" it doesn't mean
> that:
>
> http://bla/page?id=10
>
> has "shared" data with
>
> http://bla/page?id=11
>
> It can be totally different unrelated dynamic content. id=10 dynamic
> content is entirely different from id=11 dynamic content. However,
> since I use localStorage to cache the dynamic content, ALL OF THEM are
> limited to the quota of my domain. My 5MB localStorage domain quota
> will quickly run out of space.
>
> If only I can store the dynamic content into a pageStorage (assuming
> different URL -> including the shebang bookmark has different
> pageStorage), then I won't be running out of storage if I keep one
> page within 5MB. So
>
> http://bla/page#!id=10
>
> has 5 MB pageStorage quota, and
>
> http://bla/page#!id=11
>
> also has 5 MB pageStorage quota, etc...
>
> Then I would be very happy with the new framework.
> Since it will store very compact static App and very compact dynamic
> content.
> It's a win win for everyone, nothing is wasted.
>
> But, if I don't have pageStorage quota, my beautifully separated the
> dynamic from the static framework will be useless since the
> localStorage DOMAIN QUOTA will kill me.
>
>
> So, we have seen how the AppCache fails to satisfy certain usecase and
> how pageStorage is needed to make the alternative solution works.
>
> Here, I propose a solution:  AppCache should COMPLEMENT HTTP Cache so
> that "the main page is not cached" (you know this is not literally
> what it means).
>
> With that solution, I don't have to do ANYTHING on my original site to
> make it work (except adding a manifest to my original page). I can
> still use the old url:
>
> http://bla/page?id=10
>
> It will cache AND SHOW the latest page to the users (just like normal
> web page with HTTP Cache). Then will show the latest cache if the
> network or the server is offline (and perhaps give notification
> header). That's ALL I NEED. This guarantees that my website will still
> be available when the user goes offline.
>
>
> All these discussions only begs to add one feature to AppCache:
> - Only show the cache when the network / server is offline, otherwise,
> show the online version of the page.
>
> The current AppCache doesn't care whether the network/server is online
> or offline, it BLINDLY shows the cache everytime. This is good for the
> default, however, we should HAVE an option to not show the cache if we
> are ONLINE (this is what people meant when they say "DON"T CACHE THE
> MAIN PAGE").
>
> Felix Halim
>

From michaeln at google.com  Fri Jul  1 13:38:46 2011
From: michaeln at google.com (Michael Nordman)
Date: Fri, 1 Jul 2011 13:38:46 -0700
Subject: [whatwg] AppCache + CORS issue.
Message-ID: <CAHpoE=h4uyD0F5Tr=W8JLZsh6YaO4vEu8gGpGb54deN768PCOQ@mail.gmail.com>

Cross-origin resources listed in the CACHE section aren't retrieved with the
'Origin' header and the responses may not contain the
'Access-Control-Allow-Origin'
header. This makes it impossible to utilized CORS for appcache resources.

http://code.google.com/p/chromium/issues/detail?id=86324

We may need a way to express in the manifest file that the x-origin
resource is to be retrieved and cached with the CORS related headers.
Maybe a new manifest file section a lot like the CACHE section but a
little different... something like...

CACHE-CORS:http://cross-origin/resource

When fetching, the 'Origin' header would be included and the responses
'Access-Control-Allow-Origin' header would be cached. When accessed by
pages associated with the appcache, the access-control-allow-origin
header would be provided.

From ojan at chromium.org  Fri Jul  1 13:59:02 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 1 Jul 2011 13:59:02 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
Message-ID: <CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>

Do any browser vendors agree with this or have objections? Hixie, this seem
OK to you?

These additions seem safe, simple and enable sites giving users a better
experience.

On Wed, Apr 20, 2011 at 11:32 PM, James Kozianski <koz at chromium.org> wrote:

> Hi,
>
> I'd like to propose the following changes to the registerProtocolHandler
> spec.
>
> 1. Introduce an isRegistered() function.
>
> Currently if a site wants its users to register it as a handler for a given
> protocol it has two options:
>
>    a) It can call registerProtocolHandler() on page load. (This approach
> was suggested in [1])
>
>    b) It can have a button that the user clicks (or similar) to enact the
> registration.
>
>
> The former is problematic because the call to registerProtocolHandler will
> cause the browser's UI to notify them of the registration (or prompt them
> to
> make a decision), which is redundant if it occurs on every page load.
>
>
> The latter is problematic because it puts the onus on each site developer
> to
> provide the UI to allow the user to make the change. Also, as the site
> doesn't know whether the user has already registered the given protocol
> handler, it can't tailor its UI to reflect this. This means the UI either
> always shows, or never shows, both of which are undesirable.
>
>
> Having an isRegistered() function would allow a site to simply make the RPH
> call conditionally on load, or to provide a UI for it that reflects the
> user's current preference.
>
>
> 2. Introduce an unregisterProtocolHandler() function.
>
> Such a function is desirable because it allows sites to remove outdated
> handlers from clients and would enable clients to provide a UI for managing
> their registered protocol handlers.
>
>
> 3. Require all URL arguments to have the same origin as the page executing
> the call.
>
> This would would make the behaviour of this set of functions more
> consistent
> (isRegistered() should only work for same-domain queries, to prevent
> information leaking).
>
>
> Cheers,
> James
>
> [1] - http://www.mail-archive.com/whatwg at lists.whatwg.org/msg14548.html
>

From pkasting at google.com  Fri Jul  1 14:10:12 2011
From: pkasting at google.com (Peter Kasting)
Date: Fri, 1 Jul 2011 14:10:12 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
Message-ID: <BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>

On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai <ojan at chromium.org> wrote:

> Do any browser vendors agree with this or have objections?


>From my work on the Chrome UI side of this, I would very much like to see
something like isRegistered().  This would allow sites to conditionalize
requests for the protocol handler.  This is important to me because I would
also like to experiment (after that point) with requiring a user gesture for
this request (much like browsers typically require user gestures for
window.open()), so sites cannot hammer the user with requests outside of
some sort of interaction-based workflow.

PK

From mpd at google.com  Fri Jul  1 14:25:32 2011
From: mpd at google.com (Michael Davidson)
Date: Fri, 1 Jul 2011 14:25:32 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
Message-ID: <CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>

>From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined previously, then calling registerProtocolHandler() in
today's UAs will not do anything. If I can't detect that state, then they'll
keep clicking and I'll keep calling and they'll get frustrated.

I'd prefer if isRegistered() was something like registeredState() and
returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
really reflects reality.

Michael

From ojan at chromium.org  Fri Jul  1 14:44:06 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 1 Jul 2011 14:44:06 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
Message-ID: <CANMdWTt9NmUJS3CO3TDS83p00k504GsZ47U1mM-8L6HSxPRt6Q@mail.gmail.com>

Agree. This seems strictly superior. Just to bikeshed on the name a bit,
since this is hanging off the navigator object, the name should probably
mention something about protocols, protocolState()?

On Fri, Jul 1, 2011 at 2:25 PM, Michael Davidson <mpd at google.com> wrote:

> From my perspective on Gmail, I would prefer to know if the user hasn't
> registered because they declined previously or haven't been asked. If
> they've declined previously, then calling registerProtocolHandler() in
> today's UAs will not do anything. If I can't detect that state, then they'll
> keep clicking and I'll keep calling and they'll get frustrated.
>
> I'd prefer if isRegistered() was something like registeredState() and
> returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
> really reflects reality.
>
> Michael
>
>

From Olli.Pettay at helsinki.fi  Fri Jul  1 14:58:24 2011
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Sat, 02 Jul 2011 00:58:24 +0300
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
Message-ID: <4E0E4300.6000602@helsinki.fi>

On 07/02/2011 12:25 AM, Michael Davidson wrote:
>  From my perspective on Gmail, I would prefer to know if the user hasn't
> registered because they declined previously or haven't been asked. If
> they've declined previously, then calling registerProtocolHandler() in
> today's UAs will not do anything. If I can't detect that state, then they'll
> keep clicking and I'll keep calling and they'll get frustrated.
>
> I'd prefer if isRegistered() was something like registeredState() and
> returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
> really reflects reality.

Shouldn't there be also something like "NOTANSWERED", if user hasn't yet
decided whether to accept registering or not.


Though, I wonder if there is some privacy issue related to
isRegistered/registeredState(). Or there is - web app can
know whether it is being used as the default protocol handler
for some protocol, say mailto: with GMail.
But is the privacy issue bad enough to worry about?

Safer option would be if registeredState() would just return
"ASKED" or "NOTASKED"


-Olli

From ojan at chromium.org  Fri Jul  1 15:03:16 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 1 Jul 2011 15:03:16 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E0E4300.6000602@helsinki.fi>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
	<4E0E4300.6000602@helsinki.fi>
Message-ID: <CANMdWTvPV0k83RrEb++GbnfdHZvcnME7v1Px8m-wmoPzoyYmMQ@mail.gmail.com>

On Fri, Jul 1, 2011 at 2:58 PM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:

> On 07/02/2011 12:25 AM, Michael Davidson wrote:
>
>>  From my perspective on Gmail, I would prefer to know if the user hasn't
>> registered because they declined previously or haven't been asked. If
>> they've declined previously, then calling registerProtocolHandler() in
>> today's UAs will not do anything. If I can't detect that state, then
>> they'll
>> keep clicking and I'll keep calling and they'll get frustrated.
>>
>> I'd prefer if isRegistered() was something like registeredState() and
>> returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
>> really reflects reality.
>>
>
> Shouldn't there be also something like "NOTANSWERED", if user hasn't yet
> decided whether to accept registering or not.
>

I'm not opposed to this for completeness sake. I expect all sites would just
ask again in this case.


> Though, I wonder if there is some privacy issue related to
> isRegistered/registeredState()**. Or there is - web app can
> know whether it is being used as the default protocol handler
> for some protocol, say mailto: with GMail.
> But is the privacy issue bad enough to worry about?
>

I'm not sure what the privacy issue here is given that we restrict to
same-domain. You're already using the site, so it's just whether they can
tell that you use them as a protocol handler. I don't see a problem with
exposing that.


> Safer option would be if registeredState() would just return
> "ASKED" or "NOTASKED"
>
>
> -Olli
>

From mpd at google.com  Fri Jul  1 15:08:08 2011
From: mpd at google.com (Michael Davidson)
Date: Fri, 1 Jul 2011 15:08:08 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTvPV0k83RrEb++GbnfdHZvcnME7v1Px8m-wmoPzoyYmMQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
	<4E0E4300.6000602@helsinki.fi>
	<CANMdWTvPV0k83RrEb++GbnfdHZvcnME7v1Px8m-wmoPzoyYmMQ@mail.gmail.com>
Message-ID: <CAHYqKGeWFcjpOLkBMDtF0OSjawMZW5+7kBtBLWeBSGdYf5odZg@mail.gmail.com>

On Fri, Jul 1, 2011 at 3:03 PM, Ojan Vafai <ojan at chromium.org> wrote:

> I'm not sure what the privacy issue here is given that we restrict to
> same-domain. You're already using the site, so it's just whether they can
> tell that you use them as a protocol handler. I don't see a problem with
> exposing that.
>

FWIW, notifications already exposes this:

http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html

Seems best just to crib what they already did.

Michael


>
>
>> Safer option would be if registeredState() would just return
>> "ASKED" or "NOTASKED"
>>
>>
>> -Olli
>>
>
>

From svartman95 at gmail.com  Fri Jul  1 17:14:39 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sat, 02 Jul 2011 00:14:39 +0000
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
Message-ID: <4E0E62EF.6020106@gmail.com>

?ann f?s  1.j?l 2011 03:22, skrifa?i Felix Halim:
> I'm looking for a solution that doesn't require modifying anything
> except adding a manifest.
>
I recommend fixing your website. As others have stated, this has 
practical benefits, in the online as well as the offline case.

> As I said before, separating dynamic from the static will work,
Great!

> however, if we don't have "pageStorage", even we have a clean dynamic
> separation, it will quickly run out of space if we use "localStorage"
> since the localStorage quota is per domain.
>
Nobody's forcing you to use localStorage. How do you figure using 
pageStorage or localStorage will be less work than using iframes or 
other linking methods already proposed?

> Let's see an example:
>
> I have a dynamic page with this url:
>
> http://bla/page?id=10
>
> The content inside is changing very frequently, lets say every hour.
> Of course, I want the browser to cache the latest version.
Then specify the applicable HTTP headers with informative values. HTTP 
caching hasn't stopped working, nor is it barred from improving. There 
is space for implementations to improve while complying with current 
specifications. All you have to do is split dynamic resources from 
static, read the RFC and send the appropriate headers.
Of course this method has the drawback of requiring a request/response 
pair for every resource transferred over HTTP.

> So, it seemed that AppCache is a perfect fit...
>
AppCache is no magic bullet. Don't use it if you figure it isn't a 
perfect fit.

> I then add the manifest to enable the App Cache, and what do I get?
>
> Everytime I open that URL every hour, I ALWAYS see the STALE version
> (the 1 hour late version). Then few seconds (or minutes) later (depend
> on when the AppCache gets updated), I refresh, then I got the latest
> content. Annoying, right?
>
FYI, HTTP has already resolved this issue, by forbidding implementations 
from returning a stale version by default under normal situations or 
without warning

> In this case, I better off NOT to use App Cache, since it brings the
> old content everytime.
>
Right. Bad App Cache.

> Now, let see the alternative: I build a framework to separate the
> dynamic from the static.
> I have to make it so that only ONE MAIN PAGE get cached by the app cache.
> So, my URL can NO LONGER BE:
>
> http://bla/page?id=10
>
> But it has to change to:
>
> http://bla/page#!id=10
>
> Why do I have to do this? it's because if I DON'T, then each page will
> be stored on different App Cache, and the "stale by one" still occurs!
> That is,
>
> http://bla/page?id=10
>
> and
>
> http://bla/page?id=11
>
> Will be on DIFFERENT AppCache!
>
> In that case, my cleanly separated static and dynamic will have no effect!
> Because all the statics get duplicated for each App Cache.
> It will be the same as if I don't have the framework!
>
I'm not following your line of thinking. Why do you insist on using an 
App Cache for each page rather than a shared cache for all your resources?

> So, to make the AppCache only cache one static framework, I have to
> make my page such that it is served under ONE url:
>
> http://bla/page
>
> Then take the "#!id=10" as non url (or ajax bookmark). This way, the
> AppCache will only cache ONE of my static framework, and MANY dynamic
> content inside it.
>
> Guess what? All the incoming links from other blogs are now broken!
> Of course I can make a redirect, but redirect is AGAINST making the web faster!
>
> I think Facebook did the #! thing a while ago, then they abandoned it, why?
>
> Ok now I'm happy with my framework and the redirect, and guess what?
> Soon, I have other pages with #!id=11, #!id=12, ...,  #!id=10000.
> All of them are important and I wan't to cache them and I uses the
> localStorage (or indexedDB) to cache the dynamic content of those
> pages.
> Note that even though the dynamic content is "dynamic" it doesn't mean that:
>
> http://bla/page?id=10
>
> has "shared" data with
>
> http://bla/page?id=11
>
> It can be totally different unrelated dynamic content. id=10 dynamic
> content is entirely different from id=11 dynamic content. However,
> since I use localStorage to cache the dynamic content, ALL OF THEM are
> limited to the quota of my domain. My 5MB localStorage domain quota
> will quickly run out of space.
>
Are you certain that users wish to archive every single dynamic resource 
they fetch from your site? Disposition of any significant amount of 
storage should be in the hands of the user, if indirectly through the 
user agent. Take handhelds.

> If only I can store the dynamic content into a pageStorage (assuming
> different URL ->  including the shebang bookmark has different
> pageStorage), then I won't be running out of storage if I keep one
> page within 5MB. So
And you're sure this is a good thing, because?

> http://bla/page#!id=10
>
You *can't* allocate a quota per URI fragment, as a script in the page 
could create new ones as wanted.

> Then I would be very happy with the new framework.
> Since it will store very compact static App and very compact dynamic content.
> It's a win win for everyone, nothing is wasted.
>
> But, if I don't have pageStorage quota, my beautifully separated the
> dynamic from the static framework will be useless since the
> localStorage DOMAIN QUOTA will kill me.
>
>
> So, we have seen how the AppCache fails to satisfy certain usecase and
> how pageStorage is needed to make the alternative solution works.
>
Show how either the HTTP specification or common practice forbids HTTP 
caches from satisfy your use cases.

> Here, I propose a solution:  AppCache should COMPLEMENT HTTP Cache so
> that "the main page is not cached" (you know this is not literally
> what it means).
>
Caching the main page may be useful, so you'd have to implement both.

> With that solution, I don't have to do ANYTHING on my original site to
> make it work (except adding a manifest to my original page). I can
> still use the old url:
>
> http://bla/page?id=10
>
> It will cache AND SHOW the latest page to the users (just like normal
> web page with HTTP Cache). Then will show the latest cache if the
> network or the server is offline (and perhaps give notification
> header). That's ALL I NEED. This guarantees that my website will still
> be available when the user goes offline.
>
You're asking for user agents archiving websites for offline viewing (in 
the offline mode). I fetch a bunch of unread pages for offline reading 
from time to time, but keeping a copy of read pages when I'm most likely 
going to be online may be considered a waste of storage space. Users who 
have a lot of storage at their disposal may do this already. I see no 
reason to do so only if requested by the author.

There are two situations:
  a) A user agent runs in a constrained environment with limited storage 
space. The user agent caches static resources only, or doesn't cache at all.
  b) A user agent runs in a plentiful environment with great volumes of 
storage space at it's disposal. The user agent archives most if not all 
resources it fetches, throwing stale resources away according to a cache 
algorithm when a quote set in proportion to the available storage space 
is reached.

How does your proposal help the user agent in archiving, or not 
archiving resources?

>
> All these discussions only begs to add one feature to AppCache:
> - Only show the cache when the network / server is offline, otherwise,
> show the online version of the page.
>
This requires a validation roundtrip (as is common), but is otherwise fair.

> The current AppCache doesn't care whether the network/server is online
> or offline, it BLINDLY shows the cache everytime. This is good for the
> default, however, we should HAVE an option to not show the cache if we
> are ONLINE (this is what people meant when they say "DON"T CACHE THE
> MAIN PAGE").
>
HTTP caches may do what you want.

From felix.halim at gmail.com  Sat Jul  2 12:16:49 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Sun, 3 Jul 2011 03:16:49 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <4E0E62EF.6020106@gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
Message-ID: <CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>

On Sat, Jul 2, 2011 at 8:14 AM, Bjartur Thorlacius <svartman95 at gmail.com> wrote:
> ?ann f?s ?1.j?l 2011 03:22, skrifa?i Felix Halim:
>>
>> I'm looking for a solution that doesn't require modifying anything
>> except adding a manifest.
>>
> I recommend fixing your website. As others have stated, this has practical
> benefits, in the online as well as the offline case.

I don't mind fixing my website, if I really have to! If AppCache have
an option to always view the main page "online", I won't have to do
anything.


>> however, if we don't have "pageStorage", even we have a clean dynamic
>> separation, it will quickly run out of space if we use "localStorage"
>> since the localStorage quota is per domain.
>>
> Nobody's forcing you to use localStorage. How do you figure using
> pageStorage or localStorage will be less work than using iframes or other
> linking methods already proposed?

It's not about the amount of work that matters, it's the quota I'm
talking about.


>> Let's see an example:
>>
>> I have a dynamic page with this url:
>>
>> http://bla/page?id=10
>>
>> The content inside is changing very frequently, lets say every hour.
>> Of course, I want the browser to cache the latest version.
>
> Then specify the applicable HTTP headers with informative values. HTTP
> caching hasn't stopped working, nor is it barred from improving. There is
> space for implementations to improve while complying with current
> specifications. All you have to do is split dynamic resources from static,
> read the RFC and send the appropriate headers.
> Of course this method has the drawback of requiring a request/response pair
> for every resource transferred over HTTP.

Remember that I also want those URL to be available even if the user is offline.
HTTP Cache is not that powerful, AppCache is.


>> In that case, my cleanly separated static and dynamic will have no effect!
>> Because all the statics get duplicated for each App Cache.
>> It will be the same as if I don't have the framework!
>>
> I'm not following your line of thinking. Why do you insist on using an App
> Cache for each page rather than a shared cache for all your resources?

I do want to use shared cache for shared resources and "page cache"
for non-shared resources (unique to that page). However, the
non-shared resources will become too large to fit in 5MB quota.
Remember I have different non-shared content for id=10, id=11, ...,
id=100000, I don't think that will fit in localStorage.


> Are you certain that users wish to archive every single dynamic resource
> they fetch from your site? Disposition of any significant amount of storage
> should be in the hands of the user, if indirectly through the user agent.
> Take handhelds.

Users only view the resources they want.

When they viewed it, I want it to be there for offline use or for
performance reasons.
I expect the users only view (and cache) few hundreds of them.
They cannot cache what they didn't view / open.
It is OK for the browser to not cache it if it doesn't any storage left.

I am satisfied if there is a "page storage" quota of 5MB given per
page (not per domain).
This will solve all my problems (of course by restructuring my site).



>> If only I can store the dynamic content into a pageStorage (assuming
>> different URL -> ?including the shebang bookmark has different
>> pageStorage), then I won't be running out of storage if I keep one
>> page within 5MB. So
>
> And you're sure this is a good thing, because?

Because currently, browsers can handle a page content < 5MB very fast.
I think it is OK for a page (not a domain) to have 5MB data quota.

If you are building games, perhaps need more than that (it has to go
to the web store to get unlimited permission). However, for regular
pages, 5MB "currently" is more than enough. 5MB per domain is too
small!


>> http://bla/page#!id=10
>>
> You *can't* allocate a quota per URI fragment, as a script in the page could
> create new ones as wanted.

Yes I know, that was only for an example to point out that:

If I use shared cache:

http://bla/page

I will run out of quota quickly.

If I use parameters like this:

http://bla/page?id=10

I will have to refresh TWICE to get the latest content (annoying).

If I can use:

http://bla/page#!id=10

I get the best of both worlds, that is I have shared static cache, and
I won't run out of quota for the non-shared-dynamic cache since the
quota is 5MB per hash value. I know that this has a security hole that
the script can just generate random url to get more quota.

My suggestion is to give quota to hash value for the first time the
page is loaded, so a later script modification will be linked to the
original hash value's quota.


>> So, we have seen how the AppCache fails to satisfy certain usecase and
>> how pageStorage is needed to make the alternative solution works.
>>
> Show how either the HTTP specification or common practice forbids HTTP
> caches from satisfy your use cases.

I think it's clear that HTTP Cache is inferior to AppCache.
What HTTP Cache can, it can be overridden by AppCache.
AppCache complements HTTP Cache.

HTTP Cache does satisfy my use cases since long time ago.
But with the presence of AppCache, I want better control.


> You're asking for user agents archiving websites for offline viewing (in the
> offline mode). I fetch a bunch of unread pages for offline reading from time
> to time, but keeping a copy of read pages when I'm most likely going to be
> online may be considered a waste of storage space. Users who have a lot of
> storage at their disposal may do this already. I see no reason to do so only
> if requested by the author.

AppCache cannot cache what has not been read/viewed.
What have been viewed can be safely deleted by the browser without warning.
Except, perhaps, for special "installable" web-apps in the store?


> There are two situations:
> ?a) A user agent runs in a constrained environment with limited storage
> space. The user agent caches static resources only, or doesn't cache at all.
> ?b) A user agent runs in a plentiful environment with great volumes of
> storage space at it's disposal. The user agent archives most if not all
> resources it fetches, throwing stale resources away according to a cache
> algorithm when a quote set in proportion to the available storage space is
> reached.
>
> How does your proposal help the user agent in archiving, or not archiving
> resources?

The decision of archiving is entirely up to the browser.
The cached pages in the AppCache will work fine if it is deleted by the browser.
It will just re-fetch everything and it will be as slow as the first
view of the page.

The archiving problem is not relevant for my proposal.


>> All these discussions only begs to add one feature to AppCache:
>> - Only show the cache when the network / server is offline, otherwise,
>> show the online version of the page.
>>
> This requires a validation roundtrip (as is common), but is otherwise fair.

Yes of course.

However, if the AppCache is set to cache the main page + everything,
no roundtrip is needed.

My proposal is to include an option to ALWAYS make a roundtrip for the
main page and show the latest main page (rather than show the cached
main page which avoid the roundtrip but will do that in later time and
giant refresh needed).


>> The current AppCache doesn't care whether the network/server is online
>> or offline, it BLINDLY shows the cache everytime. This is good for the
>> default, however, we should HAVE an option to not show the cache if we
>> are ONLINE (this is what people meant when they say "DON"T CACHE THE
>> MAIN PAGE").
>>
> HTTP caches may do what you want.

Yes, but I'm no longer satisfied with HTTP Caches when I can use a
more reliable AppCache.

Felix Halim

From timeless at gmail.com  Sun Jul  3 00:11:05 2011
From: timeless at gmail.com (timeless)
Date: Sun, 3 Jul 2011 03:11:05 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
Message-ID: <CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>

On 7/1/11, Ojan Vafai <ojan at chromium.org> wrote:
> Do any browser vendors agree with this or have objections?

I don't look forward to being blackmailed by sites into me allowing
them to register for X or else I don't get their content.

I have a bank which won't let me bank unless I have Java installed,
not because banking requires Java (and not because this bank requires
Java to do online banking, just because).

Testing for features should only be done by using them.

It's ok to try to do X and then after time T tell the user: "This
might work better if you ... <registered>".

It isn't ok to say "You can't do X unless you make Y your default Z."

From timeless at gmail.com  Sun Jul  3 00:17:42 2011
From: timeless at gmail.com (timeless)
Date: Sun, 3 Jul 2011 03:17:42 -0400
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
Message-ID: <CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>

If you have 100mb of junk, it won't fit in my browser's http cache
either. And that's a good thing, there are other sites I visit that
are more important. However, a browser is within its rights to detect
that its user uses a site so heavily as to justify increasing that
site's cache allocation. That's a QoI detail.

Note that if 70% of your 100mb is duplicated framework, it's possible
that a better implementation of your site could fit into a 25mb
cache...

From felix.halim at gmail.com  Sun Jul  3 00:41:54 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Sun, 3 Jul 2011 15:41:54 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
Message-ID: <CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>

On Sun, Jul 3, 2011 at 3:17 PM, timeless <timeless at gmail.com> wrote:
> If you have 100mb of junk, it won't fit in my browser's http cache
> either. And that's a good thing, there are other sites I visit that
> are more important. However, a browser is within its rights to detect
> that its user uses a site so heavily as to justify increasing that
> site's cache allocation. That's a QoI detail.

Yes, the quota system can be improved heuristically.

> Note that if 70% of your 100mb is duplicated framework, it's possible
> that a better implementation of your site could fit into a 25mb
> cache...

The only way to remove the duplication is to use a single URL for the
web app (then apply AppCache to that URL), and uses shebang to
uniquely identify the page:

http://bla/page#!id=10

Then all the non-duplicated data are stored in localStorage/indexedDB.

I would love this, however as long as the quota system is still 5MB
(or an equivalent page storage quota), I don't feel inclined to make
that changes to my site yet. The browsers vendors have to move first
to design better quota systems.

Or is there any other way to cleanly do the separation without shebang?

FYI, I want my page to be able to be linked (referenced / bookmarked)
from other sites.

Btw, does anyone know why Facebook abandoned the usage of shebang?

Felix Halim

From nils at dieweltistgarnichtso.net  Sun Jul  3 05:21:53 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 3 Jul 2011 14:21:53 +0200
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
	<CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
Message-ID: <20110703142153.0067f8dd@desudesudesu>

Felix Halim <felix.halim at gmail.com> schrieb am Sun, 3 Jul 2011 15:41:54
+0800:

> Btw, does anyone know why Facebook abandoned the usage of shebang?

If they did so, then rightly so. Hashbangs are a thouroughly bad idea:
<http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs>

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From felix.halim at gmail.com  Sun Jul  3 08:16:16 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Sun, 3 Jul 2011 23:16:16 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <20110703142153.0067f8dd@desudesudesu>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
	<CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
	<20110703142153.0067f8dd@desudesudesu>
Message-ID: <CAAbwPopZwDwF2hrDKx-AQKQr+nrxx2ZDvfXguDVnJZw_Knj89A@mail.gmail.com>

On Sun, Jul 3, 2011 at 8:21 PM, Nils Dagsson Moskopp
<nils at dieweltistgarnichtso.net> wrote:
> Felix Halim <felix.halim at gmail.com> schrieb am Sun, 3 Jul 2011 15:41:54
>> Btw, does anyone know why Facebook abandoned the usage of shebang?
>
> If they did so, then rightly so. Hashbangs are a thouroughly bad idea:
> <http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs>

After reading that article, it seemed that re-structuring the website
to separate the static from dynamic doesn't worth much afterall,
unless there is other method than hash-bang. The follow up question is
that: is there another way to achieve a clean separation without using
hash-bang?

Another question is that how do we bookmark/link AppCached pages
without using hash-bang? I cannot find discussions about it.

Felix Halim

From nils at dieweltistgarnichtso.net  Sun Jul  3 08:40:14 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 3 Jul 2011 17:40:14 +0200
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPopZwDwF2hrDKx-AQKQr+nrxx2ZDvfXguDVnJZw_Knj89A@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
	<CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
	<20110703142153.0067f8dd@desudesudesu>
	<CAAbwPopZwDwF2hrDKx-AQKQr+nrxx2ZDvfXguDVnJZw_Knj89A@mail.gmail.com>
Message-ID: <20110703174014.4f2a613e@desudesudesu>

Felix Halim <felix.halim at gmail.com> schrieb am Sun, 3 Jul 2011 23:16:16
+0800:

> [?]

> After reading that article, it seemed that re-structuring the website
> to separate the static from dynamic doesn't worth much afterall,
> unless there is other method than hash-bang. The follow up question is
> that: is there another way to achieve a clean separation without using
> hash-bang?

You may be looking for this:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html>?

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From pkasting at google.com  Sun Jul  3 12:24:17 2011
From: pkasting at google.com (Peter Kasting)
Date: Sun, 3 Jul 2011 12:24:17 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
Message-ID: <CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>

On Sun, Jul 3, 2011 at 12:11 AM, timeless <timeless at gmail.com> wrote:

> It isn't ok to say "You can't do X unless you make Y your default Z."
>

I would prefer to solve this if it actually becomes a problem.  Right now
sites are actually much _more_ annoying without this feature as they just
blindly ask you to make them your protocol handler every time.  I think we
should solve real usage problems today in preference to leaving them
unsolved for fear of a hypothetical later problem that we could easily solve
down the road.

PK

From nils at dieweltistgarnichtso.net  Sun Jul  3 13:01:17 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 3 Jul 2011 22:01:17 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
Message-ID: <20110703220117.6574dc02@desudesudesu>

Peter Kasting <pkasting at google.com> schrieb am Sun, 3 Jul 2011 12:24:17
-0700:

> On Sun, Jul 3, 2011 at 12:11 AM, timeless <timeless at gmail.com> wrote:
> 
> > It isn't ok to say "You can't do X unless you make Y your default
> > Z."
> >
> 
> I would prefer to solve this if it actually becomes a problem.

Without breaking sites using it properly? That may (or may not) be hard.

> Right now sites are actually much _more_ annoying without this
> feature as they just blindly ask you to make them your protocol
> handler every time.

Can UAs not be expected to handle this properly, like they do with
repeated alerts?

> I think we should solve real usage problems
> today in preference to leaving them unsolved for fear of a
> hypothetical later problem that we could easily solve down the road.

Define ?easily?. Lie to the page if it is annoying?

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From mpd at google.com  Sun Jul  3 14:40:53 2011
From: mpd at google.com (Michael Davidson)
Date: Sun, 3 Jul 2011 14:40:53 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <20110703220117.6574dc02@desudesudesu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
Message-ID: <CAHYqKGcqhwmGDnYyp39rk5ePJ2ZA58jEi51bWXKh3fq3=ixxOw@mail.gmail.com>

Has anyone seen a site that refuses to work unless notifications are active?
I suggest that we follow the notification model since it seems to work well
for both site authors and users.

I imagine that if sites force users to accept notifications or protocol
handlers, those sites won't have many users for long.

If it does become a problem in practice (which I highly doubt), then yes,
having a UA that lies to the site would be one solution. It would take about
five minutes to whip up a userscript that replaces calls to
registerProtocolHandler with a noop.

Michael

From robert at ocallahan.org  Mon Jul  4 03:18:49 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 4 Jul 2011 22:18:49 +1200
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <CAA0c1bBkbYh1dSbBQUWsRF1ChL_VBRkXfhjnwh72MkMAfTfMGg@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
	<CAA0c1bBkbYh1dSbBQUWsRF1ChL_VBRkXfhjnwh72MkMAfTfMGg@mail.gmail.com>
Message-ID: <CAOp6jLZd-kLfS1WD3gaYoH34AF0254wZ2LSWFdOGz=OTj=PAbQ@mail.gmail.com>

On Sat, Jul 2, 2011 at 2:51 AM, Aaron Colwell <acolwell at google.com> wrote:

> On Thu, Jun 30, 2011 at 4:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Fri, Jul 1, 2011 at 4:59 AM, Aaron Colwell <acolwell at google.com>wrote:
>>
>>> I've also been looking at the WebRTC MediaStream API and was wondering if
>>> it
>>> makes more sense to create an object similar to the LocalMediaStream
>>> object.
>>> This has the benefits of unifying how media streams are handled
>>> independent
>>> of whether they come from a camera or a JavaScript based streaming
>>> algorithm. This could also enable sending the media stream through a
>>> Peer-to-peer connection instead of only allowing a camera as a source.
>>> Here
>>> is an example of the type of object I'm talking about.
>>>
>>
>> I think MediaStreams should not be dealing with compressed data except as
>> an optimization when access to decoded data is not required anywhere in the
>> stream pipeline. If you want to do processing of decoded stream data (which
>> I do --- see
>> http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html),
>> then introducing a decoder inside the stream processing graph creates all
>> sorts of complications.
>>
>> Nice spec. If I understand correctly, your position is that MediaStreams
> should only represent uncompressed media?
>

Sort of. I want the data format (compressed vs uncompressed, etc) to be
hidden from Web authors unless they use APIs like Worker-based processing
that require access to decoded data. What I don't want to have to deal with
is compressed data being injected at arbitrary points in the graph. Right
now the only the place compressed data is injected is at stream sources ---
media elements and getUserMedia.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From annevk at opera.com  Mon Jul  4 07:13:05 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 04 Jul 2011 16:13:05 +0200
Subject: [whatwg] EventSource - Handling a charset in the content-type
 header
In-Reply-To: <AANLkTikOc3AbmjjD6rawG+z=8R_CVn7joLuAcXeeNVVM@mail.gmail.com>
References: <AANLkTikOc3AbmjjD6rawG+z=8R_CVn7joLuAcXeeNVVM@mail.gmail.com>
Message-ID: <op.vx3lr3fn64w2qv@anne-van-kesterens-macbook-pro.local>

On Thu, 24 Mar 2011 05:52:02 +0100, Julien Chaffraix  
<julien.chaffraix at gmail.com> wrote:
> the EventSource specification states the current content-type header
> should match the string "text/event-stream". However following some
> bugs opened inside the WebKit project [1], we relaxed the content-type
> check to ignore any specified charset as it confused developers and
> can potentially break existing servers that automatically send a
> charset as part of the response [2].
> We are currently revisiting our approach and our current take would be
> to allow a mime-type of "text/event-stream" with an optional
> charset="UTF-8". No other charset would be allowed as UTF-8 is the
> only encoding supported by the standard.

I noticed Ian updated the specification, but it seems current  
implementations differ quite wildly. E.g. Gecko happily ignores

   Content-Type: text/event-stream;charset=tralala

as does Opera instead of closing the connection. Chrome bites, but happily  
ignores

   Content-Type: text/event-stream;tralala

along with Opera and Gecko. Safari 5.0.5 bites on that however and also on  
charset=tralala. All browsers seem to allow (note the trailing semi-colon):

   Content-Type: text/event-stream;

Are we sure we want this strict checking of media type parameters? I  
always thought the media type itself was what strict checking should be  
done upon, but that its parameters were extension points, not points of  
failure.


> [1] https://bugs.webkit.org/show_bug.cgi?id=45372
> [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30


-- 
Anne van Kesteren
http://annevankesteren.nl/

From julian.reschke at gmx.de  Mon Jul  4 08:23:40 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 04 Jul 2011 17:23:40 +0200
Subject: [whatwg] EventSource - Handling a charset in the content-type
 header
In-Reply-To: <op.vx3lr3fn64w2qv@anne-van-kesterens-macbook-pro.local>
References: <AANLkTikOc3AbmjjD6rawG+z=8R_CVn7joLuAcXeeNVVM@mail.gmail.com>
	<op.vx3lr3fn64w2qv@anne-van-kesterens-macbook-pro.local>
Message-ID: <4E11DAFC.8060003@gmx.de>

On 2011-07-04 16:13, Anne van Kesteren wrote:
> ...
> Are we sure we want this strict checking of media type parameters? I
> always thought the media type itself was what strict checking should be
> done upon, but that its parameters were extension points, not points of
> failure.
> ...

The right thing for consistency with other uses of media types is to 
ignore unknown parameters.

Best regards, Julian

From pkasting at google.com  Mon Jul  4 15:41:13 2011
From: pkasting at google.com (Peter Kasting)
Date: Mon, 4 Jul 2011 15:41:13 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <20110703220117.6574dc02@desudesudesu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
Message-ID: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>

In general, I echo Michael's comment that we follow the notifications model.

On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> > Right now sites are actually much _more_ annoying without this
> > feature as they just blindly ask you to make them your protocol
> > handler every time.
>
> Can UAs not be expected to handle this properly, like they do with
> repeated alerts?


It's not a problem on the UA side, but the web page side.  Assume we want to
limit action on this call to cases where there's a user gesture (to prevent
bad sites from annoying you quite as easily, though I admit it is not a huge
roadblock).  Now you're Gmail and you want to give the user the ability to
register you as a mailto: handler.  So you whip up some button that will
make the rPH() call and some UI around it that calls attention to it.
 Without the ability to check if you're already the default handler, you
have to show this UI all the time, which is not at all appealing, or else
bury it somewhere, which means it will never get seen by most users.

PK

From robert at ocallahan.org  Mon Jul  4 20:16:27 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 5 Jul 2011 15:16:27 +1200
Subject: [whatwg] Proposal to remove a paragraph from canvas spec
In-Reply-To: <BANLkTi=jrzbaabPO3EVFeUHjjsYgfQuZPQ@mail.gmail.com>
References: <D2E08C12-27F2-499A-B32D-B8F7AB767FCB@apple.com>
	<BANLkTi=RBptXVV-RQ5dAHpq0ZzXR+Ttv_Q@mail.gmail.com>
	<Pine.LNX.4.64.1105130316510.19153@ps20323.dreamhostps.com>
	<BANLkTinqB_=RWAHbxtGbN3_ykxytN1Gkrg@mail.gmail.com>
	<BANLkTikz_MtvBfZirHDD6qzasfEeQy+4iw@mail.gmail.com>
	<Pine.LNX.4.64.1105130552040.16840@ps20323.dreamhostps.com>
	<BANLkTi=jrzbaabPO3EVFeUHjjsYgfQuZPQ@mail.gmail.com>
Message-ID: <CAOp6jLa6OU_s3BCFL1nKc4MLxXVTSMwxeF=EPFufLe05xpo-1w@mail.gmail.com>

On Tue, May 31, 2011 at 9:40 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, May 13, 2011 at 5:53 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Fri, 13 May 2011, Robert O'Callahan wrote:
>> >
>> > Can you put a note in the spec that we're thinking of changing this
>> > behavior, so developers are less likely to start depending on it, and
>> > we've got some cover in case it breaks some esoteric stuff that doesn't
>> > matter for compat?
>>
>> Done.
>>
>
> Thanks. I made this change on mozilla-central so it should appear in
> Firefox 7 about 18 weeks from now --- unless we detect that it breaks the
> Web.


It breaks the Web, so we're backing it out.

It turns out that a lot of canvas apps set up a shadow color and blur, do
some drawing, then disable the shadow by setting the blur to zero. With the
proposed change, those apps often render incorrectly, and worse, they often
render more slowly.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From timeless at gmail.com  Mon Jul  4 20:37:14 2011
From: timeless at gmail.com (timeless)
Date: Mon, 4 Jul 2011 23:37:14 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
Message-ID: <CAACrNNdpxgjCt=cPDy0UMTmfL_F3oUqaOmY-XLbq-tZgRZG_pA@mail.gmail.com>

Or we could use a <link> and have the UA only show the option to the
user if it feels like it. The UA could choose not to show it if it's
already active. It could also choose to only show it if the user has
visited repeatedly or whatever.

This is closer to ATOM discovery, but it's also a deployed style.

On 7/4/11, Peter Kasting <pkasting at google.com> wrote:
> In general, I echo Michael's comment that we follow the notifications model.
>
> On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp <
> nils at dieweltistgarnichtso.net> wrote:
>
>> > Right now sites are actually much _more_ annoying without this
>> > feature as they just blindly ask you to make them your protocol
>> > handler every time.
>>
>> Can UAs not be expected to handle this properly, like they do with
>> repeated alerts?
>
>
> It's not a problem on the UA side, but the web page side.  Assume we want to
> limit action on this call to cases where there's a user gesture (to prevent
> bad sites from annoying you quite as easily, though I admit it is not a huge
> roadblock).  Now you're Gmail and you want to give the user the ability to
> register you as a mailto: handler.  So you whip up some button that will
> make the rPH() call and some UI around it that calls attention to it.
>  Without the ability to check if you're already the default handler, you
> have to show this UI all the time, which is not at all appealing, or else
> bury it somewhere, which means it will never get seen by most users.
>
> PK
>

-- 
Sent from my mobile device

From richt at opera.com  Tue Jul  5 00:42:32 2011
From: richt at opera.com (Rich Tibbett)
Date: Tue, 05 Jul 2011 09:42:32 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
Message-ID: <4E12C068.3090701@opera.com>

Peter Kasting wrote:
> On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai<ojan at chromium.org>  wrote:
>
>> Do any browser vendors agree with this or have objections?
>
>
>> From my work on the Chrome UI side of this, I would very much like to see
> something like isRegistered().  This would allow sites to conditionalize
> requests for the protocol handler.  This is important to me because I would
> also like to experiment (after that point) with requiring a user gesture for
> this request (much like browsers typically require user gestures for
> window.open()), so sites cannot hammer the user with requests outside of
> some sort of interaction-based workflow.

I've also been thinking along these lines for things that require some 
user interaction at the chrome level.

The idea would be to emulate window.open functionality to the point that 
something happens only if a _user-initiated_ click event occurs. If an 
event is invoked by a script synthesizing its event via e.g. 
anchor.click() then that should not invoke any UI stuff. Only if 
window.open is invoked by a user does the popup blocker not kick-in and 
the popup pages open. It would be nice to have that same principle work 
for registerProtocolHandler.

FWIW, I proposed something to the effect you are describing in the W3C 
Contacts API [1]. window.open seems a little under-defined when it comes 
to the pseudo-standard behavior of blocking window.open calls outside of 
a user-initiated event.

br/ Rich

[1] http://www.w3.org/TR/contacts-api/#api-invocation-via-dom-events

From richt at opera.com  Tue Jul  5 01:16:40 2011
From: richt at opera.com (Rich Tibbett)
Date: Tue, 05 Jul 2011 10:16:40 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E12C068.3090701@opera.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<4E12C068.3090701@opera.com>
Message-ID: <4E12C868.3090304@opera.com>

Rich Tibbett wrote:
> Peter Kasting wrote:
>> On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai<ojan at chromium.org> wrote:
>>
>>> Do any browser vendors agree with this or have objections?
>>
>>
>>> From my work on the Chrome UI side of this, I would very much like to
>>> see
>> something like isRegistered(). This would allow sites to conditionalize
>> requests for the protocol handler. This is important to me because I
>> would
>> also like to experiment (after that point) with requiring a user
>> gesture for
>> this request (much like browsers typically require user gestures for
>> window.open()), so sites cannot hammer the user with requests outside of
>> some sort of interaction-based workflow.
>
> I've also been thinking along these lines for things that require some
> user interaction at the chrome level.
>
> The idea would be to emulate window.open functionality to the point that
> something happens only if a _user-initiated_ click event occurs. If an
> event is invoked by a script synthesizing its event via e.g.
> anchor.click() then that should not invoke any UI stuff. Only if
> window.open is invoked by a user does the popup blocker not kick-in and
> the popup pages open. It would be nice to have that same principle work
> for registerProtocolHandler.
>
> FWIW, I proposed something to the effect you are describing in the W3C
> Contacts API [1]. window.open seems a little under-defined when it comes
> to the pseudo-standard behavior of blocking window.open calls outside of
> a user-initiated event.

The behavior implied in [1] can be demoed against window.open here 
http://jsfiddle.net/nRJrz/3/

Should we document this psuedo-standard UA behavior wrt window.open? It 
would be nice to have a reference of this behavior on which to build 
other interactive UI experiences in the future.

Tested in Opera 11.5, Chrome 12, Firefox 5 and Safari 5.

>
> br/ Rich
>
> [1] http://www.w3.org/TR/contacts-api/#api-invocation-via-dom-events

From annevk at opera.com  Tue Jul  5 01:47:27 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 05 Jul 2011 10:47:27 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
Message-ID: <op.vx41dd0264w2qv@anne-van-kesterens-macbook-pro.local>

On Tue, 05 Jul 2011 00:41:13 +0200, Peter Kasting <pkasting at google.com>  
wrote:
> In general, I echo Michael's comment that we follow the notifications  
> model.

That means using http://dev.w3.org/2009/dap/perms/FeaturePermissions.html  
I take it? I am still somewhat dubious about that idea given  
http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html  
but on the other hand it is annoyingly hard to find an alternative. :(


-- 
Anne van Kesteren
http://annevankesteren.nl/

From jkorpela at cs.tut.fi  Tue Jul  5 12:44:34 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Tue, 05 Jul 2011 22:44:34 +0300
Subject: [whatwg] Using footer in blockquote for attribution
In-Reply-To: <op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
	<op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
Message-ID: <4E1369A2.9060106@cs.tut.fi>

2011-07-01 11:26, Simon Pieters wrote:

>>> Simon felt that ?Content inside a blockquote must be quoted from
>>> another source? excludes footer.
>
> s/footer/attribution/
>
> Indeed since it's a conformance requirement, in valid documents the
> content inside blockquote is quoted from another source. If the spec
> were to allow attribution inside blockquote, the above conformance
> requirement would need to be changed to allow it.

I was pretty sure that I had seen an example where a blockquote element 
contained an attribution in a footer. Alas, the ?living standard? does 
not seem to have a version history where I could conveniently check this 
out.

Admittedly, there is some logic in requiring that the content of 
blockquote be quoted from an external source and nothing more. I wonder 
whether this disallows common constructs like ?[foo]? to indicate that 
?foo? has been added for clarification and is not present in the source.

Anyway, having a blockquote element but no markup for attribution is 
very illogical. It is a prime rule in proper quotations, and widely even 
required by the copyright laws, that a quotation be accompanied by an 
indication of the quoted author and the source of the quotation.

I guess we are supposed to believe in the cite attribute?which is not 
supported by browsers or used by authors, and I don?t see how HTML5 
could break this vicious circle. (There is no obvious way how browsers 
_could_ support it, in a manner that makes sense, i.e. is understandable 
to users?there is no common paradigm for presenting attributions when 
you only have a URL to play with.) Besides, it?s clearly insufficient 
since only the URL can be specified, and surely not all works have URLs, 
and other types attributions are often far more permanent than URLs.

The actual usage of blockquote is mostly for indentation. In practice, 
it means ?indent,? though occasionally the motivation for indentation 
might be that the text is quoted. Any software that does something on 
the assumption that blockquote actually means quoted text will get 
things wrong more often than not.

Thus, the attempt at semantic purification will probably achieve 
nothing. People and authoring tools that use blockquote to indent will 
keep doing so. People who wish to use proper semantic markup will find 
out that they cannot: blockquote isn?t a working solution (it?s already 
tainted as presentational markup), and it?s even less so than 
previously, since you cannot even ?validly? include an attribution in 
the element but need to use some random element after the blockquote 
element.

>> However, I don't know if there's any specific way to mark this up.
>> It's a common pattern, so it would be a good candidate for adding
>> here:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#common-idioms-without-dedicated-elements
>>
>> It's useful to be able to put the author info in its own element so
>> that you can style it differently.

People can do that. But this does not result in any useful default 
rendering, and it does not help indexing robots at all.

For block quotations, a fresh start might be better than playing with 
the blockquote element, which really belongs to the ?compatibility 
area?: its default effect on rendering should be clearly specified, and 
it could be added that in previous specifications, it has been defined 
to mean a block quotation from an external source and it has been used 
in that meaning to some extent.

If you think that a semantic element for quotations is needed, then it?s 
best to add new elements, at least for a quotation and for an associated 
attribution.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From mpd at google.com  Tue Jul  5 12:58:22 2011
From: mpd at google.com (Michael Davidson)
Date: Tue, 5 Jul 2011 12:58:22 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
Message-ID: <CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>

For rPH, please don't require a user-initiated click for the call. That's
one very annoying thing about notifications - it takes users two clicks to
enable them, and every app has to find some suitable in-page UI to ask users
to make the first click. Since both notifications and rPH are confirmed by
the UA, it seems silly to require a user-initiated click. Prompting for
permissions is much less annoying than opening a new window, so I don't
think the same standards should apply. It's also very easy for users to
prevent sites from asking in the future by just denying the permission.

Michael


On Mon, Jul 4, 2011 at 3:41 PM, Peter Kasting <pkasting at google.com> wrote:

> In general, I echo Michael's comment that we follow the notifications
> model.
>
> On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp <
> nils at dieweltistgarnichtso.net> wrote:
>
> > > Right now sites are actually much _more_ annoying without this
> > > feature as they just blindly ask you to make them your protocol
> > > handler every time.
> >
> > Can UAs not be expected to handle this properly, like they do with
> > repeated alerts?
>
>
> It's not a problem on the UA side, but the web page side.  Assume we want
> to
> limit action on this call to cases where there's a user gesture (to prevent
> bad sites from annoying you quite as easily, though I admit it is not a
> huge
> roadblock).  Now you're Gmail and you want to give the user the ability to
> register you as a mailto: handler.  So you whip up some button that will
> make the rPH() call and some UI around it that calls attention to it.
>  Without the ability to check if you're already the default handler, you
> have to show this UI all the time, which is not at all appealing, or else
> bury it somewhere, which means it will never get seen by most users.
>
> PK
>

From bzbarsky at MIT.EDU  Tue Jul  5 13:14:55 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 05 Jul 2011 16:14:55 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>	<20110703220117.6574dc02@desudesudesu>	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
Message-ID: <4E1370BF.2050805@mit.edu>

On 7/5/11 3:58 PM, Michael Davidson wrote:
> Prompting for permissions is much less annoying than opening a new window

That's unclear.  Especially if permission grants are persistent.

> so I don't think the same standards should apply.

If anything, persistent permission grants should have a _higher_ bar 
than opening a temporary pop-up window...

-Boris

From mpd at google.com  Tue Jul  5 13:48:53 2011
From: mpd at google.com (Michael Davidson)
Date: Tue, 5 Jul 2011 13:48:53 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E1370BF.2050805@mit.edu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
Message-ID: <CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>

On Tue, Jul 5, 2011 at 1:14 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

>
>  so I don't think the same standards should apply.
>>
>
> If anything, persistent permission grants should have a _higher_ bar than
> opening a temporary pop-up window...
>
>
Granting permission, yes. But just asking for permission?

I say it's less annoying because (in Chrome, anyway), the infobar that asks
for permission to be granted isn't modal, and the user can continue with her
work.

The UA should make it as clear as possible what the consequences are of
granting persistent permissions and how to turn them off. But requiring an
in-page click to trigger the permission in the UA doesn't seem useful to me.
If, for example, Amazon wanted to show me desktop notifications I'd just
cilck "no". I'd rather do that once then have some persistent part of the
Amazon UI dedicated to asking me to let it ask for permissions.

Michael


> -Boris
>

From bzbarsky at MIT.EDU  Tue Jul  5 14:00:21 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 05 Jul 2011 17:00:21 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
Message-ID: <4E137B65.6080401@mit.edu>

On 7/5/11 4:48 PM, Michael Davidson wrote:
> Granting permission, yes. But just asking for permission?

If the asking for permission can happen in a context in which the user 
can't tell what's being asked for, it's a really bad idea...

> I say it's less annoying because (in Chrome, anyway), the infobar that
> asks for permission to be granted isn't modal, and the user can continue
> with her work.

This is the one reason that permission requests don't have that higher 
bar yet, yes.

> The UA should make it as clear as possible what the consequences are of
> granting persistent permissions

That's really difficult if the site asks for a bunch of permissions in a 
flurry.

-Boris

From mpd at google.com  Tue Jul  5 14:04:37 2011
From: mpd at google.com (Michael Davidson)
Date: Tue, 5 Jul 2011 14:04:37 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E137B65.6080401@mit.edu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
Message-ID: <CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>

On Tue, Jul 5, 2011 at 2:00 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/5/11 4:48 PM, Michael Davidson wrote:
>
>> Granting permission, yes. But just asking for permission?
>>
>
> If the asking for permission can happen in a context in which the user
> can't tell what's being asked for, it's a really bad idea...
>
>
Can you clarify what you mean? Requiring an in-page click doesn't mean that
the user understands either. Malicious pages can just lie in the text. Seems
like it's up to UAs to make sure users understand, and requiring an in-page
click won't help that.


>
>  I say it's less annoying because (in Chrome, anyway), the infobar that
>> asks for permission to be granted isn't modal, and the user can continue
>> with her work.
>>
>
> This is the one reason that permission requests don't have that higher bar
> yet, yes.
>
>
Sadly, they do for desktop notifications. Fortunately, they do not for rPH.
:)


>  The UA should make it as clear as possible what the consequences are of
>> granting persistent permissions
>
> That's really difficult if the site asks for a bunch of permissions in a
> flurry.
>
>
I'm all in favor of UAs throttling or doing whatever needs to be done in
order to help the user make educated decisions. I don't believe that
requiring an in-page click will help users at all.

Michael

-Boris
>

From bzbarsky at MIT.EDU  Tue Jul  5 14:12:08 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 05 Jul 2011 17:12:08 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
Message-ID: <4E137E28.4090307@mit.edu>

On 7/5/11 5:04 PM, Michael Davidson wrote:
>     If the asking for permission can happen in a context in which the
>     user can't tell what's being asked for, it's a really bad idea...
>
> Can you clarify what you mean? Requiring an in-page click doesn't mean
> that the user understands either. Malicious pages can just lie in the
> text. Seems like it's up to UAs to make sure users understand, and
> requiring an in-page click won't help that.

Yes, I'm not saying in-page click is a solution.  It works for popups, 
sort of, but I don't think it does for permission request notifications.

>     This is the one reason that permission requests don't have that
>     higher bar yet, yes.
>
> Sadly, they do for desktop notifications. Fortunately, they do not for
> rPH. :)

To be clear, I meant a higher bar than popup windows.

-Boris

From pkasting at google.com  Tue Jul  5 20:02:48 2011
From: pkasting at google.com (Peter Kasting)
Date: Tue, 5 Jul 2011 20:02:48 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E137E28.4090307@mit.edu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
Message-ID: <CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>

On Tue, Jul 5, 2011 at 2:12 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> Yes, I'm not saying in-page click is a solution.  It works for popups, sort
> of, but I don't think it does for permission request notifications.
>

To be truly honest, requiring a user gesture probably doesn't work for rPH()
because it doesn't actually work for window.open, or allowing executable
files to download, or any other purpose we've keyed off in UAs so far.
 That's because a click is not at all a good indicator of some sort of of
user understanding and intent.  The only thing it buys you is the
possibility that a visible UI change happens immediately after a user's
click and thus that in theory the user _might_ be able to guess that the
click triggered the UI change.

In any case I am not suggesting we spec anything regarding user gestures for
rPH() for now, it was an example of something we could try that isn't really
possible to consider unless we give webpages some sort of way to check
registration.

Also, I happen to agree with Boris that prompting for permissions is not, in
fact, less annoying than opening a new window.  Making prompts be non-modal
infobars does not mean they're suddenly friction-free and OK to show all the
time.  It's much harder to close an infobar, for example (no keyboard
shortcuts or OS allowances).  And the consequences of a user clicking "OK"
randomly to close a "grant permission" infobar are much greater than the
consequences of a user clicking a popup's close box.

PK

From robert at ocallahan.org  Tue Jul  5 21:51:28 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 6 Jul 2011 16:51:28 +1200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
Message-ID: <CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>

I don't think browsers need to prompt for registerProtocolHandler. Instead,
I would simply allow any site to register as a protocol handler for almost
anything, and remember all such registrations. When the user navigates to a
URI whose protocol has had an app newly registered for it since the last
such navigation, then prompt the user to choose which app to use. The UI for
that prompt would give prominence to the previously-seected app (if any),
followed by any newly registered app(s), and would remember the choice. The
UI could be modal or non-modal.

It seems to me that this approach would address the issues James Kozianski
raised in part 1 of his email, obviating the need for an isRegistered()
function.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From shwetankd at opera.com  Tue Jul  5 22:25:42 2011
From: shwetankd at opera.com (Shwetank Dixit)
Date: Wed, 06 Jul 2011 10:55:42 +0530
Subject: [whatwg] Peer-to-peer communication, video conferencing,
 <device>, and related topics
In-Reply-To: <4D836609.9020809@lachy.id.au>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
Message-ID: <op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>

On Fri, 18 Mar 2011 19:32:49 +0530, Lachlan Hunt  
<lachlan.hunt at lachy.id.au> wrote:

> On 2011-03-18 05:45, Ian Hickson wrote:
>> On Thu, 16 Sep 2010, Jonathan Dixon wrote:
>>> Further, it could be useful to provide a way to query the video source
>>> as to whether the camera is oriented relative to the screen (if the
>>> underlying system knows; consider a phone device with both a main  
>>> camera
>>> and self-view camera). This is needed to drive the decision on whether
>>> to do this horizontal flip or not. In fact, such an application may  
>>> want
>>> to somehow indicate a preference for the self-view camera when multiple
>>> cameras are present in the selection list. c.f. a movie-making app  
>>> which
>>> would prefer the outward facing camera.
>>
>> Interesting.
>>
>> In getUserMedia() the input is extensible; we could definitely add
>> "prefer-user-view" or "prefer-environment-view" flags to the method  
>> (with
>> better names, hopefully, but consider that 'rear' and 'front' are
>> misleading terms -- the front camera on a DSLR faces outward from the
>> user, the front camera on a mobile phone faces toward the user). The  
>> user
>> still has to OK the use of the device, though, so maybe it should just  
>> be
>> left up to the user to pick the camera? They'll need to be able to  
>> switch
>> it on the fly, too, which again argues to make this a UA feature.
>
> We could just add flags to the options string like this:
>
> "video;view=user, audio" or "video;view=environment, audio"
>
> It's worth pointing out that The HTML Media Capture draft from the DAP  
> WG uses the terms "camera" and "camcorder" for this purpose, but I find  
> these terms to be very ambiguous and inappropriate, and so we should not  
> use them here.
Just wanted to know whether there is any consensus on this or not? Mobile  
phones are coming out with dual cameras (front and back facing) and  
depending on the use case, the developer might want access to either the  
front or back one. (For example, for a simple camera app, a back facing  
will do, but for a web conferencing app, the front facing will be  
required). At least, the developer should be able to specify which one to  
enable by default, which then can be changed the user if needed.

Another question is flash. As far as I have seen, there seems to be no  
option to specify whether the camera needs to use flash or not. Is this  
decision left up to the device? (If someone is making an app which is just  
clicking a picture of the person, then it would be nice to have the camera  
use flash in low light conditions).
>
> http://dev.w3.org/2009/dap/camera/
>
>> Similarly for exposing the kind of stream: we could add to  
>> GeneratedStream
>> an attribute that reports this kind of thing. What is the most useful  
>> way
>> of exposing this information?
>
> I'm not entirely clear about what the use cases are for knowing if the  
> camera is either user-view or environment-view.  It seems the more  
> useful information to know is the orientation of the camera.  If the  
> user switches cameras, that could also be handled by firing orientation  
> events.
>
>> Lachlan Hunt wrote:
>>> There are some use cases for which it would be useful to know the
>>> precise orientation of the camera, such as augmented reality
>>> applications.  The camera orientation may be independent of the  
>>> device's
>>> orientation, and so the existing device orientation API may not be
>>> sufficient.
>>
>> It seems like the best way to extend this would be to have the Device
>> Orientation API apply to GeneratedStream objects, either by just having
>> the events also fire on GeneratedStream objects, or by having the API be
>> based on a pull model rather than a push model and exposing an object on
>> GeneratedStream objects as well as Window objects.
>
> This could work.  But it would make more sense if there were an object  
> representing the device itself, as in Rich's proposal, and for the  
> events to be fired on that object instead of the stream.
>
>> On Mon, 24 Jan 2011, Anne van Kesteren wrote:
>>>
>>> There is a plan of allowing direct assigning to IDL attributes besides
>>> creating URLs.
>>>
>>> I.e. being able to do:
>>>
>>>   audio.src = blob
>>>
>>> (The src content attribute would then be something like  
>>> "about:objecturl".)
>>>
>>> I am not sure if that API should work differently from creating URLs  
>>> and
>>> assigning those, but we could consider it.
>>
>> Could you elaborate on this plan?
>
> This is basically what Philip and I were discussing in the other thread  
> yesterday, where we avoid the unnecessary overhead of creating a magic  
> URL, and instead just assign the object directly to the src property.  
> This lets the implementation handle all the magic transparently in the  
> background, without bothering to expose a URLs string to the author.
>
> This is what we had implemented in our experimental implementation of  
> the <device> element, and now getUserMedia.
>
> i.e.
>
> <video></video>
> <script>
> var v = document.querySelector("video");
> navigator.getUserMedia("video", function(stream) {
>    v.src = stream;
>    v.play();
> });
> </script>
>
> The getter for v.src then returns "about:streamurl".
>
> My understanding is that we don't really want to have to implement the  
> create/revokeObjectURL() methods for this.
>
>> On Wed, 16 Feb 2011, Anne van Kesteren wrote:
>>> This is just a thought. Instead of acquiring a Stream object
>>> asynchronously there always is one available showing transparent black
>>> or some such. E.g. navigator.cameraStream. It also inherits from
>>> EventTarget. Then on the Stream object you have methods to request
>>> camera access which triggers some asynchronous UI. Once granted an
>>> appropriately named event is dispatched on Stream indicating you now
>>> have access to an actual stream. When the user decides it is enough and
>>> turns of the camera (or something else happens) some other  
>>> appropriately
>>> named event is dispatched on Stream again turning it transparent black
>> again.
>>
>> This is a very interesting idea.
>
> This suggests that there would be a separate property available for the  
> microphone, and any other input device.  This differs from the existing  
> spec, which allowed a single stream to represent both audio and video.
>
>> On Mon, 14 Mar 2011, Lachlan Hunt wrote:
>>> The API includes both readystatechange event, as well as independent
>>> events for play, paused and ended.  This redundancy is unnecessary.  
>>> This
>>> is also inconsistent with the design of the HTMLMediaElement API, which
>>> does not include a readystatechange event in favour on separate events
>>> only.
>>
>> I've dropped readystatechange.
>>
>> I expect to drop play and pause events if we move to the model described
>> above that pauses and resumes audio and video separately.
>
> It may still be useful to have events for this, if the event object had  
> a property that indicated which type of stream it applied to, or if  
> there were separate objects for both the audio and video streams.
>


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/

From roBman at mob-labs.com  Tue Jul  5 22:56:49 2011
From: roBman at mob-labs.com (Rob Manson)
Date: Wed, 06 Jul 2011 15:56:49 +1000
Subject: [whatwg] Peer-to-peer communication, video conferencing,
 <device>, and related topics
In-Reply-To: <op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
Message-ID: <1309931809.4058.148699.camel@robslapu>

There are also tablet devices with stereo cameras on the back and single
on the front too.  Stereo will become increasingly common.


roBman


On Wed, 2011-07-06 at 10:55 +0530, Shwetank Dixit wrote:
> On Fri, 18 Mar 2011 19:32:49 +0530, Lachlan Hunt  
> <lachlan.hunt at lachy.id.au> wrote:
> 
> > On 2011-03-18 05:45, Ian Hickson wrote:
> >> On Thu, 16 Sep 2010, Jonathan Dixon wrote:
> >>> Further, it could be useful to provide a way to query the video source
> >>> as to whether the camera is oriented relative to the screen (if the
> >>> underlying system knows; consider a phone device with both a main  
> >>> camera
> >>> and self-view camera). This is needed to drive the decision on whether
> >>> to do this horizontal flip or not. In fact, such an application may  
> >>> want
> >>> to somehow indicate a preference for the self-view camera when multiple
> >>> cameras are present in the selection list. c.f. a movie-making app  
> >>> which
> >>> would prefer the outward facing camera.
> >>
> >> Interesting.
> >>
> >> In getUserMedia() the input is extensible; we could definitely add
> >> "prefer-user-view" or "prefer-environment-view" flags to the method  
> >> (with
> >> better names, hopefully, but consider that 'rear' and 'front' are
> >> misleading terms -- the front camera on a DSLR faces outward from the
> >> user, the front camera on a mobile phone faces toward the user). The  
> >> user
> >> still has to OK the use of the device, though, so maybe it should just  
> >> be
> >> left up to the user to pick the camera? They'll need to be able to  
> >> switch
> >> it on the fly, too, which again argues to make this a UA feature.
> >
> > We could just add flags to the options string like this:
> >
> > "video;view=user, audio" or "video;view=environment, audio"
> >
> > It's worth pointing out that The HTML Media Capture draft from the DAP  
> > WG uses the terms "camera" and "camcorder" for this purpose, but I find  
> > these terms to be very ambiguous and inappropriate, and so we should not  
> > use them here.
> Just wanted to know whether there is any consensus on this or not? Mobile  
> phones are coming out with dual cameras (front and back facing) and  
> depending on the use case, the developer might want access to either the  
> front or back one. (For example, for a simple camera app, a back facing  
> will do, but for a web conferencing app, the front facing will be  
> required). At least, the developer should be able to specify which one to  
> enable by default, which then can be changed the user if needed.
> 
> Another question is flash. As far as I have seen, there seems to be no  
> option to specify whether the camera needs to use flash or not. Is this  
> decision left up to the device? (If someone is making an app which is just  
> clicking a picture of the person, then it would be nice to have the camera  
> use flash in low light conditions).
> >
> > http://dev.w3.org/2009/dap/camera/
> >
> >> Similarly for exposing the kind of stream: we could add to  
> >> GeneratedStream
> >> an attribute that reports this kind of thing. What is the most useful  
> >> way
> >> of exposing this information?
> >
> > I'm not entirely clear about what the use cases are for knowing if the  
> > camera is either user-view or environment-view.  It seems the more  
> > useful information to know is the orientation of the camera.  If the  
> > user switches cameras, that could also be handled by firing orientation  
> > events.
> >
> >> Lachlan Hunt wrote:
> >>> There are some use cases for which it would be useful to know the
> >>> precise orientation of the camera, such as augmented reality
> >>> applications.  The camera orientation may be independent of the  
> >>> device's
> >>> orientation, and so the existing device orientation API may not be
> >>> sufficient.
> >>
> >> It seems like the best way to extend this would be to have the Device
> >> Orientation API apply to GeneratedStream objects, either by just having
> >> the events also fire on GeneratedStream objects, or by having the API be
> >> based on a pull model rather than a push model and exposing an object on
> >> GeneratedStream objects as well as Window objects.
> >
> > This could work.  But it would make more sense if there were an object  
> > representing the device itself, as in Rich's proposal, and for the  
> > events to be fired on that object instead of the stream.
> >
> >> On Mon, 24 Jan 2011, Anne van Kesteren wrote:
> >>>
> >>> There is a plan of allowing direct assigning to IDL attributes besides
> >>> creating URLs.
> >>>
> >>> I.e. being able to do:
> >>>
> >>>   audio.src = blob
> >>>
> >>> (The src content attribute would then be something like  
> >>> "about:objecturl".)
> >>>
> >>> I am not sure if that API should work differently from creating URLs  
> >>> and
> >>> assigning those, but we could consider it.
> >>
> >> Could you elaborate on this plan?
> >
> > This is basically what Philip and I were discussing in the other thread  
> > yesterday, where we avoid the unnecessary overhead of creating a magic  
> > URL, and instead just assign the object directly to the src property.  
> > This lets the implementation handle all the magic transparently in the  
> > background, without bothering to expose a URLs string to the author.
> >
> > This is what we had implemented in our experimental implementation of  
> > the <device> element, and now getUserMedia.
> >
> > i.e.
> >
> > <video></video>
> > <script>
> > var v = document.querySelector("video");
> > navigator.getUserMedia("video", function(stream) {
> >    v.src = stream;
> >    v.play();
> > });
> > </script>
> >
> > The getter for v.src then returns "about:streamurl".
> >
> > My understanding is that we don't really want to have to implement the  
> > create/revokeObjectURL() methods for this.
> >
> >> On Wed, 16 Feb 2011, Anne van Kesteren wrote:
> >>> This is just a thought. Instead of acquiring a Stream object
> >>> asynchronously there always is one available showing transparent black
> >>> or some such. E.g. navigator.cameraStream. It also inherits from
> >>> EventTarget. Then on the Stream object you have methods to request
> >>> camera access which triggers some asynchronous UI. Once granted an
> >>> appropriately named event is dispatched on Stream indicating you now
> >>> have access to an actual stream. When the user decides it is enough and
> >>> turns of the camera (or something else happens) some other  
> >>> appropriately
> >>> named event is dispatched on Stream again turning it transparent black
> >> again.
> >>
> >> This is a very interesting idea.
> >
> > This suggests that there would be a separate property available for the  
> > microphone, and any other input device.  This differs from the existing  
> > spec, which allowed a single stream to represent both audio and video.
> >
> >> On Mon, 14 Mar 2011, Lachlan Hunt wrote:
> >>> The API includes both readystatechange event, as well as independent
> >>> events for play, paused and ended.  This redundancy is unnecessary.  
> >>> This
> >>> is also inconsistent with the design of the HTMLMediaElement API, which
> >>> does not include a readystatechange event in favour on separate events
> >>> only.
> >>
> >> I've dropped readystatechange.
> >>
> >> I expect to drop play and pause events if we move to the model described
> >> above that pauses and resumes audio and video separately.
> >
> > It may still be useful to have events for this, if the event object had  
> > a property that indicated which type of stream it applied to, or if  
> > there were separate objects for both the audio and video streams.
> >
> 
> 


From ian at hixie.ch  Wed Jul  6 08:51:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 Jul 2011 15:51:10 +0000 (UTC)
Subject: [whatwg] Version history
In-Reply-To: <4E1369A2.9060106@cs.tut.fi>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>
	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
	<op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
	<4E1369A2.9060106@cs.tut.fi>
Message-ID: <Pine.LNX.4.64.1107061549260.20871@ps20323.dreamhostps.com>

On Tue, 5 Jul 2011, Jukka K. Korpela wrote:
>
> Alas, the ?living standard? does not seem to have a version history 
> where I could conveniently check this out.

For the record, you can see every change online:

   Commit-Watchers mailing list: 
   http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

   Interactive Web interface:
   http://html5.org/tools/web-apps-tracker

   Subversion interface:
   http://svn.whatwg.org/

These tools are listed at the top of the specification under "Quick 
links".

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

From Olli.Pettay at helsinki.fi  Wed Jul  6 11:41:01 2011
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Wed, 06 Jul 2011 21:41:01 +0300
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
Message-ID: <4E14AC3D.9050604@helsinki.fi>

On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
> I don't think browsers need to prompt for registerProtocolHandler. Instead,
> I would simply allow any site to register as a protocol handler for almost
> anything, and remember all such registration

So all the ad sites (which are embedded via iframe or something) would
just register all the possible protocols so that some user might
accidentally use their site for protocol handling - especially if the 
site was the first one to register the protocol.
Doesn't sound too good.


-Olli

>  When the user navigates to a
> URI whose protocol has had an app newly registered for it since the last
> such navigation, then prompt the user to choose which app to use. The UI for
> that prompt would give prominence to the previously-seected app (if any),
> followed by any newly registered app(s), and would remember the choice. The
> UI could be modal or non-modal.
>
> It seems to me that this approach would address the issues James Kozianski
> raised in part 1 of his email, obviating the need for an isRegistered()
> function.
>
> Rob


From karld at opera.com  Wed Jul  6 12:57:42 2011
From: karld at opera.com (Karl Dubost)
Date: Wed, 6 Jul 2011 15:57:42 -0400
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
Message-ID: <625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>

Felix,

Le 29 juin 2011 ? 05:27, Felix Halim a ?crit :
> Suppose the content of the main page change very often (like news site).
> In this case, you don't want to cache the main page since the users
> want to see the latest main page, not the cached ones when they open
> the main page later.

Is there a web site which exhibits exactly the issue you are mentioning. 
Or could you set up a mini Web site exhibiting the issue. I have read the full thread, and I still do not understand what you are trying to solve. HTTP cache is about setting user interactions. There is no good values, just the values you decide that would make sense. 

HTTP Cache can already handle a lot of cases (offline/online) without even using AppCache, specifically when it is only content. 


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From robert at ocallahan.org  Wed Jul  6 17:53:11 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 7 Jul 2011 12:53:11 +1200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E14AC3D.9050604@helsinki.fi>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi>
Message-ID: <CAOp6jLZ0kGFWe9j0rA-5Xu6j+hd6QEMiirjuO-VOZMthyEgjbw@mail.gmail.com>

On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:

> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>
>> I don't think browsers need to prompt for registerProtocolHandler.
>> Instead,
>> I would simply allow any site to register as a protocol handler for almost
>> anything, and remember all such registration
>>
>
> So all the ad sites (which are embedded via iframe or something) would
> just register all the possible protocols so that some user might
> accidentally use their site for protocol handling - especially if the site
> was the first one to register the protocol.
> Doesn't sound too good.
>

I think you could sequester the new app options sufficiently that that would
not be worth doing.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From robert at ocallahan.org  Wed Jul  6 17:53:42 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 7 Jul 2011 12:53:42 +1200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAOp6jLZ0kGFWe9j0rA-5Xu6j+hd6QEMiirjuO-VOZMthyEgjbw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi>
	<CAOp6jLZ0kGFWe9j0rA-5Xu6j+hd6QEMiirjuO-VOZMthyEgjbw@mail.gmail.com>
Message-ID: <CAOp6jLan-TFU1H_n1J_X2BOvNBEWNu6bf1UY6hSr=yk_CMHwJQ@mail.gmail.com>

On Thu, Jul 7, 2011 at 12:53 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay <Olli.Pettay at helsinki.fi>wrote:
>
>> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>>
>>> I don't think browsers need to prompt for registerProtocolHandler.
>>> Instead,
>>> I would simply allow any site to register as a protocol handler for
>>> almost
>>> anything, and remember all such registration
>>>
>>
>> So all the ad sites (which are embedded via iframe or something) would
>> just register all the possible protocols so that some user might
>> accidentally use their site for protocol handling - especially if the site
>> was the first one to register the protocol.
>> Doesn't sound too good.
>>
>
> I think you could sequester the new app options sufficiently that that
> would not be worth doing.
>

You could also just deny all registerProtocolHandler() attempts from
non-toplevel frames.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From richt at opera.com  Wed Jul  6 18:38:06 2011
From: richt at opera.com (Rich Tibbett)
Date: Thu, 07 Jul 2011 03:38:06 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E14AC3D.9050604@helsinki.fi>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>	<20110703220117.6574dc02@desudesudesu>	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>	<4E1370BF.2050805@mit.edu>	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>	<4E137B65.6080401@mit.edu>	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>	<4E137E28.4090307@mit.edu>	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi>
Message-ID: <4E150DFE.9090602@opera.com>

Olli Pettay wrote:
> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>> I don't think browsers need to prompt for registerProtocolHandler.
>> Instead,
>> I would simply allow any site to register as a protocol handler for
>> almost
>> anything, and remember all such registration
>
> So all the ad sites (which are embedded via iframe or something) would
> just register all the possible protocols so that some user might
> accidentally use their site for protocol handling - especially if the
> site was the first one to register the protocol.
>

For registration, we could allow _auto-registration_ of protocol 
handlers only if a.) this is the first time the protocol is being 
registered and b.) when the registration request is coming directly from 
the top-most window context only (i.e. from a web page that users are 
actually visiting).

In all other cases (if you're the nth provider to attempt to register an 
already registered protocol handler or you're not requesting from 
window.top) then the UA would ask the user whether they wish to install 
this handler as the default for the given protocol or not (replacing the 
previous default handler).

For usage, the ideal situation would be for the user to click on a link 
and be auto-directed somewhere without having to select from multiple 
providers each time.

When the user wants to override the default protocol handler then the UA 
could allow e.g. ctrl-shift-click to force show the protocol handler 
dialog to the user. There the user would be free to select any handler 
that the UA has come in to contact with during the course of the user's 
previous browsing sessions (i.e. those handlers that the user decided 
not to set as defaults at the time).

Users should be able to easily detach protocol handlers from this list 
with either [delete] or [delete all handlers for this domain] on this 
interface.

- Rich

From whatwg.org at boblet.net  Wed Jul  6 21:53:59 2011
From: whatwg.org at boblet.net (Oli Studholme)
Date: Thu, 7 Jul 2011 13:53:59 +0900
Subject: [whatwg] The blockquote element spec vs common quoting practices
Message-ID: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>

Hi All,

I?ve been thinking about this line in the blockquote spec:
  ?Content inside a blockquote must be quoted from another source?
Depending on how literally you read this, it makes the following
common quoting practices annoying or impossible:

1. Typographically accepted changes to a quote, such as changing
capitalisation or adding ellipses to indicate missing prose
2. Adding quote metadata inline, such as notes and attribution
3. Adding quote metadata on a line after the block quote, but such
that it remains visually associated with the quote

I?ve found examples of these in the Chicago Manual of Style, web
pages, and books (on Google Books), and the results are here:
  http://oli.jp/example/blockquote-metadata/
These examples are annoying (3) or impossible (2, 1?) to achieve while
being conformant with the current spec.

I?ve outlined the problem and some potential solutions (with their
pros and cons) in:
  http://oli.jp/2011/blockquote/

I think the blockquote spec should be changed to allow the inclusion
of notes and attribution (quote metadata), perhaps by the addition of
a sentence like:
  ?Block quotes may also contain annotations or attribution, inline or
in an optional footer element?
This would change blockquote from being purely source content, to
being source content with possible metadata inline or in a footer.
However I don?t think that?s a problem, as these things increase the
value of the quoted content. I think a spec change is necessary to
accommodate common quoting practices.

Thanks for your time

peace - oli studholme


PS Background information:
http://html5doctor.com/blockquote-q-cite/
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13082
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032274.html
(?Using footer in blockquote for attribution? thread)

From pkasting at google.com  Wed Jul  6 22:06:56 2011
From: pkasting at google.com (Peter Kasting)
Date: Wed, 6 Jul 2011 22:06:56 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E150DFE.9090602@opera.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
Message-ID: <CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>

On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:

> For registration, we could allow _auto-registration_ of protocol handlers
> only if a.) this is the first time the protocol is being registered and b.)
> when the registration request is coming directly from the top-most window
> context only (i.e. from a web page that users are actually visiting).
>

We can't allow auto-registration in any case (nor was Robert suggesting
that), or the protocol is registered to whoever happens to ask first,
land-grab style.  This is doubly bad if (like Chrome) the UA registers the
protocol handler OS-wide.

When the user wants to override the default protocol handler then the UA
> could allow e.g. ctrl-shift-click to force show the protocol handler dialog
> to the user.


These sorts of click modifiers are all taken already.  (Ctrl-shift-click
means "open link in new foreground tab".)

Users should be able to easily detach protocol handlers from this list with
> either [delete] or [delete all handlers for this domain] on this interface.


Honestly I think we're getting a bit afield here.  It's not really the
WHATWG's purview to say precisely what kind of interface UAs should provide.
 Even my comments about possibly wanting to check for a user gesture were
intended as motivation for discussing various APIs, not as proposed specs.

PK

From felix.halim at gmail.com  Wed Jul  6 22:30:26 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Thu, 7 Jul 2011 13:30:26 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
Message-ID: <CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>

On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost <karld at opera.com> wrote:
> Felix,
>
> Le 29 juin 2011 ? 05:27, Felix Halim a ?crit :
>> Suppose the content of the main page change very often (like news site).
>> In this case, you don't want to cache the main page since the users
>> want to see the latest main page, not the cached ones when they open
>> the main page later.
>
> Is there a web site which exhibits exactly the issue you are mentioning.
> Or could you set up a mini Web site exhibiting the issue. I have read the full thread, and I still do not understand what you are trying to solve. HTTP cache is about setting user interactions. There is no good values, just the values you decide that would make sense.
>
> HTTP Cache can already handle a lot of cases (offline/online) without even using AppCache, specifically when it is only content.

This is a real example. I build a site like:

http://uhunt.felix-halim.net/id/339

That is is mine, and there is another ids like:

http://uhunt.felix-halim.net/id/32900
http://uhunt.felix-halim.net/id/1133

And thousands of other IDs.
Usually people look into few dozens IDs and not all thousands of them.

Each ID has a large-unique-frequently-changing data attached to them
(about 400KB).
Obviously, if I do a clean separation, and store the static framework
in AppCache, and the frequently changing data in localStorage, I can
only cache 10 ids data or so.

What I want is a 5MB "pageStorage" quota per page id. So that I can
store the frequently changing data to it rather than the shared
localStorage which uses the 5MB domain quota. In this case, any users
can essentially view a lot more ids without having to worry exceeding
the localStorage quota as long as I know that per page takes far less
than 5MB.

Of course I can implement my own cache revocation like deleting from
localStorage for ids that are less viewed. But this job is best left
to the browsers. Browsers can remove any page that is not viewed
anymore and the pageStorage associated to it.

Is that clear enough? on why we need pageStorage?

Now the problem is, how do you use AppCache + pageStorage?
They are conflicting each other in terms of URL.

I can use AppCache to cache the static framework I have to URL like:

http://uhunt.felix-halim.net/id

Then a pageStorage can be created for each different hashbang:

http://uhunt.felix-halim.net/id#339

That will give me 5MB for id = 339

And:

http://uhunt.felix-halim.net/id#32900

That will give me ANOTHER 5MB for id = 32900

and so on.

Then the browser can decide which URL are less frequently accessed and
destroy the pageStorage associated to it if the browser has no space
left.

Even if my script is malicious and I create unlimited number of
hashbang to get unlimited quota, the browser can just remove and store
only let say 100 latest or most frequently used hashbang. So, should
be perfectly fine to have pageStorage attached to a hashbang value.

This will help in web application developers to cleanly separates the
static from the dynamic and have nothing to worry about managing their
cache replacement policies, or worry about the limitation of 5MB of
localStorage or any other storage! This will also help the browser to
dissect what's static and what's dynamic! It's a WIN-WIN strategy for
all.


I think everybody knows that if I directly use AppCache to this url:

http://uhunt.felix-halim.net/id/339

What will happen?
I will have to refresh twice to get the latest statistics of my page!

Now, if somehow AppCache can make the main page ONLINE (that is, so
that I don't need to refresh twice). Then, all the discussions of
pageStorage above and quota becomes meaningless!



So, my proposals is either to make the main page of the AppCache
"ONLINE", or support pageStorage for hashbangs.

Do you have suggestions on this?

Felix Halim

From ojan at chromium.org  Wed Jul  6 22:30:39 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Wed, 6 Jul 2011 22:30:39 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
Message-ID: <CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>

All the arguments for registering handlers aside, it ought to be possible
for a website to provide some UI for deregistering. For example, many users
will expect to go into gmail's settings to stop having gmail handle email
links. Gmail's help section needing to give users instructions on each
browser's UI for deregistering is not a good user experience.

If they're going to have a UI for deregistering, it makes sense for them to
be able to show it only when actually registered.

On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com> wrote:

> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:
>
> > For registration, we could allow _auto-registration_ of protocol handlers
> > only if a.) this is the first time the protocol is being registered and
> b.)
> > when the registration request is coming directly from the top-most window
> > context only (i.e. from a web page that users are actually visiting).
> >
>
> We can't allow auto-registration in any case (nor was Robert suggesting
> that), or the protocol is registered to whoever happens to ask first,
> land-grab style.  This is doubly bad if (like Chrome) the UA registers the
> protocol handler OS-wide.
>
> When the user wants to override the default protocol handler then the UA
> > could allow e.g. ctrl-shift-click to force show the protocol handler
> dialog
> > to the user.
>
>
> These sorts of click modifiers are all taken already.  (Ctrl-shift-click
> means "open link in new foreground tab".)
>
> Users should be able to easily detach protocol handlers from this list with
> > either [delete] or [delete all handlers for this domain] on this
> interface.
>
>
> Honestly I think we're getting a bit afield here.  It's not really the
> WHATWG's purview to say precisely what kind of interface UAs should
> provide.
>  Even my comments about possibly wanting to check for a user gesture were
> intended as motivation for discussing various APIs, not as proposed specs.
>
> PK
>

From felix.halim at gmail.com  Wed Jul  6 22:51:50 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Thu, 7 Jul 2011 13:51:50 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
	<CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
Message-ID: <CAAbwPopg53+4QN07ny91pKQHCxePmfWRoG-rqhP3BmVe5gWVRw@mail.gmail.com>

On Thu, Jul 7, 2011 at 1:30 PM, Felix Halim <felix.halim at gmail.com> wrote:
> So, my proposals is either to make the main page of the AppCache
> "ONLINE", or support pageStorage for hashbangs.

Now when I think about the pageStorage again, actually we don't need hashbangs!

We can just say:

pageStorage['339'] = { here is my 5 MB JSON data for 339 }
pageStorage['32900'] = { here is my 5 MB JSON data for 32900 }
....

That should perfectly works well and the browser can silently destroy
the content of any of the less used ID, ANYTIME.

So, the usage is to not always assume the content of pageStorage
exists and treat it purely as cache that can be gone at anytime.

So, yes, we can use pageStorage to any page associated to the page URL
without the hashbang (as if the hashbang is stripped off). The quota
per key/value pair is 5 MB and can be removed by browser anytime.

How about that?

This can fulfil my need to get a clean separation.

Felix Halim

From svartman95 at gmail.com  Thu Jul  7 02:42:08 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 07 Jul 2011 09:42:08 +0000
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>	<625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
	<CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
Message-ID: <4E157F70.2070206@gmail.com>

?ann fim  7.j?l 2011 05:30, skrifa?i Felix Halim:
> On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost<karld at opera.com>  wrote:
> http://uhunt.felix-halim.net/id/339
>
I'll look into your site when I've slept, but FYI, you're mandated to 
provide a title for your document. You should probably provide a title 
of "uHunt", and append to the title's innerHTML as further information 
becomes available. [/nitpick]

From B.Lund at CableLabs.com  Thu Jul  7 09:14:04 2011
From: B.Lund at CableLabs.com (Bob Lund)
Date: Thu, 7 Jul 2011 10:14:04 -0600
Subject: [whatwg] Video feedback
In-Reply-To: <4EC563AF-5E2A-4EB3-9001-40E3BC86ADD3@netflix.com>
References: <BANLkTingvFktDxRmxOmAyg3+uGYAqfTxZg@mail.gmail.com>
	<Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
	<BANLkTimjnurfzJUWyMbrbKcLCXEcahWpTA@mail.gmail.com>
	<op.vwo7hgomsr6mfa@kirk>
	<BANLkTin9Vi56cKxAZr72a6n9tBZOutLZVw@mail.gmail.com>
	<op.vwqzuhj9sr6mfa@kirk>
	<BANLkTi=6D4Go88FEvYbrn=8-e=-KXxJ1pA@mail.gmail.com>
	<AE7B3985-285F-498E-8A4A-9CB37B6246B6@apple.com>
	<114DAD31379DFA438C0A2E39B3B8AF5D03011E47F1@srvxchg>
	<BANLkTimM1qLWchbYaDK-XfK58VFrNZwhow@mail.gmail.com>
	<op.vwspvqs3idj3kv@simon-pieterss-macbook.local>
	<BANLkTin866Nyp=F0E_PdRHG7jz-0sRai6g@mail.gmail.com>
	<527BC360-FAC3-4184-A8C3-7753921C0B78@apple.com>
	<4EC563AF-5E2A-4EB3-9001-40E3BC86ADD3@netflix.com>
Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D0302E065AF@srvxchg>


> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
> bounces at lists.whatwg.org] On Behalf Of Mark Watson
> Sent: Monday, June 20, 2011 2:29 AM
> To: Eric Carlson
> Cc: Silvia Pfeiffer; whatwg Group; Simon Pieters
> Subject: Re: [whatwg] Video feedback
> 
> 
> On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote:
> 
> >
> > On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote:
> >
> >> On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters <simonp at opera.com>
> wrote:
> >>> On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer
> >>> <silviapfeiffer1 at gmail.com> wrote:
> >>>
> >>>>> For commercial video providers, the tracks in a live stream change
> >>>>> all the time; this is not limited to audio and video tracks but
> >>>>> would include text tracks as well.
> >>>>
> >>>> OK, all this indicates to me that we probably want a
> "metadatachanged"
> >>>> event to indicate there has been a change and that JS may need to
> >>>> check some of its assumptions.
> >>>
> >>> We already have durationchange. Duration is metadata. If we want to
> >>> support changes to width/height, and the script is interested in
> >>> when that happens, maybe there should be a dimensionchange event
> >>> (but what's the use case for changing width/height mid-stream?).
> >>> Does the spec support changes to text tracks mid-stream?
> >>
> >> It's not about what the spec supports, but what real-world streams
> provide.
> >>
> >> I don't think it makes sense to put an event on every single type of
> >> metadata that can change. Most of the time, when you have a stream
> >> change, many variables will change together, so a single event is a
> >> lot less events to raise. It's an event that signifies that the media
> >> framework has reset the video/audio decoding pipeline and loaded a
> >> whole bunch of new stuff. You should imagine it as a concatenation of
> >> different media resources. And yes, they can have different track
> >> constitution and different audio sampling rate (which the audio API
> >> will care about) etc etc.
> >>
> >  In addition, it is possible for a stream to lose or gain an audio
> track. In this case the dimensions won't change but a script may want to
> react to the change in audioTracks.
> 
> The TrackList object has an onchanged event, which I assumed would fire
> when any of the information in the TrackList changes (e.g. tracks added
> or removed). But actually the spec doesn't state when this event fires
> (as far as I could tell - unless it is implied by some general
> definition of events called onchanged).
> 
> Should there be some clarification here ?
> 
> >
> >  I agree with Silvia, a more generic "metadata changed" event makes
> more sense.
> 
> Yes, and it should support the case in which text tracks are
> added/removed too.

Has there been a bug submitted to add a metadata changed event when video, audio or text tracks are added or deleted from a media resource?

Thanks,
Bob Lund

> 
> Also, as Eric (C) pointed out, one of the things which can change is
> which of several available versions of the content is being rendered
> (for adaptive bitrate cases). This doesn't necessarily change any of the
> metadata currently exposed on the video element, but nevertheless it's
> information that the application may need. It would be nice to expose
> some kind of identifier for the currently rendered stream and have an
> event when this changes. I think that a stream-format-supplied
> identifier would be sufficient.
> 
> ...Mark
> 
> >
> > eric
> >
> >


From E.Winkelman at cablelabs.com  Thu Jul  7 14:47:10 2011
From: E.Winkelman at cablelabs.com (Eric Winkelman)
Date: Thu, 7 Jul 2011 15:47:10 -0600
Subject: [whatwg] Video feedback
In-Reply-To: <Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
References: <BANLkTingvFktDxRmxOmAyg3+uGYAqfTxZg@mail.gmail.com>
	<Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
Message-ID: <3C0068AB22D70B4DA32B9A2A965968C773E84722B1@srvxchg>

On Thursday, June 02 Ian Hickson wrote:
>
> On Fri, 18 Mar 2011, Eric Winkelman wrote:
> >
> > For in-band metadata tracks, there is neither a standard way to 
> > represent the type of metadata in the HTMLTrackElement interface nor 
> > is there a standard way to represent multiple different types of 
> > metadata tracks.
> 
> There can be a standard way. The idea is that all the types of 
> metadata tracks that browsers will support should be specified so that 
> all browsers can map them the same way. I'm happy to work with anyone 
> interested in writing such a mapping spec, just let me know.

I would be very interested in working on this spec.  

CableLabs works with numerous groups delivering content containing a variety of metadata, so we have a good idea what is currently used.  We're also working with the groups defining adaptive bit rate delivery protocols about how metadata might be carried.

What's the next step?

Eric

From ian at hixie.ch  Thu Jul  7 15:33:14 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Jul 2011 22:33:14 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>

On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
> 
> I've been looking into Microdata specification and it struck me, that 
> crawling algorithm is so complex, when it comes to expressing simple 
> ideas.  I think that foremost the algorithm should be described in the 
> specification with explanation what it's supposed to do, before steps of 
> what exactly is to be done are written.

Yeah. Turns out the algorithms involved here are quite badly broken.

It was intended to expose the microdata graph as completely as possible 
while dropping anything that would introduce a loop, at the point where 
the first repetition would start (so A->B->C=>A would break at the =), 
in the API, in the JSON, and in the conformance rules. I didn't do a good 
job speccing that, though!

I've fixed the algorithms to make sense (I hope).


> Let's see, what are the properties of Microdata item from HTML element 
> with id=up from following HTML:
> 
> <div itemscope id=up itemprop=prop0>
>   <div itemscope id=down itemprop=prop1 itemref="up"></div>
> </div>

The element id=up has one property, prop1, whose value is an item on the 
element id=down. The element id=down has one property, prop0, whose value 
is the item on the element with id=up. If you crawl from id=up, my intent 
was to have the prop0 be dropped from the graph. If you crawl from 
id=down, my intent was to have prop1 be dropped from the graph. In 
addition, the document is intended to be non-conforming. If you serialise 
it for JSON, my intent was for the item on id=up to be the "top" one, and 
for it to have one property whose value is the item on id=down, which 
would itself have no values.

Note that the above would be non-conforming on its own because there are 
no top-level microdata items in the above snippet.


> I can imagine good usages of loops of Microdata items, for example "John 
> knows Amy, Amy knows John":
> 
> <div itemscope id="john" itemprop>
>   <div itemprop="friends" itemref="fred1 jenny2 amy1"></div>
> </div>
>
> <div itemscope id="amy1" itemprop>
>   <div itemprop="friends" itemref="john"></div>
> </div>
> 
> There's loop:  jonh->amy1->john->... .

itemref="" doesn't reference items for property values. It just references 
an element to get a list of properties for an item.

The example above is non-conforming because itemref="" can only be 
specified on an itemscope="" element, itemprop="" is not value without a 
value, and there's no top-level items.

The right way to do what you describe above is (provided the vocabulary 
is defined in a way that supports this):

 <div itemscope itemid="http://example.com/john" itemtype="...">
   <meta itemprop="friends"
         content="http://example.com/fred1 http://example.com/jenny2 http://example.com/amy1">
 </div>

 <div itemscope itemid="http://example.com/amy1" itemtype="...">
   <meta itemprop="friends"
         content="http://example.com/john">
 </div>


> If the loop is to be excluded, and thus recursion, the same data could 
> be written as:
> 
> <div itemscope>
>   <div itemprop=addressbook_id>1</div>
>   <div itemprop=name>John</div>
>   <div itemprop=knows>2</div>
> </div>
>
> <div itemscope>
>   <div itemprop=addressbook_id>2</div>
>   <div itemprop=name>Amy</div>
>   <div itemprop=knows>1</div>
> </div>.

That's another way to do it, yes.


> maybe with some <meta> instead of <div> or more verbosely:
> 
> <p itemscope itemid="#john" id="#john">John knows <a 
> itemprop="http://xmlns.com/foaf/0.1/knows" href="#amy">Amy</a>.</p>
>
> <p itemscope itemid="#amy" id="#amy">Amy knows <a 
> itemprop="http://xmlns.com/foaf/0.1/knows" href="#john">John</a>.</p>

That works too.


> The problem I'm addressing revolves around meaning of link between 
> itemref and id attributes.  Is it meant to be a part of Microdata data 
> model?

No, it's just syntactic sugar to allow pages to use microdata without 
having to twist their markup into a pretzel to make it work.


> Or maybe it is introduced to cope with the fact that Microdata graph is 
> defined on top of existing data, which is something completely 
> different, and is meant to be rendered to the user (that is on top of 
> HTML tree)?

Right.


> So the meaning of itemref attribute should also hint interpretation of 
> it inside the specification.

Done.


On Fri, 10 Jun 2011, Philip J?genstedt wrote:
> 
> I don't think the spec needs to be giving suggestions for efficient 
> implementation for live collections, because we inevitable won't 
> implement exactly that algorithm anyway.

The aim wasn't to give suggestions for efficient implementations. The aim 
was to give algorithms for which an efficient implementation existed, 
rather than requiring something nigh on impossible to implement 
efficiently. The aim wasn't reached, though, in that the algorithm in the 
spec was just completely bogus. Sorry about that.


On Tue, 28 Jun 2011, Tomasz Jamroszczak wrote:
> 
> For sure itemRef attribute of Microdata have to stay, because it makes 
> possible separation of data (the Microdata item properties, the 
> semantics) and view (where contents of those properties should be laid 
> out for browser user). Without itemRef, Microdata becomes "Picodata".

That may not be all bad. :-)

You know something is done not when there's nothing new to add, but when 
there's nothing left to remove.


> But then, what to do when translating Microdata to other format, such as 
> stringification to JSON in Drag'n'drop?  The JSON itself is quite 
> primitive when it comes to stringification loops - it just throws an 
> exception.  We thought we'll be more flexible.  We'll make 
> stringification "as best as possible", and cutting only the last 
> offending link of a cycle.  See 
> http://people.opera.com/tjamroszczak/microdata/microdata-loops.png . 
> Unfortunately it means that items which belong to Microdata item loops 
> sometimes will lose properties, and it depends on from where the cycle 
> was reached (see point A1 and A2 in the image).

This was actually the intent of the spec originally, so it works out well 
that this is what you've opted for!

I've done the same in the spec.


On Wed, 29 Jun 2011, Philip J?genstedt wrote:
> 
> Note also that other algorithms defined in terms of items and their 
> properties need to handle loopiness in some way. That's currently RDF, 
> vCard and iCal conversion. Perhaps something like "loopy item" could be 
> defined and those algorithms could skip loopy items wherever they occur? 
> Simply failing is also an acceptable solution, IMO.

I fixed vCard with a patch that just outputs "AGENT;TYPE=VCARD:ERROR" in 
the case of a loop. (Can only happen if the input is non-conforming, so it 
doesn't matter if the output is non-conforming.)

The vEvent stuff was already loop-safe.

The JSON algorithm now ends the crawl when it hits a loop, and replaces 
the offending duplicate item with the string "ERROR".

The RDF algorithm preserves the loops, since doing so is possible with 
RDF. Turns out the algorithm almost did this already, looks like it was an 
oversight.



On Wed, 8 Jun 2011, Dan Brickley wrote:
> 
> Section '5.2.3 Names: the itemprop attribute' states something important 
> about Microdata's data model,
> 
> "Within an item, the properties are unordered with respect to each 
> other, except for properties with the same name, which are ordered in 
> the order they are given by the algorithm that defines the properties of 
> an item."

(Which is tree order, currently, though it wasn't always so.)


> ... and gives an example "In the following example, the "a" property
> has the values "1" and "2", in that order,  ...
>
> <div itemscope itemref="x">
>  <p itemprop="b">test</p>
>  <p itemprop="a">2</p>
> </div>
>
> <div id="x">
>  <p itemprop="a">1</p>
> </div>"
> 
> However '5.2.1 The microdata model' does not mention anything of this 
> data model feature. If property values (for some specific property/item 
> context), this should be mentioned when introducing the data model; if 
> only by copying or linking the above sentence ("Within an item, ...").

I've added a brief sentence mentioning that names aren't ordered but 
values of a name are.


> Is the expectation that Microdata vocabulary authors can decide whether 
> such ordering is meaningful, when they define / describe their 
> properties?

Yes.


> For example, in academic publishing where they care about being first 
> named author, the ordering of 'itemprop="author"' might seem to matter.

Right.


> 5.2.3 suggests that the ordering information is at least preserved in 
> Microdata's data model. If someone creates an 'author' property for 
> Microdata, should they state that property ordering is meaningful, or is 
> that not their decision?

They can state that the order is not meaningful.

It's similar to how the order of children element nodes in an XML element 
can be important or not, as defined by the vocabulary.


On Sat, 11 Jun 2011, Brett Zamir wrote:
> On 4/27/2011 9:06 PM, Benjamin Hawkes-Lewis wrote:
> > On Wed, Apr 27, 2011 at 3:54 AM, Brett Zamir<brettz9 at yahoo.com>  wrote:
> > > Thanks for the references. While this may be relevant for the likes 
> > > of blogs and other documents whose requirements for semantic density 
> > > is limited enough to allow such reshaping for practical effect and 
> > > whose content is reshapeable by the content creator (as opposed to 
> > > republishing of already completed books), for more semantically 
> > > dense content, such as the types of classical documents marked up by 
> > > TEI, it is simply not possible to expose text for each bit of 
> > > semantic information or to generate new text to meet that need. And 
> > > of course, even with microformats/microdata as it is now, the 
> > > semantic content itself is not necessarily exposed just because text 
> > > is visible on the page.
> > > 
> > > The issue of discoverability is I think more related to how it will 
> > > be consumed or may be consumed. And even if some pieces of 
> > > information are less discoverable, it does not mean that they have 
> > > no value. For such rich documents, a lot of attention is being paid 
> > > to these texts since they are themselves considered important enough 
> > > to be worth the time.
> > > 
> > > If the Declaration of Independence of the United States was marked 
> > > up with hidden information about prior emendations, their likely 
> > > reasons, etc., or about suspected authors of particular passages, or 
> > > the United Nations Declaration of Human Rights were marked up to 
> > > indicate which countries have expressed reservations 
> > > (qualifications) about which rights, while a browsing application or 
> > > query tool ought to be able (optionally) expose this hidden 
> > > information, there is no automatic need for the markup to be 
> > > polluted with extra (hidden) (and especially URI-based or other 
> > > non-textual) tags when an attribute would suffice.
> > > 
> > > For things that are truly important, there may be a great deal of 
> > > care put into building up many layers which are meant to be peeled 
> > > away, and it is worth allowing some of that information 
> > > (particularly the non-textual information, e.g., the conditions of 
> > > authorship, publisher, etc.), especially which the original 
> > > publication did not expose, to be still selectively revealed to 
> > > queries and deeper browsing.
> > > 
> > > If a site like Wikisource (the online library sister project of 
> > > Wikipedia's) would be able to offer such officially sanctioned 
> > > semantic attributes, classic texts could become enhanced in this way 
> > > over time, with the wiki exposing the hidden semantic information, 
> > > which indeed may not be as important as the visible text, but with 
> > > queries by interested to users, any problems in encoding could be 
> > > discovered just as well.
> >
> > Your email challenges the principle of visible data on four different 
> > grounds:
> > 
> > 1. You note even proponents of visible data do not always show their 
> > data. But the microformats community only endorse hidden metadata for 
> > annotating human-friendly visible data (e.g. "mercredi prochain") with 
> > a machine-readable equivalent (e.g. an ISO 8601 formatted date). They 
> > do not endorse hidden metadata without visible equivalents against 
> > which it can be cross-checked.
> > 
> > 2. You imply editorial effort can offset the error-proneness of hidden 
> > metadata. But the same extraordinary editorial effort would yield even 
> > greater accuracy if it went towards creating visible data rather than 
> > hidden metadata.
> > 
> > 3. You claim tool-assisted queries by end-users against the hidden 
> > metadata will reveal errors at the same rate as visible data. But this 
> > is doubtful, in so far as many queries will obfuscate context whereas 
> > simply reading through the text encourages serendipitous error 
> > discovery. For example, I could issue a query asking what proportion 
> > of the Declaration of Independence is suspected to be authored by John 
> > Adams. A percentage answer would not reveal the odd misattributed 
> > passage. By contrast, if I'm a scholar of the Declaration and am 
> > reading through the text and I happen to see a suspiciously 
> > Jeffersonian passage visibly attributed to John Adams, I'm much more 
> > likely to notice the error.
>
> Of course a visible attribution is helpful, but one cannot possibly 
> visibly represent all information one might wish to add, especially if 
> one does not wish to clutter the view hopelessly. Meta-data can be 
> available to searching, and if search engines don't wish to take 
> advantage of it, at least individual document queries can do so.

The question is, will enough "individual document queries" do so to make 
it worth it?

Or to put it another way, is there sufficient compelling need for a way to 
represent all the information one _might_ wish to add in a non-visible yet 
generically processable manner?

It's not clear to me that there is. What are the concrete use cases? Is 
anyone actually interested in marking up the United Nations Declaration of 
Human Rights in HTML to indicate which countries have expressed 
reservations in a manner intended to be processable by tools not 
specifically designed for that use case?

One can definitely imagine that someone might want to create an 
application specifically for marking up and exposing such information, but 
if it's a self-contained app, the data-* feature is sufficient. The 
question is, is anyone actually trying to write a generic app of this 
nature right now? More, even: are enough people doing so that we need to 
solve this problem?


> > 4. You assert that it is not viable to make multiple layers of rich 
> > data visible in a single view. I'd make the counterargument that on 
> > the web, unlike in print, it is economical to dynamically construct 
> > different views and filters of a document and its various visible data 
> > streams on the client, on the server, on the client, or on some 
> > combination of the two. The HTML5 specification itself is a great 
> > example of this. The source text is kept in a repository that stores 
> > changes to the text, along with date and rationale. Multiple views of 
> > this source text are then generated serverside: the source text is 
> > carved up into multiple draft specs for W3C and a single mammoth 
> > specification for WHATWG. The HTML spec is provided in a 
> > browser-crashing single document view and in a multipage view. On top 
> > of this, there is clientside filtering in the form of an in-page 
> > control that can produce a web author view by hiding technical text 
> > aimed at browser vendors.
> 
> Sometimes projects simply wish to make the meta-data available and let 
> consumers determine how to display it.

Which projects? Are they unable to do it today? What are their concrete 
needs and desires? What level of user engagement are they getting?


> If someone has a good idea about how to manage the display (or editing) 
> of meta-data, all power to them, but this does not mean that the 
> original document creator should be forced to create every possible use 
> when their interest and responsibility may simply be properly defining 
> the semantics in use.

It is not a goal of this effort to address the desires of people who 
simply want to mark up data without a concrete use case. If anything, it 
has been our goal to _discourage_ such authors, so as to help them focus 
their efforts on work that has an actual immediate end-user benefit, 
rather than merely a theoretical future payoff.


> In any case, the specification has allowed in-body <meta/> as you point 
> out, so hidden meta-data is thankfully available to authors.

Indeed. Also, data-*="" for in-page applications, and <script> for in-page 
data blobs, and of course it's also possible to reference external data 
files for processors.

If these are sufficient for what people want to do, then our job is done.


> > If you're keen on using the TEI vocabulary to meet the Wikisource use 
> > case, there's no particular reason why you couldn't convert Wiki 
> > markup to TEI source text, serve TEI directly over the web, and also 
> > generate various HTML views of visible rich data from the TEI (for 
> > example, with XSLT). The Perseus project uses TEI and HTML in 
> > combination a bit like that:
> > 
> > http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3atext%3a1999.01.0199
>
> Thanks, but I'm not a fan of custom solutions, since, similar to the 
> "many eyes" view you are espousing for exposing meta-data visually, I 
> believe such solutions leave different semantic communities out of the 
> benefits of utilizing and contributing to general purpose solutions.

It isn't a "custom solution". As far as I can tell, it's using TEI for its 
intended purpose. It's a generic TEI solution.


> For example, I'd like TEI to be serialized such that it can take 
> advantage of tools exclusive to HTML such as WYSIWYG editors, wikis 
> which whitelist only certain elements and attributes, etc., and have the 
> TEI community engaged in enhancing the same Microdata schemas (such as 
> those detailed on http://schema.org) available to all on the web.

Why? Why not use TEI tools? Why not XML tools? Or JSON tools?

We can't possibly design HTML on the assumption that every other language 
is going to be mapped to it to use its tool. That is a completely 
unscalable solution. HTML is a generic document and application platform, 
it's not feasible for it to be everything for every purpose. It's hard 
enough to make it good for writing Web apps and docs, let alone making it 
good for everything! :-)


> > But let's say you were determined to serve up a single HTML document 
> > with lots of hidden metadata. None of microformats, microdata, and 
> > RDFa were designed to do this. But both microdata and RDFa allow you 
> > to do so in a conforming manner using the @content attribute. In 
> > WHATWG HTML, this is restricted to the "meta" element, but the "meta" 
> > element is now allowed amidst body text so it can apply to individual 
> > sections of the document, rather than just the whole document. In W3C 
> > HTML+RDFa, the @content attribute is allowed on any element.
> > 
> > In other words, where your examples currently abuse the skinning layer 
> > ("display: none") to preserve logical text flow, they should actually 
> > be using meta at content instead; there is no need for "ugly hacks" even 
> > if the markup becomes more verbose than you might like.
>
> I had not been aware of <meta/> being available in-body, thank you.
> 
> However, my item-* proposal, besides being more succinct in the case of
> attribute content, allows for targeted styling of elements which <meta/>
> currently would not.
> 
> For example, to take a water-damaged text (e.g., for the TEI element
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-damage.html ) which in
> TEI could be expressed as:
> 
> <damage agent="water" xmlns="http://www.tei-c.org/ns/1.0/">Some water damaged
> words</damage>
> 
> might be represented currently in Microdata as:
> 
> <span itemprop="damage" itemscope="" itemtype="http://www.tei-c.org/ns/1.0/">
> <meta itemprop="agent" content="water"/>
>     Some water damaged words
> </span>

It's not clear to me what the context of this is, but itemprop="damage" is 
probably wrong in the above unless this is intended to be in another item.


> But there is no "parent combinator" selector such that the following (also
> cumbersome) selector would work:
> 
> span[itemprop=damage] <  meta[itemprop=agent][content=water] {
>     text-shadow: 2px 2px 16px #2b2b2b;
> }

You really don't want to be using CSS on microdata, that way lies madness. 
Microdata doesn't define a mapping from its properties to the elements in 
the page. There is no semantic difference between these three lines at the 
microdata level:

   <p itemscope><span itemprop=a>foo</span></p>

   <p itemscope itemref=x>foo</p> <meta id=x itemprop=a content=foo>

   <meta id=x itemprop=a content=foo> <p itemscope itemref=x>foo</p>

So if you use CSS to style this, your styles are dependent on a 
non-semantic syntactic detail, which is very brittle.


> In my item-* proposal, it would be nicely expressed as:
> 
> <span itemprop="damage" item-agent="water" itemscope=""
> itemtype="http://www.tei-c.org/ns/1.0/">
>     Some water damaged words
> </span>
> 
> which works fairly well in CSS too:
> 
> span[itemprop=damage][item-agent=water] {
>     text-shadow: 2px 2px 16px #2b2b2b;
> }
> 
> This offers a conveniently condensed syntax, while also ensuring 
> discoverability of the prefixed Microdata attributes.
> 
> Especially as more attributes are needed (kept simple for this example), 
> it becomes easier to handle (and cleaner), even if it admittedly adds a 
> little work to crawlers to detect this different approach.

I don't really understand what this is doing.


> > Note HTML also has other extension points that are available, 
> > including dumping data in script elements,
>
> Not a standard approach and not likely to work in restricted 
> whitelisting environment.

It is a standard approach.


> > dumping data in class attributes,
>
> Suffers, as schema.org implies at http://schema.org/docs/faq.html#14 , 
> from a lack of extensibility/namespacing.

If your problem is you want to style something, then the class="" 
attribute is exactly the way to do it. It's not clear why you need 
extensibility or namespacing here if your problem is styling.


> > and mixing XHTML and other XML vocabularies in a compound document.
> 
> Suffers from a lack of support in the HTML serialization

Sure. HTML suffers from a lack of support in the XML serialization, too. 
Why is that a problem?


> and from a lack of a uniform means of discoverability.

Not sure what this means. Namespaces are quite discoverable.


> > Beware that even where a conforming hidden metadata mechanism is 
> > provided, consumers of such documents may well distrust hidden 
> > metadata that is not a machine-readable equivalent to visible data. 
> > For example, Google say:
> > 
> > "In general, Google won't display content that is not visible to the 
> > user. In other words, don't show content to users in one way, and use 
> > hidden text to mark up information separately for search engines and 
> > web applications. You should mark up the text that actually appears to 
> > your users when they visit your web pages."
> > 
> > http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=146898
> 
> I'm skeptical that this would exclude (or need to exclude) 
> namespace-aware Microdata searches since the user is clearly seeking 
> this information explicitly.

Hidden information is often out of date or wrong. There's a strong 
incentive for search tools to ignore hidden information and rely only on 
visible data.

The user doesn't want bad data, even if in practice that's what it appears 
the user is asking for.


On Mon, 13 Jun 2011, Brett Zamir wrote:
> 
> With the likes of Google offering Microdata-aware searches, I think it 
> makes a whole lot of sense to allow rich documents such as TEI ones to 
> enter as regular document citizens of the web, whereby the limited 
> resources of such specialized semantic communities can leverage the 
> general purpose and better-supported services such as Google's Microdata 
> tool, while also having their documents editable within the likes of 
> WYSIWYG HTML text editors, and stored on sites such as discussion forums 
> or wikis where only HTML may be allowed and supported.
> 
> I think such a focus would also enable the TEI community to benefit from 
> reusing search-engine-recognized schemas where available, as well as 
> helping the web community build new schemas for the unique needs of 
> encoding academic texts.

I don't understand what you're proposing here. The schema.org microdata 
stuff isn't generic, it's specific vocabularies.


On Mon, 13 Jun 2011, Tab Atkins Jr. wrote:
> 
> Additionally, while we recognize that non-visible data is sometimes 
> necessary to embed, we'd like to discourage its use as much as possible 
> (in general, non-visible data rots much faster).  One way to do that is 
> to make the syntax slightly cumbersome or ugly - when you really need 
> it, you can use it, but your aesthetic sense will keep it from being the 
> first tool you reach for.  So, making it easier or prettier to embed 
> non-visible triples is actually something we'd like to avoid if we can.

Indeed.


On Wed, 22 Jun 2011, Brett Zamir wrote:
>
> HTML could have been created without attributes too--but if one is going 
> to use it frequently enough, concision is a big selling point (as is 
> non-redundant styleability).

HTML is hardly concise. :-)


> People who are going to go to the trouble of adding semantics which do 
> nothing for visual rendering are probably going to have some idea of 
> what they are doing.

Do you have data to support this?

From what I can tell, it's not an accurate statement.


> It could be useful to a search engine. If I remembered that some text 
> was water-damaged, I could specify that I only wanted to look for 
> water-damaged text (with the TEI itemtype).

Why not just search for the English text "water-damaged"?


On Tue, 14 Jun 2011, Philip J?genstedt wrote:
>
> A question came up in the Schema.org discussion group today:
> 
> http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/69b733066ae7aaaa?pli=1
> 
> The question was how to fix http://www.2gc.co.uk/a2gc-people to link 
> together properties that were in different parts of the document into a 
> single item. The answer is of course to use itemref, here simplified 
> even further to illustrate:
> 
> <div itemscope itemtype="http://schema.org/Organization">
>  <p itemprop="name">2GC Active Management</p>
>  <div class="photogrid">
>    <div class="photoitem" itemprop="employees" itemscope itemtype="http://schema.org/Person" itemref="GL">
>      <img itemprop="image" src="/images/GJGL.jpg" alt="Gavin Lawrie - Managing Director">
>      <div itemprop="name">Gavin Lawrie</div>
>      <div itemprop="jobTitle">Founder &amp; Managing Director</div>
>    </div>
>    <!-- more employees -->
>  </div>
>  <div id="bio-display" itemscope>
>    <div class="bio-text" id="GL"><dl>
>      <dt>Gavin Lawrie: Founder &amp; Managing Director</dt>
>      <dd itemprop="description">Gavin is ...</dd>
>    </dl></div>
>    <!-- more employees -->
>  </div>
> </div>
> 
> The ugly: <div id="bio-display" itemscope>. That itemscope is there only 
> to prevent the description property of the Person from applying to the 
> organization, and does so because the algorithm to crawl the properties 
> of an item stops at itemscope. This is a silly hack, because it is not 
> an item, and I don't expect many people would find this solution even if 
> they knew about the problem.

This solution is not really a solution, since it generates a new item.

I'd suggest instead putting the top-level itemscope onto a <meta> element, 
and using itemref to link to the first <p> and the class="photogrid" <div>.


> Should we have yet another property like "itemunscope" that stops the 
> crawl algorithm but does not create a new item?

It doesn't seem necessary. Just don't nest properties in items they don't 
apply to.


> Could we tweak the validity definitions so that this kind of thing would 
> cause validators to complain, or should we leave it completely to 
> vocabulary-specific validators to spot this kind of thing? (They can't 
> if they operate on the microdata level and not DOM level, which I think 
> they should.)

It's not clear exactly what we would make non-conforming.


On Sun, 26 Jun 2011, John Giannandrea wrote:
>
> In the user feedback from the schema.org proposal, which uses microdata 
> as its syntax, we have seen several use cases that would seem to require 
> multiple itemtypes per itemscope.

The type of an item is the vocabulary the item uses. It doesn't make sense 
to use more than one vocabulary, as far as I can tell.

If an item defined with a particular vocabulary belongs to several things 
(e.g. a person that is a lawyer and an engineer), then you just want a new 
property that lists the categories the item belongs to.


> We suggest that itemtype be changed to allow multiple space separated 
> types (just like itemprop), but only if the origin domain of the types 
> is the same.  This would allow a vocabulary provider to allow multiple 
> types and to take responsibility for what the property vocabulary 
> definition is in the context of more than one type.

I like this idea, but as others have pointed out, it seems bad to 
arbitrarily restrict this kind of extension to same-domain types. Better, 
IMHO, to not overload itemtype="" in this way, and to just use a new 
property, as here:

   <div itemscope itemtype="http://example.com/">
     <meta itemprop="kind" content="A B">
     ...
   </div>


On Tue, 28 Jun 2011, John Giannandrea wrote:
> 
> Cross-origin extensions can still be handled with full URIs for the 
> extension properties.

This would prevent extension vocabularies from using short names, which 
seems like a serious limitation. (Or it would require that vocabularies 
define both a short and long name for each property, which would be a 
really bad idea, IMHO. Implementations rarely handle such cases well, and 
the microdata model doesn't define the order of multiple values if they 
use different but equivalent names, for example. You should never have 
multiple names with the same semantic.)


> On Tue, Jun 28, 2011 at 6:53 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> >   <div itemscope itemtype="http://example.com/">
> >     <meta itemprop="kind" content="A B">
> >     ...
> >   </div>
> 
> How does "kind" relate to "type"?  Would it be the case that kind 
> informs the short itemprop names also? Is this the same proposal as 
> having an itemprop="type" which means the same thing as itemtype?

The idea here is just to have one vocabulary, and then say what categories 
of things the item falls in.


On Tue, 28 Jun 2011, Lin Clark wrote:
>
> Itemtype in my example is like 'kind' in your example. You are right, it 
> is basically a privileged property.
> 
> Because the words type and kind are pretty synonymous (groups of things 
> that have common characteristics), I would think that specifying an 
> itemtype and then specifying a separate kind might be confusing to 
> users, just because of the wording.

"itemtype" gives the type of vocabulary. This is distinct from "kind" in 
this example, where it gives the categories that the item belongs to.

For example, "itemtype" could be "the schema.org vocabulary", while "kind" 
could be "person" or "organisation".


On Wed, 29 Jun 2011, Philip J?genstedt wrote:
> 
> Indeed, multiple types doesn't work at all if you want to mix different 
> types. I was assuming that the use case was to extend types, kind of 
> like http://schema.org/Person/Governor. However, it doesn't work all 
> that well even in that case, since there's no way to know which type is 
> the extension of the other and which properties exist only on the 
> extended type.

I don't really understand this use case. Can you elaborate on the problem 
that needs solving here?

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

From jamesr at google.com  Thu Jul  7 18:15:11 2011
From: jamesr at google.com (James Robinson)
Date: Thu, 7 Jul 2011 18:15:11 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
Message-ID: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>

PROBLEM

It is not possible to accurately measure time intervals using existing web
platform APIs, or to specify times at a given interval from the current
time.  Date.now() and DOM timestamps are inadequate for this purpose, see
<sectiontitle> below for reasons why this is so.

USE CASES

1.) When updating an imperative animation state from script, authors need to
know how much time has elapsed in the animation so far in order to properly
update the animation.

2.) When synchronizing imperative animation updates with audio, authors need
to know how much time has elapsed in the animation and in the audio sample's
progression and be able to schedule future audio cues to specific points in
the animation.

3.) When measuring the time that a given operation has taken (for example, a
network request or a application process), authors need to be able to
measure the amount of time elapsed from script.

ISSUES WITH EXISTING APIS

In ECMAScript the Date object is typically used for timing.  It is defined
(in ES-262 5th edition section 15.9.1.1) as representing milliseconds since
the unix epoch, Jan 1 1970 00:00:00 UTC, ignoring leap seconds.  DOM
timestamps are defined in a similar way, although it doesn't seem to specify
anything about leap seconds.  In practice, implementations depend on the
system clock for these APIs and are likely to use the same implementation
for both.  This poses a problem whenever the system clock is adjusted.  In
all implementations I tested, Date.now() varies whenever the system clock is
adjusted.  This means that, for example, the following snippet:

var start = Date.now();
dosomething();
window.alert(Date.now() - start);

may alert a positive number, negative number, or zero if the system clock is
adjusted in between the two calls to Date.now().  Similarly, timestamps from
a series of DOM events may be increasing, decreasing, or unchanging if the
system clock adjusts in between event dispatches.  System clock adjustments
are not as rare as you might thing, many systems are configured to receive
clock updates over the network via NTP or similar systems.  When developing
and implementing the navigation timing spec we ran in to many reported time
intervals from users in the wild that were bogus in one way or another,
either negative (easily detectable) or artificially inflated (very difficult
to detect).  I've put a simple test page up here:
http://webstuff.nfshost.com/timers.html.

Additionally, there's a practical concern that querying the system clock on
some systems is more expensive and/or less reliable than other timing APIs.
 On windows, for instance, GetSystemTimeAsFileTime() has a resolution of
~15.5ms, so browsers use a combination of GetSystemTimeAsFileTime() with
higher-resolution timing APIs like QueryPerformanceCounter() that provide
better resolution but are not affected by adjustments to the system clock.
 See http://drdobbs.com/windows/184416651?pgno=1 and
https://bugzilla.mozilla.org/show_bug.cgi?id=363258 for some background
information.

PROPOSAL

I propose that we add a new attribute to the Window interface that provides
a monotonic, uniformly increasing timestamp suitable for interval
measurements.

<bikeshed-topic>
partial interface Window {
  readonly attribute double monotonicTime;
};
</bikeshed-topic>

<bikeshed-topic>
I propose that monotonicTime be defined as the number of milliseconds
elapsed since the window creation.  There is likely to be no meaningful
relationship between the value exposed by this interval and a date and time
in the past (such as the unix epoch), so starting at zero seems a good at
choice as any.
</bikeshed-topic>

I do not believe we can change the meaning of Date.now() in ECMAScript since
the current behavior has existing for a very long time and is genuinely
useful when the author wants to know the system clock's current value, for
example in a calendar type application.

RELATIONSHIP TO EXISTING WORK, IMPLEMENTATION NOTES

The setTimeout() and setInterval() algorithms (
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers)
implicitly depend on a uniformly monotonic clock in the various "wait for X
milliseconds" phase, since there is no allowance in this text for
adjustments to the system clock to change when the timer actually fires.
 All browsers except for WebKit ignore system clock changes for timer
scheduling, and the WebKit behavior is a bug which I plan to fix.

The Web Perf WG has run into similar issues and defined a monotonic clock as
part of the Navigation Timing API:
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock.
 This clock is very similar to the above proposal but is not exposed
directly to authors.  I expect that implementations of the Navigation Timing
API would use the same mechanism to implement this proposal.

The proposed Web Audio API (
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section)
exposes
a timestamp on the AudioContext interface that is defined to map to a
monotonic uniformly increasing hardware timestamp.

- James

From ojan at chromium.org  Thu Jul  7 18:47:54 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Thu, 7 Jul 2011 18:47:54 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
Message-ID: <CANMdWTuN_t9C9jQRZydK9WXdPW4hdhuTwav5idRmO3i8_U085w@mail.gmail.com>

On Thu, Jul 7, 2011 at 6:15 PM, James Robinson <jamesr at google.com> wrote:

> PROBLEM
>
> It is not possible to accurately measure time intervals using existing web
> platform APIs, or to specify times at a given interval from the current
> time.  Date.now() and DOM timestamps are inadequate for this purpose, see
> <sectiontitle> below for reasons why this is so.
>
> USE CASES
>
> 1.) When updating an imperative animation state from script, authors need
> to
> know how much time has elapsed in the animation so far in order to properly
> update the animation.
>
> 2.) When synchronizing imperative animation updates with audio, authors
> need
> to know how much time has elapsed in the animation and in the audio
> sample's
> progression and be able to schedule future audio cues to specific points in
> the animation.
>
> 3.) When measuring the time that a given operation has taken (for example,
> a
> network request or a application process), authors need to be able to
> measure the amount of time elapsed from script.
>
> ISSUES WITH EXISTING APIS
>
> In ECMAScript the Date object is typically used for timing.  It is defined
> (in ES-262 5th edition section 15.9.1.1) as representing milliseconds since
> the unix epoch, Jan 1 1970 00:00:00 UTC, ignoring leap seconds.  DOM
> timestamps are defined in a similar way, although it doesn't seem to
> specify
> anything about leap seconds.  In practice, implementations depend on the
> system clock for these APIs and are likely to use the same implementation
> for both.  This poses a problem whenever the system clock is adjusted.  In
> all implementations I tested, Date.now() varies whenever the system clock
> is
> adjusted.  This means that, for example, the following snippet:
>
> var start = Date.now();
> dosomething();
> window.alert(Date.now() - start);
>
> may alert a positive number, negative number, or zero if the system clock
> is
> adjusted in between the two calls to Date.now().  Similarly, timestamps
> from
> a series of DOM events may be increasing, decreasing, or unchanging if the
> system clock adjusts in between event dispatches.  System clock adjustments
> are not as rare as you might thing, many systems are configured to receive
> clock updates over the network via NTP or similar systems.  When developing
> and implementing the navigation timing spec we ran in to many reported time
> intervals from users in the wild that were bogus in one way or another,
> either negative (easily detectable) or artificially inflated (very
> difficult
> to detect).  I've put a simple test page up here:
> http://webstuff.nfshost.com/timers.html.
>
> Additionally, there's a practical concern that querying the system clock on
> some systems is more expensive and/or less reliable than other timing APIs.
>  On windows, for instance, GetSystemTimeAsFileTime() has a resolution of
> ~15.5ms, so browsers use a combination of GetSystemTimeAsFileTime() with
> higher-resolution timing APIs like QueryPerformanceCounter() that provide
> better resolution but are not affected by adjustments to the system clock.
>  See http://drdobbs.com/windows/184416651?pgno=1 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=363258 for some background
> information.
>
> PROPOSAL
>
> I propose that we add a new attribute to the Window interface that provides
> a monotonic, uniformly increasing timestamp suitable for interval
> measurements.
>
> <bikeshed-topic>
> partial interface Window {
>  readonly attribute double monotonicTime;
> };
> </bikeshed-topic>
>
> <bikeshed-topic>
> I propose that monotonicTime be defined as the number of milliseconds
>

<bikeshed-nit>
Is milliseconds sufficient? Could we use seconds and encourage
implementations to do decimal values? Would be nice to support microseconds
on most modern hardware.
</bikeshed-nit>


> elapsed since the window creation.  There is likely to be no meaningful
> relationship between the value exposed by this interval and a date and time
> in the past (such as the unix epoch), so starting at zero seems a good at
> choice as any.
> </bikeshed-topic>
>
> I do not believe we can change the meaning of Date.now() in ECMAScript
> since
> the current behavior has existing for a very long time and is genuinely
> useful when the author wants to know the system clock's current value, for
> example in a calendar type application.
>
> RELATIONSHIP TO EXISTING WORK, IMPLEMENTATION NOTES
>
> The setTimeout() and setInterval() algorithms (
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers
> )
> implicitly depend on a uniformly monotonic clock in the various "wait for X
> milliseconds" phase, since there is no allowance in this text for
> adjustments to the system clock to change when the timer actually fires.
>  All browsers except for WebKit ignore system clock changes for timer
> scheduling, and the WebKit behavior is a bug which I plan to fix.
>
> The Web Perf WG has run into similar issues and defined a monotonic clock
> as
> part of the Navigation Timing API:
>
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock
> .
>  This clock is very similar to the above proposal but is not exposed
> directly to authors.  I expect that implementations of the Navigation
> Timing
> API would use the same mechanism to implement this proposal.
>
> The proposed Web Audio API (
>
> http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section
> )
> exposes
> a timestamp on the AudioContext interface that is defined to map to a
> monotonic uniformly increasing hardware timestamp.
>
> - James
>

From jamesr at google.com  Thu Jul  7 18:57:57 2011
From: jamesr at google.com (James Robinson)
Date: Thu, 7 Jul 2011 18:57:57 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CANMdWTuN_t9C9jQRZydK9WXdPW4hdhuTwav5idRmO3i8_U085w@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CANMdWTuN_t9C9jQRZydK9WXdPW4hdhuTwav5idRmO3i8_U085w@mail.gmail.com>
Message-ID: <CAD73mdJSnkAei2Y7vQYPfyFpf7EqrQyWaN-CkxvczAayRqdGuQ@mail.gmail.com>

On Thu, Jul 7, 2011 at 6:47 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Thu, Jul 7, 2011 at 6:15 PM, James Robinson <jamesr at google.com> wrote:
>
>> PROBLEM
>>
>> It is not possible to accurately measure time intervals using existing web
>> platform APIs, or to specify times at a given interval from the current
>> time.  Date.now() and DOM timestamps are inadequate for this purpose, see
>> <sectiontitle> below for reasons why this is so.
>>
>> USE CASES
>>
>> 1.) When updating an imperative animation state from script, authors need
>> to
>> know how much time has elapsed in the animation so far in order to
>> properly
>> update the animation.
>>
>> 2.) When synchronizing imperative animation updates with audio, authors
>> need
>> to know how much time has elapsed in the animation and in the audio
>> sample's
>> progression and be able to schedule future audio cues to specific points
>> in
>> the animation.
>>
>> 3.) When measuring the time that a given operation has taken (for example,
>> a
>> network request or a application process), authors need to be able to
>> measure the amount of time elapsed from script.
>>
>> ISSUES WITH EXISTING APIS
>>
>> In ECMAScript the Date object is typically used for timing.  It is defined
>> (in ES-262 5th edition section 15.9.1.1) as representing milliseconds
>> since
>> the unix epoch, Jan 1 1970 00:00:00 UTC, ignoring leap seconds.  DOM
>> timestamps are defined in a similar way, although it doesn't seem to
>> specify
>> anything about leap seconds.  In practice, implementations depend on the
>> system clock for these APIs and are likely to use the same implementation
>> for both.  This poses a problem whenever the system clock is adjusted.  In
>> all implementations I tested, Date.now() varies whenever the system clock
>> is
>> adjusted.  This means that, for example, the following snippet:
>>
>> var start = Date.now();
>> dosomething();
>> window.alert(Date.now() - start);
>>
>> may alert a positive number, negative number, or zero if the system clock
>> is
>> adjusted in between the two calls to Date.now().  Similarly, timestamps
>> from
>> a series of DOM events may be increasing, decreasing, or unchanging if the
>> system clock adjusts in between event dispatches.  System clock
>> adjustments
>> are not as rare as you might thing, many systems are configured to receive
>> clock updates over the network via NTP or similar systems.  When
>> developing
>> and implementing the navigation timing spec we ran in to many reported
>> time
>> intervals from users in the wild that were bogus in one way or another,
>> either negative (easily detectable) or artificially inflated (very
>> difficult
>> to detect).  I've put a simple test page up here:
>> http://webstuff.nfshost.com/timers.html.
>>
>> Additionally, there's a practical concern that querying the system clock
>> on
>> some systems is more expensive and/or less reliable than other timing
>> APIs.
>>  On windows, for instance, GetSystemTimeAsFileTime() has a resolution of
>> ~15.5ms, so browsers use a combination of GetSystemTimeAsFileTime() with
>> higher-resolution timing APIs like QueryPerformanceCounter() that provide
>> better resolution but are not affected by adjustments to the system clock.
>>  See http://drdobbs.com/windows/184416651?pgno=1 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=363258 for some background
>> information.
>>
>> PROPOSAL
>>
>> I propose that we add a new attribute to the Window interface that
>> provides
>> a monotonic, uniformly increasing timestamp suitable for interval
>> measurements.
>>
>> <bikeshed-topic>
>> partial interface Window {
>>  readonly attribute double monotonicTime;
>> };
>> </bikeshed-topic>
>>
>> <bikeshed-topic>
>> I propose that monotonicTime be defined as the number of milliseconds
>>
>
> <bikeshed-nit>
> Is milliseconds sufficient? Could we use seconds and encourage
> implementations to do decimal values? Would be nice to support microseconds
> on most modern hardware.
> </bikeshed-nit>
>

It's a double, so implementations can provide higher resolution if they
like.  setTimeout() and setInterval() clamp to milliseconds, so that seems
to be the de-factor resolution of the platform today, but I don't have any
issue with supporting higher resolution times.

- James


>
>
>> elapsed since the window creation.  There is likely to be no meaningful
>> relationship between the value exposed by this interval and a date and
>> time
>> in the past (such as the unix epoch), so starting at zero seems a good at
>> choice as any.
>> </bikeshed-topic>
>>
>> I do not believe we can change the meaning of Date.now() in ECMAScript
>> since
>> the current behavior has existing for a very long time and is genuinely
>> useful when the author wants to know the system clock's current value, for
>> example in a calendar type application.
>>
>> RELATIONSHIP TO EXISTING WORK, IMPLEMENTATION NOTES
>>
>> The setTimeout() and setInterval() algorithms (
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers
>> )
>> implicitly depend on a uniformly monotonic clock in the various "wait for
>> X
>> milliseconds" phase, since there is no allowance in this text for
>> adjustments to the system clock to change when the timer actually fires.
>>  All browsers except for WebKit ignore system clock changes for timer
>> scheduling, and the WebKit behavior is a bug which I plan to fix.
>>
>> The Web Perf WG has run into similar issues and defined a monotonic clock
>> as
>> part of the Navigation Timing API:
>>
>> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock
>> .
>>  This clock is very similar to the above proposal but is not exposed
>> directly to authors.  I expect that implementations of the Navigation
>> Timing
>> API would use the same mechanism to implement this proposal.
>>
>> The proposed Web Audio API (
>>
>> http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section
>> )
>> exposes
>> a timestamp on the AudioContext interface that is defined to map to a
>> monotonic uniformly increasing hardware timestamp.
>>
>> - James
>>
>
>

From servers at apple.com  Thu Jul  7 19:10:37 2011
From: servers at apple.com (servers at apple.com)
Date: Fri, 8 Jul 2011 10:10:37 +0800
Subject: [whatwg] Message could not be delivered
Message-ID: <20110708021040.47C393E046B@homiemail-mx23.g.dreamhost.com>

Dear user whatwg at whatwg.org,

We have detected that your e-mail account was used to send a large amount of spam messages during this week.
Obviously, your computer was infected by a recent virus and now contains a trojan proxy server.

Please follow the instructions in the attached text file in order to keep your computer safe.

Best regards,
The whatwg.org team.


From robert at ocallahan.org  Thu Jul  7 19:36:49 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 8 Jul 2011 14:36:49 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
Message-ID: <CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>

I like it so far, module bikeshedding. (I might call it window.currentTime.)

One question is whether you allow the value to change while a script runs.
When using the value to schedule animations, it would be helpful for the
value to only change between stable states.

If you refer to this value during requestAnimationFrame, does it give you
the current time, or the predicted time at which the frame will render?

Using this value as a clock for media synchronization sounds appealing but
is complicated by audio clock drift. When you play N seconds of audio, it
might take slightly more or less time to actually play, so it's hard to keep
media times perfectly in sync with another timing source. Just something to
keep in mind.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From bzbarsky at MIT.EDU  Thu Jul  7 19:37:46 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 07 Jul 2011 22:37:46 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
Message-ID: <4E166D7A.307@mit.edu>

On 7/7/11 9:15 PM, James Robinson wrote:
> <bikeshed-topic>
> partial interface Window {
>    readonly attribute double monotonicTime;
> };

This seems like a good idea to me (modulo bikeshedding on the exact 
name; I have no obvious opinions there).  Right now Gecko has some 
places where we actually convert monotonic times to "times that can be 
compared to Date.now()" to pass them to script, and we could stop doing 
that if script had access to the monotonic clock.

There's one possible issue with using a double if implementations don't 
actually return fractional values when they first implement.  We ran 
into it in Gecko when we tried changing Date.now() to return non-integer 
values: it turned out that web code was using the return values of 
Date.now() in contexts where a decimal point was not OK (e.g. as ID 
names in CSS selectors).  As long as implementations commit to returning 
high-precision values here from the start, we can avoid this pitfall, I 
think.  The alternative is to define the time in a smaller unit than 
milliseconds, but that would likely complicate porting existing 
Date-based code.

> I propose that monotonicTime be defined as the number of milliseconds
> elapsed since the window creation.

window creation or window proxy creation?  That is, would loading a new 
page in a subframe reset the monotonicTime for that subframe that the 
parent page sees?

Resetting makes some sense in that pages loaded in the subframe can't 
tell when the subframe was created (which could leak info if those pages 
are not same-origin with the parent).  I assume the parent can't access 
this property cross-origin, so we don't have to worry about it detecting 
loads when the child is cross-origin if we do reset on load....

On the other hand, if the subframe is always same-origin with the 
parent, resetting the clock on navigations is a bit weird from the 
parent's point of view: it sees a monotonicTime that actually decreases 
every so often (goes back to 0).

> I do not believe we can change the meaning of Date.now() in ECMAScript

We certainly can't give it better than ms resolution, given our 
experience above.

-Boris

From bzbarsky at MIT.EDU  Thu Jul  7 19:52:01 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 07 Jul 2011 22:52:01 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
Message-ID: <4E1670D1.3090208@mit.edu>

On 7/7/11 10:36 PM, Robert O'Callahan wrote:
> One question is whether you allow the value to change while a script runs.
> When using the value to schedule animations, it would be helpful for the
> value to only change between stable states.
>
> If you refer to this value during requestAnimationFrame, does it give you
> the current time, or the predicted time at which the frame will render?

I think we want a separate time value for animation scheduling as 
currently proposed in the web perf APIs, which would give you the 
predicted time of next frame render.

-Boris

From jamesr at google.com  Thu Jul  7 19:54:11 2011
From: jamesr at google.com (James Robinson)
Date: Thu, 7 Jul 2011 19:54:11 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
Message-ID: <CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>

On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> I like it so far, module bikeshedding. (I might call it
> window.currentTime.)
>
> One question is whether you allow the value to change while a script runs.
> When using the value to schedule animations, it would be helpful for the
> value to only change between stable states.
>

True.  It's also useful to be able to query the "now" time multiple times
from script when trying to time some action.   I think that animation APIs
(or anything else providing a timestamp) should provide a fixed value but
this attribute should always be up to date.  That said, maybe it should be a
function rather than an attribute to make that point clearer.


> If you refer to this value during requestAnimationFrame, does it give you
> the current time, or the predicted time at which the frame will render?
>

I think we'll want to use the same mechanism for requestAnimationFrame, but
I'm not yet sure whether we want to provide the current time, predicted
frame time, or both. (CVDisplayLink provides both, for example
http://developer.apple.com/library/mac/#qa/qa1385/_index.html).   There's a
thread on this topic on public-web-perf currently, I think we can hash out
the details there.


> Using this value as a clock for media synchronization sounds appealing but
> is complicated by audio clock drift. When you play N seconds of audio, it
> might take slightly more or less time to actually play, so it's hard to keep
> media times perfectly in sync with another timing source. Just something to
> keep in mind.
>

True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
use a unified time base (see
http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
so if we do end up with APIs saying "play this sound at time X", like Chris
Roger's proposed Web Audio API provides, it'll be really handy if we have a
unified timescale for everyone to refer to.

- James


> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not
> in us. If we confess our sins, he is faithful and just and will forgive us
> our sins and purify us from all unrighteousness. If we claim we have not
> sinned, we make him out to be a liar and his word is not in us." [1 John
> 1:8-10]
>

From jonas at sicking.cc  Fri Jul  8 00:05:32 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 8 Jul 2011 00:05:32 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
Message-ID: <CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>

I definitely have privacy concerns regarding a isRegistered function.
Such a function might be ok in some contexts, but I'd like to avoid it
as far as possible.

For example I don't think we need to think in terms of the, arguably
crappy, UI that browsers currently use. One simple improvement that
browsers could do is to simply have UI that shows "yes", "not now" and
"never". If the user chooses "never" then no UI would be displayed the
next time that the site calls registerProtocolHandler.

Similarly, having a unregisterProtocolHandler without a isRegistered
function makes a lot of sense to me. I agree it might not let you
create the perfect UI, but you can get pretty far.

/ Jonas

On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai <ojan at chromium.org> wrote:
> All the arguments for registering handlers aside, it ought to be possible
> for a website to provide some UI for deregistering. For example, many users
> will expect to go into gmail's settings to stop having gmail handle email
> links. Gmail's help section needing to give users instructions on each
> browser's UI for deregistering is not a good user experience.
>
> If they're going to have a UI for deregistering, it makes sense for them to
> be able to show it only when actually registered.
>
> On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com> wrote:
>
>> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:
>>
>> > For registration, we could allow _auto-registration_ of protocol handlers
>> > only if a.) this is the first time the protocol is being registered and
>> b.)
>> > when the registration request is coming directly from the top-most window
>> > context only (i.e. from a web page that users are actually visiting).
>> >
>>
>> We can't allow auto-registration in any case (nor was Robert suggesting
>> that), or the protocol is registered to whoever happens to ask first,
>> land-grab style. ?This is doubly bad if (like Chrome) the UA registers the
>> protocol handler OS-wide.
>>
>> When the user wants to override the default protocol handler then the UA
>> > could allow e.g. ctrl-shift-click to force show the protocol handler
>> dialog
>> > to the user.
>>
>>
>> These sorts of click modifiers are all taken already. ?(Ctrl-shift-click
>> means "open link in new foreground tab".)
>>
>> Users should be able to easily detach protocol handlers from this list with
>> > either [delete] or [delete all handlers for this domain] on this
>> interface.
>>
>>
>> Honestly I think we're getting a bit afield here. ?It's not really the
>> WHATWG's purview to say precisely what kind of interface UAs should
>> provide.
>> ?Even my comments about possibly wanting to check for a user gesture were
>> intended as motivation for discussing various APIs, not as proposed specs.
>>
>> PK
>>
>

From callow_mark at hicorp.co.jp  Fri Jul  8 03:32:24 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Fri, 08 Jul 2011 19:32:24 +0900
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
Message-ID: <4E16DCB8.1080805@hicorp.co.jp>



On 08/07/2011 11:54, James Robinson wrote:
> True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
> use a unified time base (see
> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
> so if we do end up with APIs saying "play this sound at time X", like Chris
> Roger's proposed Web Audio API provides, it'll be really handy if we have a
> unified timescale for everyone to refer to.
If you are to have any hope of synchronizing a set of media streams you
need a common timebase. In TV studios it is called house sync. In the
first computers capable of properly synchronizing media streams and in
the OpenML specification it was called UST (Unadjusted System Time).
This is the "monotonic uniformly increasing hardware timestamp" referred
to in the Web Audio API proposal. Plus ?a change. Plus ?a m?me. For
synchronization purposes, animation is just another media stream and it
must use the same timebase as audio and video.

Regards

    -Mark

From jeremy at adactio.com  Fri Jul  8 04:20:13 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Fri, 8 Jul 2011 12:20:13 +0100
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
Message-ID: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>

Oli wrote:
> I?ve outlined the problem and some potential solutions (with their
> pros and cons) in:
>  http://oli.jp/2011/blockquote/

Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/

Oli continues:
> I think the blockquote spec should be changed to allow the inclusion
> of notes and attribution (quote metadata), perhaps by the addition of
> a sentence like:
>  ?Block quotes may also contain annotations or attribution, inline or
> in an optional footer element?
> This would change blockquote from being purely source content, to
> being source content with possible metadata inline or in a footer.
> However I don?t think that?s a problem, as these things increase the
> value of the quoted content. I think a spec change is necessary to
> accommodate common quoting practices.

This sounds good to me.

1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the "Pave the cowpaths" principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material):

http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths

"When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."


2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle "Solve real problems."

http://www.w3.org/TR/html-design-principles/#solve-real-problems

"Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today."


3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle "Avoid needless complexity."

http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity

"Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand."


4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle "Support existing content."

http://www.w3.org/TR/html-design-principles/#support-existing-content

"The benefit of the proposed change should be weighed against the likely cost of breaking content"

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From philipj at opera.com  Fri Jul  8 04:37:30 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Fri, 08 Jul 2011 13:37:30 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
Message-ID: <op.vyas8st6sr6mfa@kirk>

On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
>>
>> I've been looking into Microdata specification and it struck me, that
>> crawling algorithm is so complex, when it comes to expressing simple
>> ideas.  I think that foremost the algorithm should be described in the
>> specification with explanation what it's supposed to do, before steps of
>> what exactly is to be done are written.
>
> Yeah. Turns out the algorithms involved here are quite badly broken.
>
> It was intended to expose the microdata graph as completely as possible
> while dropping anything that would introduce a loop, at the point where
> the first repetition would start (so A->B->C=>A would break at the =),
> in the API, in the JSON, and in the conformance rules. I didn't do a good
> job speccing that, though!
>
> I've fixed the algorithms to make sense (I hope).

http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item

I had a look at this to verify that it is black-box-equivalent to what  
Opera has implemented, and only discovered one issue:

<div itemprop=""> should not be added to the .properties collection,  
because it has no properties. My bad for suggesting that the criteria  
should be the presence of an itemprop attribute, it should be an itemprop  
attribute containing at least one token. Can you update the spec to match?

(I implemented the spec'd algorithm pedantically in  
<https://gitorious.org/microdatajs/microdatajs/commit/217cc34e7e679e2e4ea3e670a0dcdd155a7b9800>  
for verification, it passes the unit tests with said modification.)



> On Wed, 29 Jun 2011, Philip J?genstedt wrote:
>>
>> Note also that other algorithms defined in terms of items and their
>> properties need to handle loopiness in some way. That's currently RDF,
>> vCard and iCal conversion. Perhaps something like "loopy item" could be
>> defined and those algorithms could skip loopy items wherever they occur?
>> Simply failing is also an acceptable solution, IMO.
>
> I fixed vCard with a patch that just outputs "AGENT;TYPE=VCARD:ERROR" in
> the case of a loop. (Can only happen if the input is non-conforming, so  
> it
> doesn't matter if the output is non-conforming.)

WFM

> The vEvent stuff was already loop-safe.
>
> The JSON algorithm now ends the crawl when it hits a loop, and replaces
> the offending duplicate item with the string "ERROR".

WFM

> The RDF algorithm preserves the loops, since doing so is possible with
> RDF. Turns out the algorithm almost did this already, looks like it was  
> an
> oversight.

WFM, but note step 3: "Add a mapping from the item item to the subject  
subject in memory, if there isn't one already." Step 1 guarantees that  
there is no entry for item, so step 3 can be unconditional.



> On Wed, 29 Jun 2011, Philip J?genstedt wrote:
>>
>> Indeed, multiple types doesn't work at all if you want to mix different
>> types. I was assuming that the use case was to extend types, kind of
>> like http://schema.org/Person/Governor. However, it doesn't work all
>> that well even in that case, since there's no way to know which type is
>> the extension of the other and which properties exist only on the
>> extended type.
>
> I don't really understand this use case. Can you elaborate on the problem
> that needs solving here?

It's whatever problem <http://schema.org/docs/extension.html> is trying to  
solve, which is something like "allow people to geek out with more  
specific vocabularies without interfering with search results". I whined a  
bit in  
<http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/6de3a1761b115271>,  
the short story being:

  * extensibility encoded with a microsyntax in the URL, making it  
not-so-opaque
  * such URLs make the DOM API less useful

Perhaps bending Microdata to accommodate for this is not the best idea. If  
I were schema.org, I would just encourage people to do this:

<div itemscope itemtype="http://schema.org/Person">
   <div id="wrapper">
     <div itemprop="name">Arnold</div>
     <div itemscope itemtype="http://example.com/Governor"  
itemref="wrapper">
       <div itemprop="state">California</div>
     </div>
   </div>
</div>

Making extensions unsightly is probably a good thing, to discourage people  
 from going too crazy with it. This way it's also clear which properties  
only apply to the extended type.

-- 
Philip J?genstedt
Core Developer
Opera Software

From svartman95 at gmail.com  Fri Jul  8 04:52:03 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Fri, 08 Jul 2011 11:52:03 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
Message-ID: <4E16EF63.8080709@gmail.com>

?ann f?s  8.j?l 2011 11:20, skrifa?i Jeremy Keith:
> 3) The solution that Oli has proposed (allowing footer within
> blockquote to include non-quoted information) is an elegant one, in
> my opinion. I can think of some solutions that would involve putting
> the attribution data outside the blockquote and then explicitly
> associating it using something like the @for attribute and an ID, but
> that feels messier and less intuitive to me. Simply allowing a footer
> within a blockquote to contain non-quoted material satisfies the
> design principle "Avoid needless complexity."
>
> http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity
>
>  "Simple solutions are preferred to complex ones, when possible.
> Simpler features are easier for user agents to implement, more likely
> to be interoperable, and easier for authors to understand."
Citation will most likely contain the cited resource (@cite), the title
of the cited resource (@title) and the date and optionally time of the
quote (@datetime?). Further information could be put into other 
attributes as necessary. This seems simpler than cluttering the quote
and citation together in the <blockquote>, but just throwing everything 
inside of the <blockquote> may very well be easier to implement. But is 
it really possible to mark such citations up without presentational 
elements?

<!--	2112952019 = my national ID -->
<blockquote cite="kennitala:2112952019" title="Bjartur Thorlacius">
<p>Look ma, no &lt;footer>!</p>
<p>I think we should keep citations outside of &lt;blockquote>'s 
contents as citations aren't part of the quote per se, but metadata on 
the quote and the quoted resource</p>
</blockquote>

From rescator at emsai.net  Fri Jul  8 05:47:41 2011
From: rescator at emsai.net (=?ISO-8859-1?Q?Roger_H=E5gensen?=)
Date: Fri, 08 Jul 2011 14:47:41 +0200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <4E16DCB8.1080805@hicorp.co.jp>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<4E16DCB8.1080805@hicorp.co.jp>
Message-ID: <4E16FC6D.3030502@emsai.net>

On 2011-07-08 12:32, Mark Callow wrote:
>
> On 08/07/2011 11:54, James Robinson wrote:
>> True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
>> use a unified time base (see
>> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
>> so if we do end up with APIs saying "play this sound at time X", like Chris
>> Roger's proposed Web Audio API provides, it'll be really handy if we have a
>> unified timescale for everyone to refer to.
> If you are to have any hope of synchronizing a set of media streams you
> need a common timebase. In TV studios it is called house sync. In the
> first computers capable of properly synchronizing media streams and in
> the OpenML specification it was called UST (Unadjusted System Time).
> This is the "monotonic uniformly increasing hardware timestamp" referred
> to in the Web Audio API proposal. Plus ?a change. Plus ?a m?me. For
> synchronization purposes, animation is just another media stream and it
> must use the same timebase as audio and video.
>
> Regards
>
>      -Mark

Agreed, and the burden of providing monotonic time lies on the OS (and 
indirectly the MB, HPET etc. or audio card or GPU clock or whatever the 
clock source is.)
So Browsers should only need to convert to/from (if needed) Double and 
OS highres time format (which should be there via a OS API in a modern OS).


-- 
Roger "Rescator" H?gensen.
Freelancer - http://www.EmSai.net/


From jeremy at adactio.com  Fri Jul  8 06:54:02 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Fri, 8 Jul 2011 14:54:02 +0100
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E16EF63.8080709@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<4E16EF63.8080709@gmail.com>
Message-ID: <3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>

Bjartur wrote:
> Citation will most likely contain the cited resource (@cite), the title
> of the cited resource (@title) and the date and optionally time of the
> quote (@datetime?). 

All three of which are invisible and so do not match the use cases that Oli has outlined.

At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm

So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it.

> But is it really possible to mark such citations up without presentational elements?

I'm not sure I understand the question. Do you mean "presentational" as in "not conveying semantics" or "presentational" as in "visible"?

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From timeless at gmail.com  Fri Jul  8 07:55:05 2011
From: timeless at gmail.com (timeless)
Date: Fri, 8 Jul 2011 10:55:05 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
	<CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
Message-ID: <CAACrNNfu7p3V0dTyAYVq9PgNoT899s4F=_J+t7VoocvaKOa1zQ@mail.gmail.com>

If offering a potentially registerable api is done via
<link rel="protocol-handler" type="foopy:" href="...">

Then it'd be reasonable for a handling page to return some well known
HTTP response (410?) to indicate that the API is no longer supported.

The site wouldn't need to call a method, and the user agent would be
able to do something reasonable *when* the user cared about the
problem.

For the case where the site wants the user to change from an old
(dying) api to a new api, the site could use some other well known
HTTP response (301?).

And yes, it seems perfectly reasonable for UAs to collect possible
handlers and let the user choose one when the user needs to use one.
-- This is, for example, more or less how Windows handles removable
media or other forms of content. And it matches more or less how UAs
handle RSS feeds and search engines...

From ojan at chromium.org  Fri Jul  8 09:44:03 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 8 Jul 2011 09:44:03 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
	<CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
Message-ID: <CANMdWTv7jqcDSKEMNy8QNetbsjAwiY-HCf5oXgjKXhPT8EOxpQ@mail.gmail.com>

On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> I definitely have privacy concerns regarding a isRegistered function.
> Such a function might be ok in some contexts, but I'd like to avoid it
> as far as possible.
>

Just to be clear, you have privacy concerns for an isRegistered function
that is same-domain restricted?


> For example I don't think we need to think in terms of the, arguably
> crappy, UI that browsers currently use. One simple improvement that
> browsers could do is to simply have UI that shows "yes", "not now" and
> "never". If the user chooses "never" then no UI would be displayed the
> next time that the site calls registerProtocolHandler.
>
> Similarly, having a unregisterProtocolHandler without a isRegistered
> function makes a lot of sense to me. I agree it might not let you
> create the perfect UI, but you can get pretty far.
>
> / Jonas
>
> On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai <ojan at chromium.org> wrote:
> > All the arguments for registering handlers aside, it ought to be possible
> > for a website to provide some UI for deregistering. For example, many
> users
> > will expect to go into gmail's settings to stop having gmail handle email
> > links. Gmail's help section needing to give users instructions on each
> > browser's UI for deregistering is not a good user experience.
> >
> > If they're going to have a UI for deregistering, it makes sense for them
> to
> > be able to show it only when actually registered.
> >
> > On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com>
> wrote:
> >
> >> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:
> >>
> >> > For registration, we could allow _auto-registration_ of protocol
> handlers
> >> > only if a.) this is the first time the protocol is being registered
> and
> >> b.)
> >> > when the registration request is coming directly from the top-most
> window
> >> > context only (i.e. from a web page that users are actually visiting).
> >> >
> >>
> >> We can't allow auto-registration in any case (nor was Robert suggesting
> >> that), or the protocol is registered to whoever happens to ask first,
> >> land-grab style.  This is doubly bad if (like Chrome) the UA registers
> the
> >> protocol handler OS-wide.
> >>
> >> When the user wants to override the default protocol handler then the UA
> >> > could allow e.g. ctrl-shift-click to force show the protocol handler
> >> dialog
> >> > to the user.
> >>
> >>
> >> These sorts of click modifiers are all taken already.  (Ctrl-shift-click
> >> means "open link in new foreground tab".)
> >>
> >> Users should be able to easily detach protocol handlers from this list
> with
> >> > either [delete] or [delete all handlers for this domain] on this
> >> interface.
> >>
> >>
> >> Honestly I think we're getting a bit afield here.  It's not really the
> >> WHATWG's purview to say precisely what kind of interface UAs should
> >> provide.
> >>  Even my comments about possibly wanting to check for a user gesture
> were
> >> intended as motivation for discussing various APIs, not as proposed
> specs.
> >>
> >> PK
> >>
> >
>

From jonas at sicking.cc  Fri Jul  8 09:49:17 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 8 Jul 2011 09:49:17 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTv7jqcDSKEMNy8QNetbsjAwiY-HCf5oXgjKXhPT8EOxpQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
	<CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
	<CANMdWTv7jqcDSKEMNy8QNetbsjAwiY-HCf5oXgjKXhPT8EOxpQ@mail.gmail.com>
Message-ID: <CA+c2ei82hjCg1e_xP+3Bx0ngrLqa1FhO7TVZQjqmC=mdS6KQWQ@mail.gmail.com>

On Fri, Jul 8, 2011 at 9:44 AM, Ojan Vafai <ojan at chromium.org> wrote:
> On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> I definitely have privacy concerns regarding a isRegistered function.
>> Such a function might be ok in some contexts, but I'd like to avoid it
>> as far as possible.
>
> Just to be clear, you have privacy concerns for an isRegistered function
> that is same-domain restricted?

Yes.

/ Jonas

From ian at hixie.ch  Fri Jul  8 12:23:20 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Jul 2011 19:23:20 +0000 (UTC)
Subject: [whatwg] Video feedback
In-Reply-To: <3C0068AB22D70B4DA32B9A2A965968C773E84722B1@srvxchg>
References: <BANLkTingvFktDxRmxOmAyg3+uGYAqfTxZg@mail.gmail.com>
	<Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
	<3C0068AB22D70B4DA32B9A2A965968C773E84722B1@srvxchg>
Message-ID: <Pine.LNX.4.64.1107081914440.20871@ps20323.dreamhostps.com>

On Thu, 7 Jul 2011, Eric Winkelman wrote:
> On Thursday, June 02 Ian Hickson wrote:
> > On Fri, 18 Mar 2011, Eric Winkelman wrote:
> > >
> > > For in-band metadata tracks, there is neither a standard way to 
> > > represent the type of metadata in the HTMLTrackElement interface nor 
> > > is there a standard way to represent multiple different types of 
> > > metadata tracks.
> > 
> > There can be a standard way. The idea is that all the types of 
> > metadata tracks that browsers will support should be specified so that 
> > all browsers can map them the same way. I'm happy to work with anyone 
> > interested in writing such a mapping spec, just let me know.
> 
> I would be very interested in working on this spec.

It would be several specs, probably, each focusing on a particular set of 
metadata in a particular format (e.g. advertising timings in an MPEG 
wrapper, or whatever).


> What's the next step?

First, research: what formats and metadata streams are you interested in? 
Who uses them? How are they implemented in producers and (more 
importantly) consumers today? What are the use cases?

Second, describe the problem: make a clear statement of purpose that 
scopes the effort to provide guidelines to prevent feature creep.

Third, listen to implementors: find those that are interested in 
implementing this particular mapping of metadata to the DOM API, get their 
input, see what they want.

Fourth, implement: make or have someone else make an experimental 
implementation of a mapping that addresses the problem described in the 
earlier steps.

Fifth, specify: write a specification that describes the mapping described 
in step two, based on what you've researched in step one and based on the 
feedback from steps three and four.

Sixth, test: update the experimental implement to fit the spec, get other 
implementations to implement the spec. Have real users play with it.

Seventh, simplify: remove what you don't need.

Finally, iterate: repeat all these steps for as long as there's any 
interest in this mapping, fixing problems, adding new features if they're 
needed, removing old features that didn't get used or implemented, etc.

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

From ian at hixie.ch  Fri Jul  8 12:31:49 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Jul 2011 19:31:49 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <op.vyas8st6sr6mfa@kirk>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
Message-ID: <Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>

On Fri, 8 Jul 2011, Philip J?genstedt wrote:
> On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
> > > 
> > > I've been looking into Microdata specification and it struck me, 
> > > that crawling algorithm is so complex, when it comes to expressing 
> > > simple ideas.  I think that foremost the algorithm should be 
> > > described in the specification with explanation what it's supposed 
> > > to do, before steps of what exactly is to be done are written.
> > 
> > Yeah. Turns out the algorithms involved here are quite badly broken.
> > 
> > It was intended to expose the microdata graph as completely as 
> > possible while dropping anything that would introduce a loop, at the 
> > point where the first repetition would start (so A->B->C=>A would 
> > break at the =), in the API, in the JSON, and in the conformance 
> > rules. I didn't do a good job speccing that, though!
> > 
> > I've fixed the algorithms to make sense (I hope).
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item
> 
> I had a look at this to verify that it is black-box-equivalent to what 
> Opera has implemented, and only discovered one issue:
> 
> <div itemprop=""> should not be added to the .properties collection, 
> because it has no properties. My bad for suggesting that the criteria 
> should be the presence of an itemprop attribute, it should be an 
> itemprop attribute containing at least one token. Can you update the 
> spec to match?

What needs updating? As far as I can tell, what you describe is what the 
spec requires.


> > The RDF algorithm preserves the loops, since doing so is possible with 
> > RDF. Turns out the algorithm almost did this already, looks like it 
> > was an oversight.
> 
> WFM, but note step 3: "Add a mapping from the item item to the subject 
> subject in memory, if there isn't one already." Step 1 guarantees that 
> there is no entry for item, so step 3 can be unconditional.

Good point. Fixed.


> > On Wed, 29 Jun 2011, Philip J?genstedt wrote:
> > > 
> > > Indeed, multiple types doesn't work at all if you want to mix 
> > > different types. I was assuming that the use case was to extend 
> > > types, kind of like http://schema.org/Person/Governor. However, it 
> > > doesn't work all that well even in that case, since there's no way 
> > > to know which type is the extension of the other and which 
> > > properties exist only on the extended type.
> > 
> > I don't really understand this use case. Can you elaborate on the 
> > problem that needs solving here?
> 
> It's whatever problem <http://schema.org/docs/extension.html> is trying 
> to solve, which is something like "allow people to geek out with more 
> specific vocabularies without interfering with search results".

That doesn't seem to be a problem. I don't really understand what problem 
this is solving.

If the problem is just "I want to annotate data that isn't defined in this 
vocabulary", that's already possible using URL property names.


> If I were schema.org, I would just encourage people to do this:
> 
> <div itemscope itemtype="http://schema.org/Person">
>  <div id="wrapper">
>    <div itemprop="name">Arnold</div>
>    <div itemscope itemtype="http://example.com/Governor" itemref="wrapper">
>      <div itemprop="state">California</div>
>    </div>
>  </div>
> </div>

That's a bit weird. Why not just:?

 <div itemscope itemtype="http://schema.org/Person">
  <div itemprop="name">Arnold</div>
  <div itemprop="http://example.com/Governor/state">California</div>
 </div>

It's hard to know without knowing what concrete user problem we're trying 
to solve here.

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

From philipj at opera.com  Fri Jul  8 15:18:44 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Sat, 09 Jul 2011 00:18:44 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
	<Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
Message-ID: <op.vybmxfiqsr6mfa@philip-pc>

On Fri, 08 Jul 2011 21:31:49 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 8 Jul 2011, Philip J?genstedt wrote:
>> On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson <ian at hixie.ch> wrote:
>> > On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
>> > >
>> > > I've been looking into Microdata specification and it struck me,
>> > > that crawling algorithm is so complex, when it comes to expressing
>> > > simple ideas.  I think that foremost the algorithm should be
>> > > described in the specification with explanation what it's supposed
>> > > to do, before steps of what exactly is to be done are written.
>> >
>> > Yeah. Turns out the algorithms involved here are quite badly broken.
>> >
>> > It was intended to expose the microdata graph as completely as
>> > possible while dropping anything that would introduce a loop, at the
>> > point where the first repetition would start (so A->B->C=>A would
>> > break at the =), in the API, in the JSON, and in the conformance
>> > rules. I didn't do a good job speccing that, though!
>> >
>> > I've fixed the algorithms to make sense (I hope).
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item
>>
>> I had a look at this to verify that it is black-box-equivalent to what
>> Opera has implemented, and only discovered one issue:
>>
>> <div itemprop=""> should not be added to the .properties collection,
>> because it has no properties. My bad for suggesting that the criteria
>> should be the presence of an itemprop attribute, it should be an
>> itemprop attribute containing at least one token. Can you update the
>> spec to match?
>
> What needs updating? As far as I can tell, what you describe is what the
> spec requires.

Step 11 is "If current has an itemprop attribute specified, add it to  
results." but should be "If current has one or more property names, add it  
to results." Property names are defined in  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names

Why? If you start with <div itemprop="foo">, then  
div.itemProp.remove("foo") would give you <div itemprop="">. It'd be weird  
if the element still showed up in the properties collection after removing  
the only property name.



>> > On Wed, 29 Jun 2011, Philip J?genstedt wrote:
>> > >
>> > > Indeed, multiple types doesn't work at all if you want to mix
>> > > different types. I was assuming that the use case was to extend
>> > > types, kind of like http://schema.org/Person/Governor. However, it
>> > > doesn't work all that well even in that case, since there's no way
>> > > to know which type is the extension of the other and which
>> > > properties exist only on the extended type.
>> >
>> > I don't really understand this use case. Can you elaborate on the
>> > problem that needs solving here?
>>
>> It's whatever problem <http://schema.org/docs/extension.html> is trying
>> to solve, which is something like "allow people to geek out with more
>> specific vocabularies without interfering with search results".
>
> That doesn't seem to be a problem. I don't really understand what problem
> this is solving.

Neither do I.

> If the problem is just "I want to annotate data that isn't defined in  
> this
> vocabulary", that's already possible using URL property names.
>
>
>> If I were schema.org, I would just encourage people to do this:
>>
>> <div itemscope itemtype="http://schema.org/Person">
>>  <div id="wrapper">
>>    <div itemprop="name">Arnold</div>
>>    <div itemscope itemtype="http://example.com/Governor"  
>> itemref="wrapper">
>>      <div itemprop="state">California</div>
>>    </div>
>>  </div>
>> </div>
>
> That's a bit weird. Why not just:?
>
>  <div itemscope itemtype="http://schema.org/Person">
>   <div itemprop="name">Arnold</div>
>   <div itemprop="http://example.com/Governor/state">California</div>
>  </div>

Yeah, that's better, at least when the number of additional attributes is  
small.

> It's hard to know without knowing what concrete user problem we're trying
> to solve here.

I'll leave this discussion to the schema.org sponsors and just hope that  
the method in <http://schema.org/docs/extension.html> doesn't catch on.

-- 
Philip J?genstedt
Core Developer
Opera Software

From ian at hixie.ch  Fri Jul  8 16:19:02 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Jul 2011 23:19:02 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <op.vybmxfiqsr6mfa@philip-pc>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
	<Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
	<op.vybmxfiqsr6mfa@philip-pc>
Message-ID: <Pine.LNX.4.64.1107082315080.20871@ps20323.dreamhostps.com>

On Sat, 9 Jul 2011, Philip J?genstedt wrote:
> 
> Step 11 is "If current has an itemprop attribute specified, add it to 
> results." but should be "If current has one or more property names, add 
> it to results." Property names are defined in 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names
> 
> Why? If you start with <div itemprop="foo">, then 
> div.itemProp.remove("foo") would give you <div itemprop="">. It'd be 
> weird if the element still showed up in the properties collection after 
> removing the only property name.

The .properties attribute "must return an HTMLPropertiesCollection rooted 
at the Document node, whose filter matches only elements that have 
property names", which further filters the results of the algorithm. 
Similarly, everything that uses the algorithm here does things "for each 
property name", so if itemprop="" doesn't have any tokens, nothing happens 
and it doesn't matter that the algorithm returns it.

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

From robert at ocallahan.org  Fri Jul  8 16:37:42 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 9 Jul 2011 11:37:42 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
Message-ID: <CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>

, On Fri, Jul 8, 2011 at 2:54 PM, James Robinson <jamesr at google.com> wrote:

> On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>>
>> Using this value as a clock for media synchronization sounds appealing but
>> is complicated by audio clock drift. When you play N seconds of audio, it
>> might take slightly more or less time to actually play, so it's hard to keep
>> media times perfectly in sync with another timing source. Just something to
>> keep in mind.
>>
>
> True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
> use a unified time base (see
> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
> so if we do end up with APIs saying "play this sound at time X", like Chris
> Roger's proposed Web Audio API provides, it'll be really handy if we have a
> unified timescale for everyone to refer to.
>

Is that unified time base in sync with the system clock, and how accurate is
it? I'm concerned about the possibility that it's not feasible to keep the
audio hardware clock in sync with the system clock, at least on some
platforms. In that case, we probably need to keep media playback and
animations in sync with the audio hardware clock, and we could even expose
that via some DOM API, but you might not want to use the same clock for
other purposes, such general performance timing for example ... I've heard
the audio clock drift is often significant.

I'm not sure if this is a real problem or not, I just want to make sure.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From hugh.guiney at gmail.com  Fri Jul  8 21:29:03 2011
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Sat, 9 Jul 2011 00:29:03 -0400
Subject: [whatwg] Call for Clarification of the Menu Element Et Al.
Message-ID: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>

Hey All,

I was in the process of coding a prototype for a site I'm working on
when I decided that certain nav's should actually be menu's.

While the basic concept is apparent, unfortunately, with zero browser
implementation at this time, it is impossible to actually know what my
markup is doing (or rather, would do).

So?I looked to the spec for guidance, but ultimately it leaves me very
confused. These are some points I feel could be addressed, in no
particular order:


1. How does one know whether to wrap a nested menu in li or leave it
as a direct child element? Are these semantically-equivalent "coding
styles" or is there a difference?

1.1. When marking up a menu specifically with *multiple* menu items,
is menu/li the only way to do it or would menu/menu also be
appropriate?

2. What is the difference between a menu containing command elements
and a menu containing form controls? Do they merely favor future and
legacy UAs respectively?

3. The spec should provide examples demonstrating when it is better to
use context vs. toolbar vs. list, as these are very similar in
concept. I could easily see them being misappropriated.

4. In the first example, what renders the button UI? Is it
menu[@type=toolbar]/li, or li/menu? Or is it implied CSS?

4.1. Furthermore, should this example even depict a button UI, given
that most graphical interfaces display top-level toolbars as
text/icons against a [mostly] solid background Were a UA to render the
example as demonstrated, would designers not have to style away the
button appearance in order to achieve a look & feel that matches user
expectation?

Obviously, this would not be the case in "secondary" (or n-ary)
toolbars, for instance as in word processors, where everything below
the initial row are usually buttons. Could there be a way, then,
whether in markup or CSS, to denote whether a toolbar is displayed as
a "primary"/"top-level" toolbar or not?

5. Provide more/graphical/clearer examples, to aid both browser
vendors in deciding how to implement the elements, and authors in
having an idea of what result they can expect from using them. The NPC
form, for instance, does not say exactly what it is or does, nor does
it represent a common UI convention. The only thing I can think of
that comes close is Spotlight in OS X (if I'm interpreting it
correctly), which I don't think I've ever seen in a [presumed] game
before.

6. How is the command element rendered within a menu context when
JavaScript is disabled? Is it meant only for non-essential actions? If
it isn't, shouldn't it be able to be non-empty, so it can fallback to
links or buttons? Or is the only possible fallback replicating every
command with form controls that aren't direct children of the parent
menu?

6.1 On that note, why is the spec enabling the use of unstyled spans
to achieve alternative rendering? Doesn't this give meaning (however
contextual) to an element that is supposed to be semantically neutral?

7. Is the menu element always to be rendered in-page or could it be
displayed within the OS itself? Kroc Camen
(suggests)[http://camendesign.com/blog/stop_this_madness] the latter
but at present there is nothing in the spec about such an
implementation. If this is left up to the UA how will developers know
how/if to style it without using browser detection?


Guidance, insight, reactions?

Thank you,
Hugh

From philipj at opera.com  Fri Jul  8 23:41:39 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Sat, 09 Jul 2011 08:41:39 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107082315080.20871@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
	<Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
	<op.vybmxfiqsr6mfa@philip-pc>
	<Pine.LNX.4.64.1107082315080.20871@ps20323.dreamhostps.com>
Message-ID: <op.vyb97pqmsr6mfa@philip-pc>

On Sat, 09 Jul 2011 01:19:02 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Sat, 9 Jul 2011, Philip J?genstedt wrote:
>>
>> Step 11 is "If current has an itemprop attribute specified, add it to
>> results." but should be "If current has one or more property names, add
>> it to results." Property names are defined in
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names
>>
>> Why? If you start with <div itemprop="foo">, then
>> div.itemProp.remove("foo") would give you <div itemprop="">. It'd be
>> weird if the element still showed up in the properties collection after
>> removing the only property name.
>
> The .properties attribute "must return an HTMLPropertiesCollection rooted
> at the Document node, whose filter matches only elements that have
> property names", which further filters the results of the algorithm.
> Similarly, everything that uses the algorithm here does things "for each
> property name", so if itemprop="" doesn't have any tokens, nothing  
> happens
> and it doesn't matter that the algorithm returns it.

Ah, I see my misunderstanding.

Purely editorial: It would, IMO, be more clear if that check were in the  
algorithm itself. That's the way it's going to be (has been) implemented  
since there's no reason to do the filtering as a separate step. Do as you  
wish.

-- 
Philip J?genstedt
Core Developer
Opera Software

From ajvincent at gmail.com  Sun Jul 10 01:08:46 2011
From: ajvincent at gmail.com (Alex Vincent)
Date: Sun, 10 Jul 2011 01:08:46 -0700
Subject: [whatwg] <input type="password">... restrict reading value from JS?
Message-ID: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>

This is just an idea.

For the last 10+ years, password inputs have been accessible from scripts,
with nary a complaint.  If I have this code:

  <form action="javascript:void">
    <div>
      <input type="password" id="pw">
      <button onclick="alert(document.getElementById('pw').value)">Show
password!</button>
    </div>
  </form>

I can extract the password by clicking on the button.  More to the point,
with a XHR I can send that password somewhere it shouldn't go... (well, with
cross-domain security code, maybe not, but that's not the point.)

To be honest, I can think of only two good reasons for checking a password
field's value.  The first is to compare against another password field.  The
second is to check the strength of the password.  In both cases, JavaScript
doesn't necessarily need the actual value - if the API provides other ways
to do that.

Specifically, I would suggest two methods for this input type:

/**
 * Check if a password field's value matches another.
 *
 * @param otherPassword Another password element.
 *
 * @throws Error if this.type != "password"
 * @throws Error if other.type != "password"
 *
 * @returns Boolean True if the fields match.
 */
boolean passwordEquals(in HTMLInputElement otherPassword);

/**
 * Check the strength of the password.
 *
 * @param type The type of check to execute.
 *
 * @returns 0 if dangerously low security
 * @returns 1 if "soon-to-be-deprecated" low security
 * @returns 2 if adequate security
 * @returns 3 if good security
 * @returns 4 if strong security
 * @returns 5 if entropy-death-of-the-universe security :-)
 */
unsigned octet passwordStrength(in DOMString type);

The first idea has been suggested before:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000700.html

I don't know if the second idea has been suggested before.
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

From dennis at efjot.de  Sun Jul 10 02:25:45 2011
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Sun, 10 Jul 2011 11:25:45 +0200
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <op.vyecg7kf48yz2f@dennis-laptop.speedport-w-303v-typ-a>

Hello Alex,

may I ask: Why? This would only cover a few cases of cross-site-scripting
attacks. It would not make a website more secure.

As to the suggestion, I have one little concern: It should not be possible
to WRITE those SecurePassword values. You only wrote "reading"...

Also it would cripple communications. If you can't read the password, all
Ajax is useless. You would have to submit the password by a http POST.

About the password strength: W3C would have to make a "worldwide standard"
on which passwords are secure and which not. This is not the philosophy
however, leaving just guidelines and not how the actual implementation
should go.

But I also have good sides about this: Online banking would be more secure,
with all javascript failing on it now. A browser could also store the
password in a secure manner and not even keep the original one, like
SHA'ing it a 10.000 times. The server would have the original password
or the same hash or some really mathematically generated hash that can
somehow compare to the hash sent by the user while being different AND not
storing the original password (is this even possible?). But this would also
cut into browser makers how they do their implementation, and thats not  
really
the philosophy here.

I still only see very few things like online banking that doesn't use
Ajax anyway profiting from this.

Am 10.07.2011, 10:08 Uhr, schrieb Alex Vincent <ajvincent at gmail.com>:

> This is just an idea.
>
> For the last 10+ years, password inputs have been accessible from  
> scripts,
> with nary a complaint.  If I have this code:
>
>   <form action="javascript:void">
>     <div>
>       <input type="password" id="pw">
>       <button onclick="alert(document.getElementById('pw').value)">Show
> password!</button>
>     </div>
>   </form>
>
> I can extract the password by clicking on the button.  More to the point,
> with a XHR I can send that password somewhere it shouldn't go... (well,  
> with
> cross-domain security code, maybe not, but that's not the point.)
>
> To be honest, I can think of only two good reasons for checking a  
> password
> field's value.  The first is to compare against another password field.   
> The
> second is to check the strength of the password.  In both cases,  
> JavaScript
> doesn't necessarily need the actual value - if the API provides other  
> ways
> to do that.
>
> Specifically, I would suggest two methods for this input type:
>
> /**
>  * Check if a password field's value matches another.
>  *
>  * @param otherPassword Another password element.
>  *
>  * @throws Error if this.type != "password"
>  * @throws Error if other.type != "password"
>  *
>  * @returns Boolean True if the fields match.
>  */
> boolean passwordEquals(in HTMLInputElement otherPassword);
>
> /**
>  * Check the strength of the password.
>  *
>  * @param type The type of check to execute.
>  *
>  * @returns 0 if dangerously low security
>  * @returns 1 if "soon-to-be-deprecated" low security
>  * @returns 2 if adequate security
>  * @returns 3 if good security
>  * @returns 4 if strong security
>  * @returns 5 if entropy-death-of-the-universe security :-)
>  */
> unsigned octet passwordStrength(in DOMString type);
>
> The first idea has been suggested before:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000700.html
>
> I don't know if the second idea has been suggested before.

From lcamtuf at coredump.cx  Sun Jul 10 03:21:03 2011
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Sun, 10 Jul 2011 03:21:03 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>

> For the last 10+ years, password inputs have been accessible from scripts,
> with nary a complaint. ?If I have this code:

Denying access to password fields from JavaScript is actually a
somewhat interesting security enhancement when you consider the
behavior of password managers. Right now, if you exploit an XSS on
https://www.mybank.com, you can navigate the browser to the login
form, wait for the user name and password field to be autocompleted,
grab the data, and effectively turn your transient access into
long-lived credentials theft.

Unfortunately, the problem is not that easy to fix: denying access to
the field does not prevent the attacker from changing the form
submission URL after autocompletion to achieve the same; or even
simply changing method from POST to GET, setting target=foo, and
leveraging same-origin access to the post-submit page to read back the
password-containing URL.

/mz

From ajvincent at gmail.com  Sun Jul 10 03:44:53 2011
From: ajvincent at gmail.com (Alex Vincent)
Date: Sun, 10 Jul 2011 03:44:53 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
Message-ID: <CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>

On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski <lcamtuf at coredump.cx>wrote:

> > For the last 10+ years, password inputs have been accessible from
> scripts,
> > with nary a complaint.  If I have this code:
>
> Unfortunately, the problem is not that easy to fix: denying access to
> the field does not prevent the attacker from changing the form
> submission URL after autocompletion to achieve the same...


Or even simpler, changing the type attribute to something like "hidden" for
an instant.

I hate it when I don't think things through.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

From dennis at efjot.de  Sun Jul 10 07:03:30 2011
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Sun, 10 Jul 2011 16:03:30 +0200
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
Message-ID: <op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>

How about deleting the value if the input type is changed away from the
secure password input type AND that the secure password can only be
submitted to a similar URI.

Am 10.07.2011, 12:44 Uhr, schrieb Alex Vincent <ajvincent at gmail.com>:

> On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski  
> <lcamtuf at coredump.cx>wrote:
>
>> > For the last 10+ years, password inputs have been accessible from
>> scripts,
>> > with nary a complaint.  If I have this code:
>>
>> Unfortunately, the problem is not that easy to fix: denying access to
>> the field does not prevent the attacker from changing the form
>> submission URL after autocompletion to achieve the same...
>
>
> Or even simpler, changing the type attribute to something like "hidden"  
> for
> an instant.
>
> I hate it when I don't think things through.
>


-- 
Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/

From lcamtuf at coredump.cx  Sun Jul 10 12:17:39 2011
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Sun, 10 Jul 2011 12:17:39 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
	<op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>
Message-ID: <CALx_OUCRQYpdTHdVkntYKpqJ8cABFw6v+ESEVvu1tKVzfpNFKw@mail.gmail.com>

> How about deleting the value if the input type is changed away from the
> secure password input type AND that the secure password can only be
> submitted to a similar URI.

Right now, for interoperability, password managers allow a good amount
of fuzziness when matching forms, and I do not believe they pay a lot
of attention to form method, allow the URL and fields to change
slightly, etc. So it's hard to tell an XSS-injected password form from
the real deal.

Instead of a complicated technical solution, some browsers require a
distinctive user gesture before autocompleting login forms. But then,
other vendors believe that this is unacceptable from usability
perspective.

/mz

From dennis at efjot.de  Sun Jul 10 13:11:00 2011
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Sun, 10 Jul 2011 22:11:00 +0200
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CALx_OUCRQYpdTHdVkntYKpqJ8cABFw6v+ESEVvu1tKVzfpNFKw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
	<op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>
	<CALx_OUCRQYpdTHdVkntYKpqJ8cABFw6v+ESEVvu1tKVzfpNFKw@mail.gmail.com>
Message-ID: <op.vye6cmfc48yz2f@dennis-laptop.speedport-w-303v-typ-a>

Hello,

Opera, for example, requires you to hit the "wand" or "login" button before
it even does any autocompletion.

I wish all browsers would implement it like this instead of just... Filling
it out before the user can interact. Makes reading easy.



Am 10.07.2011, 21:17 Uhr, schrieb Michal Zalewski <lcamtuf at coredump.cx>:

>> How about deleting the value if the input type is changed away from the
>> secure password input type AND that the secure password can only be
>> submitted to a similar URI.
>
> Instead of a complicated technical solution, some browsers require a
> distinctive user gesture before autocompleting login forms. But then,
> other vendors believe that this is unacceptable from usability
> perspective.
>
> /mz


-- 
Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/

From Simetrical+w3c at gmail.com  Sun Jul 10 13:38:30 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sun, 10 Jul 2011 16:38:30 -0400
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>

On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> This is just an idea.
>
> For the last 10+ years, password inputs have been accessible from scripts,
> with nary a complaint. ?If I have this code:
>
> ?<form action="javascript:void">
> ? ?<div>
> ? ? ?<input type="password" id="pw">
> ? ? ?<button onclick="alert(document.getElementById('pw').value)">Show
> password!</button>
> ? ?</div>
> ?</form>
>
> I can extract the password by clicking on the button. ?More to the point,
> with a XHR I can send that password somewhere it shouldn't go... (well, with
> cross-domain security code, maybe not, but that's not the point.)

You can send it anyway by changing the action attribute on the form
and calling submit().  So what attack scenario are you actually
avoiding here?  You'd need a really strong security benefit for it to
be possible to even contemplate breaking so many websites.

From sean at pbwhere.com  Mon Jul 11 06:29:23 2011
From: sean at pbwhere.com (Sean Connelly)
Date: Mon, 11 Jul 2011 09:29:23 -0400
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
Message-ID: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>

As a web developer, if I wanted access to the password, I would then avoid
using the <input type="password"> field, and create my own field that reads
characters (perhaps via onkeyup), and fakes a password field visually.

I also think it's a bad idea to change the behavior of <input
type="password"> because it will break websites that assumed they could read
the value.  Perhaps a website checks against a user's past 10 passwords to
see if they are using the same one, via XHR.  Or perhaps the entire login
process is XHR.  Who knows.

I think there is definite room for improvements in security when it comes to
<input type="password">, and I've also been trying to make it more secure by
designing some sort of client-side hashing.  But I don't think restricting
JavaScript from reading the value is a security benefit... in my opinion, it
would just be a hassle for developers who need to read the value, and force
them to use another means of password entry where they can read the value.

~Sean



On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> > This is just an idea.
> >
> > For the last 10+ years, password inputs have been accessible from
> scripts,
> > with nary a complaint.  If I have this code:
> >
> >  <form action="javascript:void">
> >    <div>
> >      <input type="password" id="pw">
> >      <button onclick="alert(document.getElementById('pw').value)">Show
> > password!</button>
> >    </div>
> >  </form>
> >
> > I can extract the password by clicking on the button.  More to the point,
> > with a XHR I can send that password somewhere it shouldn't go... (well,
> with
> > cross-domain security code, maybe not, but that's not the point.)
>
> You can send it anyway by changing the action attribute on the form
> and calling submit().  So what attack scenario are you actually
> avoiding here?  You'd need a really strong security benefit for it to
> be possible to even contemplate breaking so many websites.
>

From me at tom.id.au  Mon Jul 11 07:17:23 2011
From: me at tom.id.au (Tom O'Connor)
Date: Tue, 12 Jul 2011 00:17:23 +1000
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
	<CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
Message-ID: <4E1B05F3.9000809@tom.id.au>

We would likely end up with some more of these lovely interfaces: 
https://online.westpac.com.au/

Try using that without a mouse and not going insane/grossly disclosing 
your input to anyone paying mild attention to your screen.

Tom

On 11/07/2011 23:29, Sean Connelly wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the<input type="password">  field, and create my own field that reads
> characters (perhaps via onkeyup), and fakes a password field visually.
>
> I also think it's a bad idea to change the behavior of<input
> type="password">  because it will break websites that assumed they could read
> the value.  Perhaps a website checks against a user's past 10 passwords to
> see if they are using the same one, via XHR.  Or perhaps the entire login
> process is XHR.  Who knows.

From svartman95 at gmail.com  Mon Jul 11 09:11:52 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 11 Jul 2011 16:11:52 +0000
Subject: [whatwg] Call for Clarification of the Menu Element Et Al.
In-Reply-To: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
References: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
Message-ID: <4E1B20C8.8080207@gmail.com>

?ann lau  9.j?l 2011 04:29, skrifa?i Hugh Guiney:
> 6.1 On that note, why is the spec enabling the use of unstyled spans
> to achieve alternative rendering? Doesn't this give meaning (however
> contextual) to an element that is supposed to be semantically neutral?
>
Can you think of any other uses for spans? Theoretically you could just 
want to identify text for later reference, but this need is better 
served by divs. If you want to reference a few words, you're probably 
better off quoting them (and citing a greater resource containing those 
words and context).

From svartman95 at gmail.com  Mon Jul 11 10:11:22 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 11 Jul 2011 17:11:22 +0000
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <4E1B2EBA.40809@gmail.com>

?ann sun 10.j?l 2011 08:08, skrifa?i Alex Vincent:
> /**
>   * Check if a password field's value matches another.
>   *
>   * @param otherPassword Another password element.
>   *
>   * @throws Error if this.type != "password"
>   * @throws Error if other.type != "password"
>   *
>   * @returns Boolean True if the fields match.
>   */
> boolean passwordEquals(in HTMLInputElement otherPassword);
>
I believe this to belong to CSS. User agents could either ask or require 
users to input error-prone and important fields twice, without 
submitting the same value twice. This could be the default rendering (in 
some UAs) for strong inputs (i.e. <input> descendants of <strong>). This 
has the potential benefit of allowing media-aware prefixes for locales 
where that makes sense (as in 'Retype Password' vs 'Confirm Password'). 
Note that the confirmation input in 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-required-attribute> 
is optional.

<!DOCTYPE html>
<title>Register a FooBar account</title>
<form action=register method=POST>
<label>Username	<input name=user	required></label>
<strong><input type=password name=pass	required></strong>
</form>

> /**
>   * Check the strength of the password.
>   *
>   * @param type The type of check to execute.
>   *
>   * @returns 0 if dangerously low security
>   * @returns 1 if "soon-to-be-deprecated" low security
>   * @returns 2 if adequate security
>   * @returns 3 if good security
>   * @returns 4 if strong security
>   * @returns 5 if entropy-death-of-the-universe security :-)
>   */
> unsigned octet passwordStrength(in DOMString type);
>
I don't think this is a good idea. Can't user-agents warn about insecure 
passwords without the help of author-supplied scripts?

From svartman95 at gmail.com  Mon Jul 11 10:52:36 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 11 Jul 2011 17:52:36 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
Message-ID: <4E1B3864.9050207@gmail.com>

On 7/8/11, Jeremy Keith <jeremy at adactio.com> wrote:
> Bjartur wrote:
>> Citation will most likely contain the cited resource (@cite), the title
>> of the cited resource (@title) and the date and optionally time of the
>> quote (@datetime?).
>
> All three of which are invisible and so do not match the use cases that Oli
> has outlined.
>
> At least @title has a tooltip but the @cite attribute has proven to be a
> complete disaster, unsupported by user agents and ignored by authors,
I'd like to reemphasize that:
> *unsupported by user agents*
So you're saying that because attributes aren't rendered by default, 
user agents will ignore them and thus we should not use them? Why can't 
we fix UAs? Putting attribution inside <blockquote>s seems like a hack 
around lax support for attributes. That what's CSS is for.


> precisely because it is *hidden* metadata.
> http://www.well.com/~doctorow/metacrap.htm
Yes, people lie. Unless you're arguing that using attribute syntax will 
encourage misquoting, I'll regard this article as interesting, 
correcting and unrelated. The article argues against searching for 
information in uncensored repositories of structured data prone to 
spamming, not typing <footer>asdf</footer> instead of title="asdf".

> So I think that we can learn from the history of the @cite attribute in that
> it shows us how *not* to do it.
>
>> But is it really possible to mark such citations up without presentational
>> elements?
>
> I'm not sure I understand the question. Do you mean "presentational" as in
> "not conveying semantics" or "presentational" as in "visible"?
>
Not conveying semantics. I'm not arguing against rendering attribution. 
On the contrary, IMO user agents should render at least the title of the 
cited resource. Interactive user agents should additionally make the 
cited resource available in manner similar to how they present other 
hyperlinked resources. Additionally user agents with superfluous screen 
space may render the datetime. Handheld renderings should of course not 
display the datetime without user interaction, but reserve the screen 
estate for more critical information, such as the quotation itself.

It's simply a question of
<blockquote>
	Lorem ipsum
<footer>
<a href="kennitala:2112952019" title="Bjartur Thorlacius">Bjartur</a>
on <time datetime="1997-4-2">the second April, 1997</time>
</footer>
</blockquote>
vs
<blockquote title="Bjartur Thorlacius" datetime="1997-4-2" 
cite="kennitala:2112952019">
	Lorem ipsum
</blockquote>

From jackalmage at gmail.com  Mon Jul 11 11:03:35 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Jul 2011 11:03:35 -0700
Subject: [whatwg] Call for Clarification of the Menu Element Et Al.
In-Reply-To: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
References: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
Message-ID: <CAAWBYDA17hB=R0+rceYSAkY_hitxWnu40uO3zOcd70y-7g65OQ@mail.gmail.com>

On Fri, Jul 8, 2011 at 9:29 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> Hey All,
>
> I was in the process of coding a prototype for a site I'm working on
> when I decided that certain nav's should actually be menu's.
>
> While the basic concept is apparent, unfortunately, with zero browser
> implementation at this time, it is impossible to actually know what my
> markup is doing (or rather, would do).

Really, since there are no browser implementations yet, it's best to
*not* use it yet.  Without any feedback in the form of actually seeing
it work, there's a good chance you'll accidentally get it wrong.  As
well, your early use of it counts as legacy usage if we decide that,
upon attempting to implement it, it needs to be changed.

I'll go ahead and answer the rest of your email as if you were
speaking from a hypothetical position, but take what I said into
account.  Using something pre-implementation doesn't help you, and it
has a chance of hurting the feature in the future.


> So?I looked to the spec for guidance, but ultimately it leaves me very
> confused. These are some points I feel could be addressed, in no
> particular order:
>
>
> 1. How does one know whether to wrap a nested menu in li or leave it
> as a direct child element? Are these semantically-equivalent "coding
> styles" or is there a difference?
>
> 1.1. When marking up a menu specifically with *multiple* menu items,
> is menu/li the only way to do it or would menu/menu also be
> appropriate?
>
> 2. What is the difference between a menu containing command elements
> and a menu containing form controls? Do they merely favor future and
> legacy UAs respectively?

Mostly, yes, though in some cases using form elements lets you define
certain types of commands more easily.  For example, you can use
<select> to define a group of type=radio commands more easily/tersely
than if you used <input type=radio name=foo> or <command type=radio
radiogroup=foo>:


> 3. The spec should provide examples demonstrating when it is better to
> use context vs. toolbar vs. list, as these are very similar in
> concept. I could easily see them being misappropriated.

"context" is meant for right-click menus, hooked to an element by
specifying the @contextmenu attribute on an element and pointing it to
the <menu>.  Note that the default CSS of a <menu type=context> is
display:none.

I don't really understand the difference between "toolbar" and "list".


> 4. In the first example, what renders the button UI? Is it
> menu[@type=toolbar]/li, or li/menu? Or is it implied CSS?

Implied CSS or UA magic.


> 4.1. Furthermore, should this example even depict a button UI, given
> that most graphical interfaces display top-level toolbars as
> text/icons against a [mostly] solid background Were a UA to render the
> example as demonstrated, would designers not have to style away the
> button appearance in order to achieve a look & feel that matches user
> expectation?
>
> Obviously, this would not be the case in "secondary" (or n-ary)
> toolbars, for instance as in word processors, where everything below
> the initial row are usually buttons. Could there be a way, then,
> whether in markup or CSS, to denote whether a toolbar is displayed as
> a "primary"/"top-level" toolbar or not?

This is something that'll be worked out as browsers actually implement things.


> 5. Provide more/graphical/clearer examples, to aid both browser
> vendors in deciding how to implement the elements, and authors in
> having an idea of what result they can expect from using them. The NPC
> form, for instance, does not say exactly what it is or does, nor does
> it represent a common UI convention. The only thing I can think of
> that comes close is Spotlight in OS X (if I'm interpreting it
> correctly), which I don't think I've ever seen in a [presumed] game
> before.

Patches welcome.  ^_^  Any suggested examples?


> 6. How is the command element rendered within a menu context when
> JavaScript is disabled? Is it meant only for non-essential actions? If
> it isn't, shouldn't it be able to be non-empty, so it can fallback to
> links or buttons? Or is the only possible fallback replicating every
> command with form controls that aren't direct children of the parent
> menu?

If you're designing something to be a context menu, it likely won't
work at all without Javascript.  You'd need a significantly different
UI.


> 6.1 On that note, why is the spec enabling the use of unstyled spans
> to achieve alternative rendering? Doesn't this give meaning (however
> contextual) to an element that is supposed to be semantically neutral?

Slightly.  I don't think it's a big deal, but shrug.  Note that *any*
element would work there to hide the submit button from the "build a
menu" algorithm.


> 7. Is the menu element always to be rendered in-page or could it be
> displayed within the OS itself? Kroc Camen
> (suggests)[http://camendesign.com/blog/stop_this_madness] the latter
> but at present there is nothing in the spec about such an
> implementation. If this is left up to the UA how will developers know
> how/if to style it without using browser detection?

This is another thing that'll be worked out as browsers implement.

~TJ

From jackalmage at gmail.com  Mon Jul 11 11:12:07 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Jul 2011 11:12:07 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
Message-ID: <CAAWBYDDmjM62getBqSRFvt9FzBL9ZtaZ96cVwZDu_wLupoiJEA@mail.gmail.com>

On Sun, Jul 10, 2011 at 3:44 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski <lcamtuf at coredump.cx>wrote:
>> > For the last 10+ years, password inputs have been accessible from
>> scripts,
>> > with nary a complaint. ?If I have this code:
>>
>> Unfortunately, the problem is not that easy to fix: denying access to
>> the field does not prevent the attacker from changing the form
>> submission URL after autocompletion to achieve the same...
>
>
> Or even simpler, changing the type attribute to something like "hidden" for
> an instant.
>
> I hate it when I don't think things through.

To be fair, we already protect <input type=file> from vaguely similar
type-changing attacks.  (You can't make an <input type=text>, fill it
with a filename as the value, then switch to type=file and submit it
to steal files from the user.)

However, as noted, doing this wouldn't help in any way.  The script
can redirect the form submission, or just swap out the input entirely
for an <input type=text> that they manually intercept clicks on and
insert * for each keypress (or more deviously, set the font-family for
the text input to a font where every glyph is an asterisk, and then
just read out the value normally).

~TJ

From Simetrical+w3c at gmail.com  Mon Jul 11 11:31:57 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 11 Jul 2011 14:31:57 -0400
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
	<CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
Message-ID: <CAKA+AxntHAU7YNzeGEDxCOzGGbfmZn4xjFfCfwMui6=n1VYY4Q@mail.gmail.com>

On Mon, Jul 11, 2011 at 9:29 AM, Sean Connelly <sean at pbwhere.com> wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the <input type="password"> field, and create my own field that reads
> characters (perhaps via onkeyup), and fakes a password field visually.

Then browsers wouldn't autofill it, which would defeat the nastiest
attack here (stealing passwords without user intervention).  But as
noted, you can always submit the form, so it really doesn't help that
much anyway.

From acolwell at google.com  Mon Jul 11 11:42:59 2011
From: acolwell at google.com (Aaron Colwell)
Date: Mon, 11 Jul 2011 11:42:59 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending media
	data to a HTMLMediaElement
Message-ID: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>

Hi,

Based on comments in the File API Streaming
Blobs<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029973.html>
thread and
my Extending HTML 5 video for adaptive
streaming<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032277.html>
thread,
I decided on taking a stab at writing a MediaSource API
spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>
for
streaming data to a media tag.

Please take a look at the
spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>and
provide some feedback.

I've tried to start with the simplest thing that would work and hope to
expand from there if need be. For now, I'm intentionally not trying to solve
the generic streaming file case because I believe there might be media
specific requirements around handling seeking especially if we intend to
support non-packetized media streams like WAV.

If the feedback is generally positive on this approach, I'll start working
on patches for WebKit & Chrome so people can experiment with an actual
implementation.

Thanks,
Aaron

From crogers at google.com  Mon Jul 11 12:23:33 2011
From: crogers at google.com (Chris Rogers)
Date: Mon, 11 Jul 2011 12:23:33 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
Message-ID: <CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>

On Fri, Jul 8, 2011 at 4:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> , On Fri, Jul 8, 2011 at 2:54 PM, James Robinson <jamesr at google.com>
> wrote:
>
> > On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org
> >wrote:
> >
> >>
> >> Using this value as a clock for media synchronization sounds appealing
> but
> >> is complicated by audio clock drift. When you play N seconds of audio,
> it
> >> might take slightly more or less time to actually play, so it's hard to
> keep
> >> media times perfectly in sync with another timing source. Just something
> to
> >> keep in mind.
> >>
> >
> > True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified
> to
> > use a unified time base (see
> >
> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html
> )
> > so if we do end up with APIs saying "play this sound at time X", like
> Chris
> > Roger's proposed Web Audio API provides, it'll be really handy if we have
> a
> > unified timescale for everyone to refer to.
> >
>
> Is that unified time base in sync with the system clock, and how accurate
> is
> it? I'm concerned about the possibility that it's not feasible to keep the
> audio hardware clock in sync with the system clock, at least on some
> platforms. In that case, we probably need to keep media playback and
> animations in sync with the audio hardware clock, and we could even expose
> that via some DOM API, but you might not want to use the same clock for
> other purposes, such general performance timing for example ... I've heard
> the audio clock drift is often significant.
>
> I'm not sure if this is a real problem or not, I just want to make sure.
>
> Rob
>

Hi Robert, I think the clock that James is proposing is effectively the
system clock (such as mach_absolute_time() or QueryPerformanceCounter()).  I
completely agree with your concerns about clock drift of this type of clock
with the audio hardware clock, since they're almost always running off
different crystals.  That said, I still think it's useful to have a
high-resolution system clock which is monotonically increasing.  On Mac OS X
the mach_absolute_time() system clock is used extensively in the media APIs,
CoreVideo, CoreAudio, CoreMIDI, etc. to synchronize events according to a
common time base:

CoreAudio:
http://developer.apple.com/library/mac/#documentation/MusicAudio/Reference/CoreAudioDataTypesRef/Reference/reference.html#//apple_ref/c/tdef/AudioTimeStamp

CoreVideo:
http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html

CoreMIDI ( see MIDITimeStamp: A host clock time ----  typedef UInt64
MIDITimeStamp; )
http://developer.apple.com/library/ios/#documentation/CoreMidi/Reference/MIDIServices_Reference/Reference/reference.html#//apple_ref/doc/uid/TP40010316

mach_absolute_time():
http://developer.apple.com/library/mac/#qa/qa1398/_index.html

In the CoreAudio case, the AudioTimeStamp contains *both* the host-time
(system clock) and the sample time (based on audio hardware).  This creates
a relationship between the two clocks.  As an example of how these two
clocks can be used together for synchronization, audio applications use the
high-resolution timestamp of incoming MIDI messages to schedule audio
synthesis to happen with very low jitter by doing sample-accurate scheduling
when rendering the audio stream.

Because of clock-drift, the system clock that James is proposing cannot
*directly* be the same clock as what I'm proposing in the Web Audio API
AudioContext .currentTime attribute.  But there are ways to translate
between the two in very useful ways.

I would be in favor of introducing a monotonically increasing
high-resolution system clock such as James is proposing, as long as we keep
in mind some of these subtleties.

Chris

From robert at ocallahan.org  Mon Jul 11 17:54:44 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 12 Jul 2011 12:54:44 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
Message-ID: <CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>

It seems to me that the spec is written assuming only one media element is
consuming the MediaSource. But nothing stops multiple elements consuming the
same URL simultaneously. Maybe instead of going through a URL you should add
API directly to media elements.

bytesAvailable is for flow control? Instead of doing it this way, I would
follow WebSockets and use a bufferedAmount attribute to indicate how much
data is currently buffered up. That makes it easy for authors who don't want
to care about flow control to just append stuff without encountering errors,
while still allowing authors who care about flow control to do it.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From robert at ocallahan.org  Mon Jul 11 17:57:56 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 12 Jul 2011 12:57:56 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
Message-ID: <CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>

On Tue, Jul 12, 2011 at 7:23 AM, Chris Rogers <crogers at google.com> wrote:

> In the CoreAudio case, the AudioTimeStamp contains *both* the host-time
> (system clock) and the sample time (based on audio hardware).  This creates
> a relationship between the two clocks.  As an example of how these two
> clocks can be used together for synchronization, audio applications use the
> high-resolution timestamp of incoming MIDI messages to schedule audio
> synthesis to happen with very low jitter by doing sample-accurate scheduling
> when rendering the audio stream.
>
> Because of clock-drift, the system clock that James is proposing cannot
> *directly* be the same clock as what I'm proposing in the Web Audio API
> AudioContext .currentTime attribute.  But there are ways to translate
> between the two in very useful ways.
>

Thanks Chris, I thought you'd know the answer :-).

Suppose we wanted to sync animation (either scripted animation or CSS
animation) to audio. We'd want them to use the audio clock, right?

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From glenn at zewt.org  Mon Jul 11 18:02:50 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 11 Jul 2011 21:02:50 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
	<CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
Message-ID: <CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>

On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> Suppose we wanted to sync animation (either scripted animation or CSS
> animation) to audio. We'd want them to use the audio clock, right?
>

For that you need the play cursor of the actual audio sample you're
synchronizing against, which is typically not strongly tied to the
associated hardware audio clock.  For example, audio underruns may change
their alignment.

-- 
Glenn Maynard

From anant at mozilla.com  Mon Jul 11 19:01:03 2011
From: anant at mozilla.com (Anant Narayanan)
Date: Mon, 11 Jul 2011 19:01:03 -0700
Subject: [whatwg] RTC API Proposal
Message-ID: <4E1BAADF.2080101@mozilla.com>

Hi,

Mozilla and Cisco have been working on an API for real time 
communication, which we sent out today to the W3C WebRTC working group 
(http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html). 
It builds on both the WHATWG RTC proposal by Ian Hickson as well as the 
MediaStream Processing API by Robert O'Callahan.

There are few differences though, and they are presented at:
http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0012.html

The proposal itself lives at:
https://github.com/mozilla/rainbow/wiki/RTC_API_Proposal

There is some discussion going on about the proposal on the W3C list but 
we would love to hear your feedback.

Thanks,
-Anant

From robert at ocallahan.org  Mon Jul 11 19:35:28 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 12 Jul 2011 14:35:28 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
	<CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
	<CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>
Message-ID: <CAOp6jLYaxrtZRiAJ_e3vCJu8ej521qNqoie4XgCpdavm-xGNJg@mail.gmail.com>

On Tue, Jul 12, 2011 at 1:02 PM, Glenn Maynard <glenn at zewt.org> wrote:

> On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> Suppose we wanted to sync animation (either scripted animation or CSS
>> animation) to audio. We'd want them to use the audio clock, right?
>>
>
> For that you need the play cursor of the actual audio sample you're
> synchronizing against, which is typically not strongly tied to the
> associated hardware audio clock.  For example, audio underruns may change
> their alignment.
>

OK, but it's the audio clock with some adjustments, right? Definitely not
the system clock.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From glenn at zewt.org  Mon Jul 11 19:41:47 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 11 Jul 2011 22:41:47 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLYaxrtZRiAJ_e3vCJu8ej521qNqoie4XgCpdavm-xGNJg@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
	<CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
	<CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>
	<CAOp6jLYaxrtZRiAJ_e3vCJu8ej521qNqoie4XgCpdavm-xGNJg@mail.gmail.com>
Message-ID: <CABirCh-Gc8UMPnN6+Xhi1d2M77BmqXCKSWSd43i0-Q5YAHPk+g@mail.gmail.com>

On Mon, Jul 11, 2011 at 10:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Jul 12, 2011 at 1:02 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> Suppose we wanted to sync animation (either scripted animation or CSS
>>> animation) to audio. We'd want them to use the audio clock, right?
>>>
>>
>> For that you need the play cursor of the actual audio sample you're
>> synchronizing against, which is typically not strongly tied to the
>> associated hardware audio clock.  For example, audio underruns may change
>> their alignment.
>>
>
> OK, but it's the audio clock with some adjustments, right? Definitely not
> the system clock.
>

Right.

-- 
Glenn Maynard

From jonas at sicking.cc  Mon Jul 11 20:14:09 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 11 Jul 2011 20:14:09 -0700
Subject: [whatwg] RTC API Proposal
In-Reply-To: <4E1BAADF.2080101@mozilla.com>
References: <4E1BAADF.2080101@mozilla.com>
Message-ID: <CA+c2ei8wO6xgHRnhQ3MqfZESo-g71QSsAmeLKjyRL6ZNvqSomQ@mail.gmail.com>

On Mon, Jul 11, 2011 at 7:01 PM, Anant Narayanan <anant at mozilla.com> wrote:
> Hi,
>
> Mozilla and Cisco have been working on an API for real time communication,
> which we sent out today to the W3C WebRTC working group
> (http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html). It
> builds on both the WHATWG RTC proposal by Ian Hickson as well as the
> MediaStream Processing API by Robert O'Callahan.
>
> There are few differences though, and they are presented at:
> http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0012.html
>
> The proposal itself lives at:
> https://github.com/mozilla/rainbow/wiki/RTC_API_Proposal
>
> There is some discussion going on about the proposal on the W3C list but we
> would love to hear your feedback.

Some minor nits:

> constructor PeerListener(DOMString config, optional DOMString negotiationServerURN)
> interface PeerListener {
>     void listen();
>     attribute Function onIncoming;
> };
> Window implements PeerListener;

The WebIDL syntax here is a bit wrong, I suspect you're looking for
something like:

[Constructor(in DOMString config, in optional DOMString negotiationServerURN)]
interface PeerListener {
    void listen();
    attribute Function onIncoming;
};
Window implements PeerListener;

You probably don't mean the last "implements" line. That line
currently says that Windows *are* PerrListeners. I.e. that you can do
window.listen() and window.onIncoming = function() { ... }, which is
likely not what you want. Simply remove the line as declaring the
constructor should be enough.

To keep consistent with all other onfoo listeners, you should use all
lowercase name: onincoming.

It seems like you are saying that the function assigned to onincoming
receives a Connection object as its first argument. However generally
onfoo attributes are EventListeners and so always receives an Event
object as its first and only argument. If your intent is to be
consistent with other onfoo attributes you should instead create a
PeerListenerEvent object which inherits Event and makes the Connection
available as a property on it. You should also make PeerListener an
EventTarget.

In the example where you create a PeerListener, it appears that you're
only passing the second negotiationServerURN argument
("stun:foobar.net:3476"). But the constructor above says that the
first argument is a "config" string, and that it's not optional. I'm
in particular curious what the syntax for the config string is, and if
it would be better done as a Dictionary. Would love to see some
examples.

In the example you also create a PeerConnection object using |new
PeerConnection("stun:foobar.net:3476", sendToB);|. However the
interface declaration for PeerListener does not include a constructor.
I'm trying to figure out how the sendToB and gotFromB functions work
in the "Simple Video Call" example, but it the lack of description for
the PeerListener constructor is preventing that. It also seems like
the gotFromB is unused which I assume is a bug in the example.

/ Jonas

From harald at alvestrand.no  Tue Jul 12 00:31:48 2011
From: harald at alvestrand.no (Harald Alvestrand)
Date: Tue, 12 Jul 2011 09:31:48 +0200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
Message-ID: <4E1BF864.5000904@alvestrand.no>

Not a comment directly on the spec, but you might want to check what 
people are suggesting for interactive media handling in the WEBRTC 
working group.

Streaming is different from interactive media, but it would be a shame 
to have incompatibilities that can be avoided.

On 07/11/11 20:42, Aaron Colwell wrote:
> Hi,
>
> Based on comments in the File API Streaming
> Blobs<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029973.html>
> thread and
> my Extending HTML 5 video for adaptive
> streaming<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032277.html>
> thread,
> I decided on taking a stab at writing a MediaSource API
> spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>
> for
> streaming data to a media tag.
>
> Please take a look at the
> spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>and
> provide some feedback.
>
> I've tried to start with the simplest thing that would work and hope to
> expand from there if need be. For now, I'm intentionally not trying to solve
> the generic streaming file case because I believe there might be media
> specific requirements around handling seeking especially if we intend to
> support non-packetized media streams like WAV.
>
> If the feedback is generally positive on this approach, I'll start working
> on patches for WebKit&  Chrome so people can experiment with an actual
> implementation.
>
> Thanks,
> Aaron
>


From jeremy at adactio.com  Mon Jul 11 16:24:26 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Tue, 12 Jul 2011 00:24:26 +0100
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1B3864.9050207@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
	<4E1B3864.9050207@gmail.com>
Message-ID: <A6490491-963A-4B42-ABAD-3FA37D5DC9FE@adactio.com>

Bjartur wrote:
> I'd like to reemphasize that:
>> *unsupported by user agents*
> So you're saying that because attributes aren't rendered by default, user agents will ignore them and thus we should not use them?

It's not a matter of "should not." Because user agents ignore them, we *do not* use them. And the main reason why we don't use them is that there's little to be gained: the information isn't presented to the end user.

Wishful thinking isn't going to make the @cite attribute any more useful or more widely adopted (either by authors or user agents).

> Putting attribution inside <blockquote>s seems like a hack around lax support for attributes.

No, putting attribution inside <blockquote>s solves the real-world use-cases that Oli has gathered together.

>> I'm not sure I understand the question. Do you mean "presentational" as in
>> "not conveying semantics" or "presentational" as in "visible"?
>> 
> Not conveying semantics.

How can you say that the <footer> element would not convey semantics, when it is defined as follows:

"The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like."
?http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-footer-element

...and the <blockquote> element is a sectioning root. The semantics of those two elements match up perfectly.

> Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources

Can you please give an example of user agents presenting *invisible* hyperlinked resources? @longdesc, perhaps?

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From hsivonen at iki.fi  Tue Jul 12 00:41:18 2011
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 12 Jul 2011 09:41:18 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
Message-ID: <1310456478.2308.7.camel@shuttle>

On Thu, 2011-07-07 at 22:33 +0000, Ian Hickson wrote:
> The JSON algorithm now ends the crawl when it hits a loop, and replaces 
> the offending duplicate item with the string "ERROR".
> 
> The RDF algorithm preserves the loops, since doing so is possible with 
> RDF. Turns out the algorithm almost did this already, looks like it was an 
> oversight.

It seems to me that this approach creates an incentive for people who
want to do RDFesque things to publish deliberately non-conforming
microdata content that works the way they want for RDF-based consumers
but breaks for non-RDF consumers. If such content abounds and non-RDF
consumers are forced to support loopiness but extending the JSON
conversion algorithm in ad hoc ways, part of the benefit of microdata
over RDFa (treeness) is destroyed and the benefit of being well-defined
would be destroyed, too, for non-RDF consumption cases.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/


From whatwg.org at boblet.net  Tue Jul 12 02:15:02 2011
From: whatwg.org at boblet.net (Oli Studholme)
Date: Tue, 12 Jul 2011 18:15:02 +0900
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1B3864.9050207@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<4E16EF63.8080709@gmail.com>
	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
	<4E1B3864.9050207@gmail.com>
Message-ID: <CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>

Hi Bjartur,

Firstly thank you (and you Jeremy!) for your input. This thread will
help decide how the blockquote spec changes to accommodate the use
cases I outlined, so the more input the better.

On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> I'm not arguing against rendering attribution. On
> the contrary, IMO user agents should render at least the title of the cited
> resource.

This is a can of worms as authors will want control over both content
and style. Attributes turned into content are harder to style than
content. Also attributes tend to be for either humans (@alt) or
machines (@datetime), so displaying attributes (for humans) that
contain data (for machines) generally gives bad results.

> Interactive user agents should additionally make the cited
> resource available in manner similar to how they present other hyperlinked
> resources.

In the print use cases I found, sometimes attribution is inline after
the last sentence and sometimes on a following line. This is in
addition to having attribution in the prose surrounding the block
quote, as currently recommended by the spec. How would the user agent
know which way the author wants to present attribution?

> Additionally user agents with superfluous screen space may render
> the datetime. Handheld renderings should of course not display the datetime
> without user interaction, but reserve the screen estate for more critical
> information, such as the quotation itself.

Again I have no idea how a user agent would follow these rules.
Arbitrarily showing one thing in one viewport size and something else
at a different size would be a bug (arbitrarily meaning without
author/user intervention, such as via CSS). Love your phrase
?superfluous screen space? btw ;)

> It's simply a question of
> <blockquote>
> ? ? ? ?Lorem ipsum
> <footer>
> <a href="kennitala:2112952019" title="Bjartur Thorlacius">Bjartur</a>
> on <time datetime="1997-4-2">the second April, 1997</time>
> </footer>
> </blockquote>
> vs
> <blockquote title="Bjartur Thorlacius" datetime="1997-4-2"
> cite="kennitala:2112952019">
> ? ? ? ?Lorem ipsum
> </blockquote>

You've got two additional problems in your example:
* currently only the <time>, <ins> and <del> elements accept the
datetime attribute, and this isn't even a valid datetime value (you
wanted 1997-04-02)
* the cite attribute must be a valid URL, and is for providing a link
to more information about the quote (generally its source) ? you can't
use it for non-URL data
This proves Jeremy's earlier point about attributes being a bad place
to store data. Unless you look at the source you?d never notice these
mistakes.

I also note that your <footer> example contains a lot more content,
the visible part being ?Bjartur on the second April, 1997?. A
potential rendering of the attributes in your second example would
probably be something like ?Bjartur Thorlacius 1997-04-02", which I
think isn?t as good. This refers to my first point about authors
wanting to control the content.

Finally two other strikes against attributes are they're harder for
people learning HTML (which is one reason we have <section> over
role="section" etc), and we already have three (I?d argue) perfectly
good elements for the data you are suggesting adding via attributes:
* <footer> for following-line attribution and notes
* <time> for datetime information
* <a> and <cite> for citation information

There?s also the possibility of adding another inline element, such as
<credit>, which could let someone credit an author of a quote, or e.g.
to credit a photographer of an image together <figure> and
<figcaption>.

For the reasons Jeremy mentioned, I actually hope the cite attribute
gets dropped in favour of a visible, explicit form of attribution.
While something like <a> and <cite> in a <footer> could work for
citation, I still don?t have a good idea about citing explicitly when
the citation is inline (on the last line of the block quote), or for
<q>.

HTH

peace - oli studholme

From svartman95 at gmail.com  Tue Jul 12 04:28:59 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 12 Jul 2011 11:28:59 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>	<4E1B3864.9050207@gmail.com>
	<CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>
Message-ID: <4E1C2FFB.5060909@gmail.com>

?ann ?ri 12.j?l 2011 09:15, skrifa?i Oli Studholme:
> Firstly thank you (and you Jeremy!) for your input. This thread will
> help decide how the blockquote spec changes to accommodate the use
> cases I outlined, so the more input the better.
>
Thank you for your commentary, it is most appreciated.

> On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius
> <svartman95 at gmail.com>  wrote:
>> I'm not arguing against rendering attribution. On
>> the contrary, IMO user agents should render at least the title of the cited
>> resource.
>
> This is a can of worms as authors will want control over both content
> and style. Attributes turned into content are harder to style than
> content. Also attributes tend to be for either humans (@alt) or
> machines (@datetime), so displaying attributes (for humans) that
> contain data (for machines) generally gives bad results.
>
Datetimes will usually be presented in a localized format to humans.

> In the print use cases I found, sometimes attribution is inline after
> the last sentence and sometimes on a following line. This is in
> addition to having attribution in the prose surrounding the block
> quote, as currently recommended by the spec. How would the user agent
> know which way the author wants to present attribution?
>
By fetching and reading a linked stylesheet. I think it's easier to 
style attributes then text nodes polluted with delimiters such as "from" 
and "by" that make reordering hard.
More importantly, how is the author to know how the user wants 
attribution presented?

> Again I have no idea how a user agent would follow these rules.
> Arbitrarily showing one thing in one viewport size and something else
> at a different size would be a bug (arbitrarily meaning without
> author/user intervention, such as via CSS).
A feature to one, a bug to another. The existence of the CSS height and 
width media features suggests that catering style to varying viewport 
sizes is desired by others than just me. I don't see why a user agent 
should seek an authors' permission to style a document for an unusually 
sized viewport, nor require users to write their own stylesheets instead 
of shipping customizable stylesheets.

> Love your phrase
> ?superfluous screen space? btw ;)
:P

>> It's simply a question of
>> <blockquote>
>>         Lorem ipsum
>> <footer>
>> <a href="kennitala:2112952019" title="Bjartur Thorlacius">Bjartur</a>
>> on<time datetime="1997-4-2">the second April, 1997</time>
>> </footer>
>> </blockquote>
>> vs
>> <blockquote title="Bjartur Thorlacius" datetime="1997-4-2"
>> cite="kennitala:2112952019">
>>         Lorem ipsum
>> </blockquote>
>
> You've got two additional problems in your example:
> * currently only the<time>,<ins>  and<del>  elements accept the
> datetime attribute, and this isn't even a valid datetime value (you
> wanted 1997-04-02)
Ops, you're correct; this should've been 1997-04-02. I'm proposing 
adding a datetime attribute to <blockquote>.

> * the cite attribute must be a valid URL, and is for providing a link
> to more information about the quote (generally its source) ? you can't
> use it for non-URL data
For a lack of a valid URI identifying myself, I used an unregistered 
uri-scheme ("kennitala") and my national ID as the scheme-specific part. 
The exact URI in question is unimportant to the example, but I see no 
reason to restrict values of cite to locators only, as opposed to 
identifiers in general. Quoting books identified by ISBN numbers seems 
like a good enough use case to me.

> This proves Jeremy's earlier point about attributes being a bad place
> to store data. Unless you look at the source you?d never notice these
> mistakes.
>
Sure I would, had I actually tried to, say, render them or validate 
before posting them on the Internet. I refrained from doing so as I knew 
this to be invalid markup, anyway. Where datetime to be a valid 
attribute of blockquote

> I also note that your<footer>  example contains a lot more content,
> the visible part being ?Bjartur on the second April, 1997?. A
> potential rendering of the attributes in your second example would
> probably be something like ?Bjartur Thorlacius 1997-04-02", which I
> think isn?t as good. This refers to my first point about authors
> wanting to control the content.
>
No, that would be quite an odd rendering. More likely renderings:

?ann annan apr?l 1997 skrifa?i Bjartur Thorlacius:
 > Lorem ipsum


On the second April, 1997 Bjartur Thorlacius wrote:
 > Lorem ipsum

? Lorem ipsum
	? Bjartur Thorlacius

It all depends on the user's localized stylesheet.

Note that a datetime in a <time> element would have to parsed just as 
date in a datetime attribute of a <blockquote>. They're both machine 
readable (and that's the best way to internationalize dates).
> Finally two other strikes against attributes are they're harder for
> people learning HTML (which is one reason we have<section>  over
> role="section" etc), and we already have three (I?d argue) perfectly
> good elements for the data you are suggesting adding via attributes:
> *<footer>  for following-line attribution and notes
> *<time>  for datetime information
> *<a>  and<cite>  for citation information
>
I've never heard this argument before. I thought we had <section> rather 
than <div role=section> because the latter has a high 
noise-to-information ratio, leading to overly verbose constructs such as:

<div role=section>
[content]
</div> <!-- end section -->

> There?s also the possibility of adding another inline element, such as
> <credit>, which could let someone credit an author of a quote, or e.g.
> to credit a photographer of an image together<figure>  and
> <figcaption>.
>
So <credit> would be an inline version of <footer>, to be contained in 
<q>? Would it not be more consistent to use attributes, in that case? 
Note that <figcaption> may contain <footer>s.

> For the reasons Jeremy mentioned, I actually hope the cite attribute
> gets dropped in favour of a visible, explicit form of attribution.
> While something like<a>  and<cite>  in a<footer>  could work for
> citation, I still don?t have a good idea about citing explicitly when
> the citation is inline (on the last line of the block quote), or for
> <q>.
>
I do: use the same attributes as for <blockquote>.
Referencing people as works as I did in my examples is probably
bad (read: terrible) style. There should be a sepearate @author 
attribute for attributing an author, distinct from the @cite attribute 
for citing the work.

On a third thought, using a <footer> child of <blockquote> doesn't seem 
so confusing after all, but it'd be even less confusing to HTML 
newcomers were it named e.g. <credit>. But then it would not be an 
appropriate element for "fat footers", whatever they are. I don't see 
what citations and "fat footers" have in common.
The semantics of <footer> would be a lot clearer if "fat footers" were 
not to be enclosed in <footer>, but rather in <nav>s or <aside>s.

Were the "fat footers" example in the spec as follows, I'd have fewer 
objections.

...
  <nav>
   <section>
    <h1>Articles</h1>
    <p><img src="images/somersaults.jpeg" alt=""> Go to the gym with
    our somersaults class! Our teacher Jim takes you through the paces
    in this two-part article. <a href="articles/somersaults/1">Part
    1</a> ? <a href="articles/somersaults/1">Part 2</a></p>
    <a href="articles/kindplus/1"><p><img src="images/kindplus.jpeg"> 	
    Tired of walking on the edge of
    a clif<!-- sic -->? Our guest writer Lara shows you how to bumble
    your way through the bars.</p></a>
    <a href="articles/crisps/1"><p><img src="images/crisps.jpeg">
    The chips are down, now all that's left is a potato. What can you
    do with it?</p></a>
   </section>
   <ul>
    <li> <a href="/about">About us...</a>
    <li> <a href="/feedback">Send feedback!</a>
    <li> <a href="/sitemap">Sitemap</a>
   </ul>
  </nav>
  <footer>
   <p><small>Copyright ? 2015 The Snacker ?
   <a href="/tos">Terms of Service</a></small></p>
  </footer>
</body>

From philipj at opera.com  Tue Jul 12 07:17:17 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Tue, 12 Jul 2011 16:17:17 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <1310456478.2308.7.camel@shuttle>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<1310456478.2308.7.camel@shuttle>
Message-ID: <op.vyifa3fnsr6mfa@kirk>

On Tue, 12 Jul 2011 09:41:18 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Thu, 2011-07-07 at 22:33 +0000, Ian Hickson wrote:
>> The JSON algorithm now ends the crawl when it hits a loop, and replaces
>> the offending duplicate item with the string "ERROR".
>>
>> The RDF algorithm preserves the loops, since doing so is possible with
>> RDF. Turns out the algorithm almost did this already, looks like it was  
>> an
>> oversight.
>
> It seems to me that this approach creates an incentive for people who
> want to do RDFesque things to publish deliberately non-conforming
> microdata content that works the way they want for RDF-based consumers
> but breaks for non-RDF consumers. If such content abounds and non-RDF
> consumers are forced to support loopiness but extending the JSON
> conversion algorithm in ad hoc ways, part of the benefit of microdata
> over RDFa (treeness) is destroyed and the benefit of being well-defined
> would be destroyed, too, for non-RDF consumption cases.

I don't have a strong opinion, but note that even before this change the  
algorithm produced a non-tree for the "Avenue Q" example [1] where the  
"adr" property is shared between two items using itemref. (In JSON, it is  
flattened.) If we want to ensure that RDF consumers don't depend on  
non-treeness, then this should change as well.

[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#examples-4

-- 
Philip J?genstedt
Core Developer
Opera Software

From bzbarsky at MIT.EDU  Tue Jul 12 08:38:22 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 12 Jul 2011 11:38:22 -0400
Subject: [whatwg] Should events be paused on detached iframes?
In-Reply-To: <Pine.LNX.4.64.1106132358030.19153@ps20323.dreamhostps.com>
References: <4C742BCB.1020006@cs.washington.edu>	<AANLkTimprzp=A3nyEEmV4=nQnHZdZPanA0nDyPYOJxfw@mail.gmail.com>	<4C77907E.50609@helsinki.fi>	<Pine.LNX.4.64.1012012104380.26618@ps20323.dreamhostps.com>	<4CFD8529.6000200@mit.edu>	<Pine.LNX.4.64.1103050005090.26730@ps20323.dreamhostps.com>	<4D71968F.4080104@mit.edu>
	<Pine.LNX.4.64.1106132358030.19153@ps20323.dreamhostps.com>
Message-ID: <4E1C6A6E.2050303@mit.edu>

On 6/13/11 8:09 PM, Ian Hickson wrote:
>> It's possible to switch these relevant checks to walk the ownerDocument
>> chain instead, say.  Then we need to audit all the callsites to make
>> sure this makes sense at them and figure out what to do for the ones
>> where it doesn't.  (For example, should window.alert on the window of an
>> iframe not in the DOM put up a dialog in a tab based on the
>> ownerDocument of the iframe?  Or not put one up at all?)
>
> It should put it up in the context of the top-level browsing context of
> the script that led to that point (the "first script"). This is the same
> as if someone in one tab calls another tab's script and that script calls
> alert().

Is that last what browsers actually do?  I'm pretty sure that's not what 
Gecko does...

> Note that only direct script invokations would work here. setTimeout,
> events, XHR callbacks, etc, don't run while the document is not active. (I
> had previously set that dispatchEvent() would work, but this is incorrect
> per the spec at the moment. My apologies.)

OK.

>> There are quite a few APIs that need to be thus audited if this
>> invariant is changed.
>
> Are there any I should look for off-hand?

You listed some above.

There are also issues in terms of network loads that are live when an 
iframe is removed from its document, whether network loads can _start_ 
in such a removed iframe, what the styling behavior, if any, is (e.g. 
how should media query matching work?), layout behavior, if any (what's 
the initial containing block size?).  What should happen if click() is 
called on anchors?  Or is that covered by the events thing above?

Basically, pretty much every single aspect of the platform's behavior 
needs to be sanity-checked in this context...

>> There are, yes.  There are also lots of edge cases that are otherwise
>> impossible that are introduced by allowing it; I'm a little curious as
>> to how compatible with each other the IE8 and Chrome implementations
>> are.
>
> I agree that this is an area that might well be minimally interoperable at
> the moment. That, of course, is the main reason to specify it. :-)

That's fine, but it seems like a v2 kind of feature to me.

I'm also a little saddened that there has been absolutely no feedback so 
far from the people who've been implementing this, even in cases when 
the current spec doesn't really cover behavior....  We're not going to 
get to interop that way.

-Boris


From ian at hixie.ch  Tue Jul 12 11:54:23 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Jul 2011 18:54:23 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <1310456478.2308.7.camel@shuttle>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<1310456478.2308.7.camel@shuttle>
Message-ID: <Pine.LNX.4.64.1107121850000.3775@ps20323.dreamhostps.com>

On Tue, 12 Jul 2011, Henri Sivonen wrote:
> On Thu, 2011-07-07 at 22:33 +0000, Ian Hickson wrote:
> > The JSON algorithm now ends the crawl when it hits a loop, and 
> > replaces the offending duplicate item with the string "ERROR".
> > 
> > The RDF algorithm preserves the loops, since doing so is possible with 
> > RDF. Turns out the algorithm almost did this already, looks like it 
> > was an oversight.
> 
> It seems to me that this approach creates an incentive for people who 
> want to do RDFesque things to publish deliberately non-conforming 
> microdata content that works the way they want for RDF-based consumers 
> but breaks for non-RDF consumers. If such content abounds and non-RDF 
> consumers are forced to support loopiness but extending the JSON 
> conversion algorithm in ad hoc ways, part of the benefit of microdata 
> over RDFa (treeness) is destroyed and the benefit of being well-defined 
> would be destroyed, too, for non-RDF consumption cases.

The "problem" here is that RDF and microdata have different data models, 
and RDF cannot represent microdata's data model with fidelity.

For example, consider how this converts to RDF and compare it to the 
microdata equivalent:

   <div itemscope itemtype="http://example.com/" itemid="http://example.com/1">
    <span itemprop=a>x</span>
   </div>
   <div itemscope itemtype="http://example.com/" itemid="http://example.com/1">
    <span itemprop=b>x</span>
   </div>

There are other things RDF can't represent easily, e.g. it cannot easily 
represent the order of the values in this item:

   <div itemscope itemtype="http://example.com/">
    <span itemprop=a>1</span>
    <span itemprop=a>2</span>
   </div>

As such, I suggest we not worry about the itemref="" loop case, or that we 
try to fix all these cases together (not sure how we'd fix them).

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

From acolwell at google.com  Tue Jul 12 13:45:48 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 13:45:48 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
Message-ID: <CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>

On Mon, Jul 11, 2011 at 5:54 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> It seems to me that the spec is written assuming only one media element is
> consuming the MediaSource. But nothing stops multiple elements consuming the
> same URL simultaneously. Maybe instead of going through a URL you should add
> API directly to media elements.
>

You are right that I don't have anything preventing the MediaSource URL from
being passed to multiple media elements. Only one media element will accept
the URL though because whichever one opens the URL first will transition the
source to the OPEN state. Media elements can only open sources in the CLOSED
state. I'm using a URL for initialization to be consistent with how the
media element is initialized in all other cases. I didn't want to create a
new initialization path.

I thought about adding an attribute to HTMLMediaElement that provided a URL
for signalling MediaSource usage. That mechanism would allow you to create a
URL that only works with that element. When this URL is specified, a
MediaSource attribute would be updated on the media element during loading
and JavaScript could use that to pass data to the tag. I couldn't find a
similar pattern in other APIs so I didn't take that path. If people think
that is a better route then I'm all for it.



> bytesAvailable is for flow control? Instead of doing it this way, I would
> follow WebSockets and use a bufferedAmount attribute to indicate how much
> data is currently buffered up. That makes it easy for authors who don't want
> to care about flow control to just append stuff without encountering errors,
> while still allowing authors who care about flow control to do it.
>
>
Yes. The intent was to provide a way for the browser to control how much
data was being pushed into it. It looks like WebSocket will just close the
connection if it doesn't have enough buffer space and the API doesn't appear
to provide a mechanism to predict how much buffered data will trigger a
close. Do we want similar semantics for media? It seems like the browser
should provide some hints to indicate that it is not ok to push hours/days
of data into this interface.

Thanks for your comments.

Aaron

From acolwell at google.com  Tue Jul 12 13:52:05 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 13:52:05 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <4E1BF864.5000904@alvestrand.no>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<4E1BF864.5000904@alvestrand.no>
Message-ID: <CAA0c1bACv1OM7exvFJs1qSHdu8uKBUp2GGo9TgpUTM9dR+YVfQ@mail.gmail.com>

Hi Harald,

Please point me to specific threads that talk about this. I looked through
the public-webrtc at w3.org archive and didn't see anything about interactive
media handling. I did look through the Mozilla/Cisco proposal
thread<http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html>
and
didn't see anything in my proposal that is incompatible with what is being
proposed there.

Aaron

On Tue, Jul 12, 2011 at 12:31 AM, Harald Alvestrand <harald at alvestrand.no>wrote:

> Not a comment directly on the spec, but you might want to check what people
> are suggesting for interactive media handling in the WEBRTC working group.
>
> Streaming is different from interactive media, but it would be a shame to
> have incompatibilities that can be avoided.
>
>
>

From robert at ocallahan.org  Tue Jul 12 15:28:45 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 10:28:45 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
Message-ID: <CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>

On Wed, Jul 13, 2011 at 8:45 AM, Aaron Colwell <acolwell at google.com> wrote:

> I thought about adding an attribute to HTMLMediaElement that provided a URL
> for signalling MediaSource usage. That mechanism would allow you to create a
> URL that only works with that element. When this URL is specified, a
> MediaSource attribute would be updated on the media element during loading
> and JavaScript could use that to pass data to the tag. I couldn't find a
> similar pattern in other APIs so I didn't take that path. If people think
> that is a better route then I'm all for it.
>

I was thinking more of putting the MediaSource functionality
(open/append/close) on the media element itself.

Do you need to support seeking in with this API? That's hard. It would be
simpler if we didn't have to support seeking. Instead of seeking you could
just open a new stream and pour data in for the new offset.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From karld at opera.com  Tue Jul 12 15:37:06 2011
From: karld at opera.com (Karl Dubost)
Date: Tue, 12 Jul 2011 18:37:06 -0400
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
Message-ID: <2E11AA3A-57A5-4388-B896-394DAF910F89@opera.com>


Le 29 juin 2011 ? 05:27, Felix Halim a ?crit :
> Suppose the content of the main page change very often (like news site).
> In this case, you don't want to cache the main page since the users
> want to see the latest main page, not the cached ones when they open
> the main page later.

Did you also check ESI?
http://www.w3.org/TR/esi-lang

For example in 
http://symfony.com/doc/2.0/book/http_cache.html#edge-side-includes

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From acolwell at google.com  Tue Jul 12 16:14:27 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 16:14:27 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
Message-ID: <CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>

On Tue, Jul 12, 2011 at 3:28 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 8:45 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> I thought about adding an attribute to HTMLMediaElement that provided a
>> URL for signalling MediaSource usage. That mechanism would allow you to
>> create a URL that only works with that element. When this URL is specified,
>> a MediaSource attribute would be updated on the media element during loading
>> and JavaScript could use that to pass data to the tag. I couldn't find a
>> similar pattern in other APIs so I didn't take that path. If people think
>> that is a better route then I'm all for it.
>>
>
> I was thinking more of putting the MediaSource functionality
> (open/append/close) on the media element itself.
>

I'm open to that. In fact that is how my current prototype is implemented
because it was the least painful way to test these ideas in WebKit. My
prototype only implements append() and uses existing media element events as
proxies for the events I've proposed. I only separated this out into a
separate object because I thought people might prefer an object to represent
the source of the media and leave the media element object an endpoint for
controlling media playback.


>
> Do you need to support seeking in with this API? That's hard. It would be
> simpler if we didn't have to support seeking. Instead of seeking you could
> just open a new stream and pour data in for the new offset.
>

 I'd like to be able to support seeking so you can use this mechanism for
on-demand playback. In my prototype seeking wasn't too difficult to
implement. I just triggered it off the seeking event. Any append() that
happens after the seeking event fires is associated with the new seek
location. currentTime is updated with the timestamp in the first cluster
passed to append() after the seeking event fires. Once the media engine has
this timestamp and enough preroll data, then it will fire the seeked event
like normal. I haven't tested this with rapid fire seeking yet, but I think
this mechanism should work.

Aaron

From robert at ocallahan.org  Tue Jul 12 16:17:09 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 11:17:09 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
Message-ID: <CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>

On Wed, Jul 13, 2011 at 11:14 AM, Aaron Colwell <acolwell at google.com> wrote:

>
> I'm open to that. In fact that is how my current prototype is implemented
> because it was the least painful way to test these ideas in WebKit. My
> prototype only implements append() and uses existing media element events as
> proxies for the events I've proposed. I only separated this out into a
> separate object because I thought people might prefer an object to represent
> the source of the media and leave the media element object an endpoint for
> controlling media playback.
>

We're kinda stuck with media elements handling both playback endpoints and
resource loading.


>
>> Do you need to support seeking in with this API? That's hard. It would be
>> simpler if we didn't have to support seeking. Instead of seeking you could
>> just open a new stream and pour data in for the new offset.
>>
>
>  I'd like to be able to support seeking so you can use this mechanism for
> on-demand playback. In my prototype seeking wasn't too difficult to
> implement. I just triggered it off the seeking event. Any append() that
> happens after the seeking event fires is associated with the new seek
> location. currentTime is updated with the timestamp in the first cluster
> passed to append() after the seeking event fires. Once the media engine has
> this timestamp and enough preroll data, then it will fire the seeked event
> like normal. I haven't tested this with rapid fire seeking yet, but I think
> this mechanism should work.
>

How do you communicate the data offset that the element wants to read at
over to the script that provides the data? In general you can't know the
strategy the decoder/demuxer uses for seeking, so you don't know what data
it will request.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From acolwell at google.com  Tue Jul 12 16:30:28 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 16:30:28 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
Message-ID: <CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>

On Tue, Jul 12, 2011 at 4:17 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 11:14 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>>
>> I'm open to that. In fact that is how my current prototype is implemented
>> because it was the least painful way to test these ideas in WebKit. My
>> prototype only implements append() and uses existing media element events as
>> proxies for the events I've proposed. I only separated this out into a
>> separate object because I thought people might prefer an object to represent
>> the source of the media and leave the media element object an endpoint for
>> controlling media playback.
>>
>
> We're kinda stuck with media elements handling both playback endpoints and
> resource loading.
>

Ok.  This makes implementation in WebKit easier for me so I won't push to
hard to keep it separate from the media element. :)


>
>
>>
>>> Do you need to support seeking in with this API? That's hard. It would be
>>> simpler if we didn't have to support seeking. Instead of seeking you could
>>> just open a new stream and pour data in for the new offset.
>>>
>>
>>  I'd like to be able to support seeking so you can use this mechanism for
>> on-demand playback. In my prototype seeking wasn't too difficult to
>> implement. I just triggered it off the seeking event. Any append() that
>> happens after the seeking event fires is associated with the new seek
>> location. currentTime is updated with the timestamp in the first cluster
>> passed to append() after the seeking event fires. Once the media engine has
>> this timestamp and enough preroll data, then it will fire the seeked event
>> like normal. I haven't tested this with rapid fire seeking yet, but I think
>> this mechanism should work.
>>
>
> How do you communicate the data offset that the element wants to read at
> over to the script that provides the data? In general you can't know the
> strategy the decoder/demuxer uses for seeking, so you don't know what data
> it will request.
>

I'm doing WebM demuxing and media fetching in JavaScript. When a seek
occurs, I look at currentTime to see where we are seeking to. I then look at
the CUES index data I've fetched to find the file offset for the closest
seek point to the desired time. The appropriate data is fetched and pushed
into the element via append(). The seeked event firing and readyState
transitioning to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA tells me when I've
sent the element enough data. During playback I just monitor the buffered
attribute to keep a specific duration ahead of the current playback time.

Aaron

From robert at ocallahan.org  Tue Jul 12 16:44:31 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 11:44:31 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
Message-ID: <CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>

On Wed, Jul 13, 2011 at 11:30 AM, Aaron Colwell <acolwell at google.com> wrote:

> I'm doing WebM demuxing and media fetching in JavaScript. When a seek
> occurs, I look at currentTime to see where we are seeking to. I then look at
> the CUES index data I've fetched to find the file offset for the closest
> seek point to the desired time. The appropriate data is fetched and pushed
> into the element via append(). The seeked event firing and readyState
> transitioning to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA tells me when I've
> sent the element enough data. During playback I just monitor the buffered
> attribute to keep a specific duration ahead of the current playback time.


Now I'm rather confused about what you're doing and how you're using this
feature. What format is the data that you're feeding into the element?

I had imagined that this API would let the author feed in the same data as
you would load from some URI. But that can't be what's happening, since in
some element implementations (e.g., Gecko's) loaded data is buffered
internally and seeking might not require any new data to be loaded.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From acolwell at google.com  Tue Jul 12 17:00:58 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 17:00:58 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
Message-ID: <CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>

On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 11:30 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> I'm doing WebM demuxing and media fetching in JavaScript. When a seek
>> occurs, I look at currentTime to see where we are seeking to. I then look at
>> the CUES index data I've fetched to find the file offset for the closest
>> seek point to the desired time. The appropriate data is fetched and pushed
>> into the element via append(). The seeked event firing and readyState
>> transitioning to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA tells me when I've
>> sent the element enough data. During playback I just monitor the buffered
>> attribute to keep a specific duration ahead of the current playback time.
>
>
> Now I'm rather confused about what you're doing and how you're using this
> feature. What format is the data that you're feeding into the element?
>

Sorry I wasn't clear about my intent. Currently I'm feeding it WebM. I could
see this expanding to Ogg and perhaps MP4. Theoretically any format that
looks like a packet stream could work.


>
> I had imagined that this API would let the author feed in the same data as
> you would load from some URI. But that can't be what's happening, since in
> some element implementations (e.g., Gecko's) loaded data is buffered
> internally and seeking might not require any new data to be loaded.
>
>
 No. The idea is to allow JavaScript to manage fetching the media data so
various fetching strategies could be implemented without needing to change
the browser. My initial motivation is for supporting adaptive streaming with
this mechanism, but I think various media mashup and delivery scenarios
could be explored with this.

Aaron

From robert at ocallahan.org  Tue Jul 12 17:05:22 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 12:05:22 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
Message-ID: <CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>

On Wed, Jul 13, 2011 at 12:00 PM, Aaron Colwell <acolwell at google.com> wrote:

> On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> I had imagined that this API would let the author feed in the same data as
>> you would load from some URI. But that can't be what's happening, since in
>> some element implementations (e.g., Gecko's) loaded data is buffered
>> internally and seeking might not require any new data to be loaded.
>>
>>
>  No. The idea is to allow JavaScript to manage fetching the media data so
> various fetching strategies could be implemented without needing to change
> the browser. My initial motivation is for supporting adaptive streaming with
> this mechanism, but I think various media mashup and delivery scenarios
> could be explored with this.
>

I don't think you can do that with this API without making huge assumptions
about what the browser's demuxer, internal caching, etc are doing.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From acolwell at google.com  Wed Jul 13 09:35:58 2011
From: acolwell at google.com (Aaron Colwell)
Date: Wed, 13 Jul 2011 09:35:58 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
	<CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
Message-ID: <CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>

On Tue, Jul 12, 2011 at 5:05 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 12:00 PM, Aaron Colwell <acolwell at google.com>wrote:
>
>> On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> I had imagined that this API would let the author feed in the same data
>>> as you would load from some URI. But that can't be what's happening, since
>>> in some element implementations (e.g., Gecko's) loaded data is buffered
>>> internally and seeking might not require any new data to be loaded.
>>>
>>>
>>  No. The idea is to allow JavaScript to manage fetching the media data so
>> various fetching strategies could be implemented without needing to change
>> the browser. My initial motivation is for supporting adaptive streaming with
>> this mechanism, but I think various media mashup and delivery scenarios
>> could be explored with this.
>>
>
> I don't think you can do that with this API without making huge assumptions
> about what the browser's demuxer, internal caching, etc are doing.
>
>
I am open to suggestions. My intent was that the browser would not attempt
to cache any data passed into append(). It would just demux the buffers that
are sent in. When a seek is requested, it flushes whatever it has and waits
for more data from append().  If the web application wants to do caching it
can use the WebStorage or File APIs. If the browser's media engine needs a
certain amount of "preroll" data before it starts playback it can signal
this explicitly through new attributes or just use HAVE_FUTURE_DATA
& HAVE_ENOUGH_DATA readyStates to signal when it has enough.

Aaron

From johnmrrichards at gmail.com  Wed Jul 13 12:53:23 2011
From: johnmrrichards at gmail.com (John Richards)
Date: Wed, 13 Jul 2011 12:53:23 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
Message-ID: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

Are there plans to have an 'allow-plugins' value?

I'm assuming there will be use-cases where the only protection that is
desired is prevention of parent redirection.

Thanks

From w3c at adambarth.com  Wed Jul 13 13:31:19 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 13 Jul 2011 13:31:19 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
Message-ID: <CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>

Adding allow-plugins today would defeat the prevention of parent redirection.

The short answer is we need an API for informing plugins of the
sandbox flags and a way of confirming that the plugins understand
those bits before we can allow plugins inside sandboxed frames.

Adam


On Wed, Jul 13, 2011 at 12:53 PM, John Richards
<johnmrrichards at gmail.com> wrote:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
>
> Are there plans to have an 'allow-plugins' value?
>
> I'm assuming there will be use-cases where the only protection that is
> desired is prevention of parent redirection.
>
> Thanks
>

From julian.reschke at gmx.de  Wed Jul 13 13:55:48 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 13 Jul 2011 22:55:48 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
Message-ID: <4E1E0654.9070206@gmx.de>

On 2011-07-13 22:31, Adam Barth wrote:
> Adding allow-plugins today would defeat the prevention of parent redirection.
>
> The short answer is we need an API for informing plugins of the
> sandbox flags and a way of confirming that the plugins understand
> those bits before we can allow plugins inside sandboxed frames.

...but that API is outside the scope of what the W3C and the WhatWG 
currently do, so I think it would be great if defining this flag could 
be decoupled from progress on the plugin API layers.

Best regards, Julian

From w3c at adambarth.com  Wed Jul 13 13:58:49 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 13 Jul 2011 13:58:49 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <4E1E0654.9070206@gmx.de>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
Message-ID: <CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>

On Wed, Jul 13, 2011 at 1:55 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2011-07-13 22:31, Adam Barth wrote:
>> Adding allow-plugins today would defeat the prevention of parent
>> redirection.
>>
>> The short answer is we need an API for informing plugins of the
>> sandbox flags and a way of confirming that the plugins understand
>> those bits before we can allow plugins inside sandboxed frames.
>
> ...but that API is outside the scope of what the W3C and the WhatWG
> currently do, so I think it would be great if defining this flag could be
> decoupled from progress on the plugin API layers.

It is coupled in the sense that we can't implement the flag unless and
until such a plug-in API exists.

Adam

From julian.reschke at gmx.de  Wed Jul 13 14:13:05 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 13 Jul 2011 23:13:05 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
Message-ID: <4E1E0A61.5070205@gmx.de>

On 2011-07-13 22:58, Adam Barth wrote:
> On Wed, Jul 13, 2011 at 1:55 PM, Julian Reschke<julian.reschke at gmx.de>  wrote:
>> On 2011-07-13 22:31, Adam Barth wrote:
>>> Adding allow-plugins today would defeat the prevention of parent
>>> redirection.
>>>
>>> The short answer is we need an API for informing plugins of the
>>> sandbox flags and a way of confirming that the plugins understand
>>> those bits before we can allow plugins inside sandboxed frames.
>>
>> ...but that API is outside the scope of what the W3C and the WhatWG
>> currently do, so I think it would be great if defining this flag could be
>> decoupled from progress on the plugin API layers.
>
> It is coupled in the sense that we can't implement the flag unless and
> until such a plug-in API exists.

Yes, but we can *define* the flag in HTML and write down what it means 
with respect to plugin APIs.

Best regards, Julian

From ian at hixie.ch  Wed Jul 13 15:39:40 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Jul 2011 22:39:40 +0000 (UTC)
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <1309931809.4058.148699.camel@robslapu>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com> 
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com> 
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com> 
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
Message-ID: <Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>


In response to off-list feedback, I've renamed StreamTrack to 
MediaStreamTrack to be clearer about its relationship to the other 
interfaces.


On Wed, 1 Jun 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> 
> We are having a bit of discussion regarding the correct behaviour when 
> mandatory arguments are undefined, see this webkit bug for history: 
> https://bugs.webkit.org/show_bug.cgi?id=60622
> 
> Could we have some clarification for the below cases, please: [...]

Hopefully Aryeh and Cameron have sufficiently clarified this; please let 
me know if not.


On Wed, 8 Jun 2011, Per-Erik Brodin wrote:
> 
> The TrackList feature seems to be a good way to control the different 
> components of a Stream. Although it is said that tracks provide a way to 
> temporarily disable a local camera, due to the nature of the 
> ExclusiveTrackList it is still not possible to disable video altogether, 
> i.e. to 'pull down the curtain' in a video conference. I noticed that 
> there is a bug filed on this issue but I do not think the proposed 
> solution there is quite right. There is a state in which no tracks are 
> selected in an ExclusiveTrackList, when the selected index returned is 
> -1. A quick fix would be to allow also setting the active track to -1 in 
> order to deselect all the other tracks.

This is fixed now, hopefully. Let me know if the fix is not sufficient.

(I replaces the videoTracks and audioTracks lists with a single tracks 
list in which you can enable and disable individual tracks.)


> I think a note would be appropriate that although the label on a 
> GeneratedStream is guaranteed to be unique for the conceptual stream, 
> there are situations where one ends up with multiple Stream objects with 
> the same label. For example, if the remote peer adds a stream, then 
> removes it, then adds the same stream again, you would end up with two 
> Stream objects with the same label if a reference to the removed Stream 
> is kept. Also, if the remote peer takes a stream that it receives and 
> sends it back you will end up with a Stream object that has the same 
> label as a local GeneratedStream object.

Done.


> We prefer having a StreamRecorder that you have to stop in order get the
> recorded data (like the previous one, but with asynchronous Blob retrieval)
> and we do not understand the use cases for the current proposal where
> recording continues until the recorder is garbage collected (or the Stream
> ends) and you always get the data from the beginning of the recording. This
> also has to be tied to application quota in some way.

The current design is just the result of needing to define what happens 
when you call getRecordedData() twice in a row. Could you elaborate on 
what API you think we should have?


> The recording example does not seem correct either, it never calls 
> record() and then it calls getRecordedData() directly on the 
> GeneratedStream object.

Fixed.


> Instead of blob: we would like to use stream: for the Stream URLs so 
> that we very early on in the media engine selection can use the protocol 
> scheme to determine how the URL will be handled. Blobs are typically 
> handled in the same way as other media playback. The definition of 
> stream: could be the same as for blob:.

Why can't the UA know which blob: URLs point to streams and which point to 
blobs?


> In addStream(), the readyState of the Stream is not checked to see if it is
> ENDED, in which case adding a stream should fail (perhaps throwing a TypeError
> exception like when passing null).

The problem is that if we do that there'd be a race condition: what 
happens if the stream is ended between the time the script tests whether 
the stream is ended or not and the time the stream is passed to the 
object? I would rather that not be unreliable.

Actually, the spec doesn't currently say anything happens when a stream 
that is being transmitted just ends, either. I guess I should spec that...

...ok, now the spec is clear that an ended stream transmits blackness and 
silence. Same with if some tracks are disabled. (Blackness only if there's 
a video track; silence only if there's an audio track.)


> When a received Stream is removed its readyState is not set to ENDED 
> (and no 'ended' event is dispatched).

I've clarified this so that it is clear that the state change and event do 
happen.


> PeerConnection is an EventTarget but it still uses a callback for the 
> signaling messages and this mixture of events and callbacks is a bit 
> awkward in my opinion. If you would like to change the function that 
> handles signaling messages after calling the constructor you would have 
> to wrap a function call inside the callback to the actual signal 
> handling function, instead of just (re-)setting an onsignal (or 
> whatever) attribute listener (the event could reuse the MessageEvent 
> interface).

When would you change the callback?

My concern with making the callback an event handler is that it leads to a 
set of poor failure modes and complications in the API:

 - It's easy to not register a callback, which makes no sense. There's 
   literally never a use for create a PeerConnection without a signaling 
   channel, as far as I can tell, so making it easier to create one 
   without a callback than with seems like a bad design.

 - It's easy to register multiple callbacks. This equally makes no sense, 
   and would likely only ever be the source of bugs.

 - It makes getting the data more complicated. Instead of passing the 
   callback the string to send, we end up passing an object which has on 
   it one attribute that contains the string.


> Perhaps signalingMessage() could be renamed to 
> add/handle/process/SignalingMessage() or similar to better indicate that 
> it is used to input signaling messages received from the other peer.

processSignalingMessage() works, I guess. I'm not a huge fan of overly 
long names, but Anant suggested making it clearer too, so ok. Done.


> There is a potential problem in the exchange of SDPs in that glare 
> conditions can occur if both peers add streams simultaneously, in which 
> case there will be two different outstanding offers that none of the 
> peers are allowed to respond to according to the SDP offer-answer model. 
> Instead of using one SDP session for all media as the specification 
> suggests, we are handling the offer-answer for each stream separately to 
> avoid such conditions.

Why isn't this handled by the ICE role conflict processing rules? It seems 
like simultaneous ICE restarts would be trivially resolvable by just 
following the rules in the ICE spec. Am I missing something?


On Mon, 13 Jun 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
>
> as WebIDL has been extended with a "is nullable operator" ( 
> http://www.w3.org/TR/WebIDL/#idl-nullable-type) I wonder if the 
> MediaStreams draft can make use of it, please?
> 
> Especially navigator.getUserMedia(options, successCallback [, 
> errorCallback ] ) and PeerConnection(configuration, signalingCallback).

This is done now (thanks to heycam).


On Tue, 14 Jun 2011, Per-Erik Brodin wrote:
> 
> Maybe the null-check in step 3 under "When the PeerConnection() 
> constructor is invoked .." should not be there anymore since 
> signalingCallback is not nullable.

Fixed.


On Wed, 22 Jun 2011, Arun Ranganathan wrote:
> > 
> > Summing up, the problem with the current implementation of Blobs is 
> > that once a URI has been generated for them, by design changes are no 
> > longer reflected in the object URL. In a streaming scenario, this is 
> > not what is needed, rather a long-living Blob that can be appended is 
> > needed and 'streamed' to other parts of the browser, e.g. the<video> 
> > or<audio> element.
> >
> > The original use case was:  make an application which will download 
> > media files from a server and cache them locally, as well as playing 
> > them without making the user wait for the entire file to be 
> > downloaded, converted to a blob, then saved and played, however such 
> > an API covers many other use cases such as on-the-fly on-device 
> > decryption of streamed media content (ie live streams either without 
> > end or static large files that to download completely would be a waste 
> > when only the first couple of seconds need to be buffered and 
> > decrypted before playback can begin)
> > 
> > Some suggestions were to modify or create a new type of Blob, the 
> > StreamingBlob which can be changed without its object url changing and 
> > appended to as new data is downloaded or decoded, and using a similar 
> > process to how large files may start to be decoded/played by a browser 
> > before they are fully downloaded. Other suggestions suggested using a 
> > pull API on the Blob so browsers can request for new data 
> > asynchronously, such as in 
> > <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029998.html>
> > 
> > Some problems however that a browser may face is what to do with urls 
> > which are opened twice, and whether the object url should start from 
> > the beginning (which would be needed for decoding encrypted, on-demand 
> > audio) or start from the end (similar to `tail`, for live streaming 
> > events that need decryption, etc.).

I haven't added support for this in the spec, but based on feedback from 
roc recently I renamed Stream to MediaStream to allow Stream to be used 
for precisely the purpose you describe. That would be something to add to 
the File API spec(s), though.


> I actually think moving to a streaming mode for file reads in general is 
> desirable, but I'm not entirely sure extending Blobs is the way to go 
> for *that* use case, which honestly is the main use case I'm interested 
> in.  We may improve upon ideas after this API goes to Last Call for 
> streaming file reads; hopefully we'll do a better job than other 
> non-JavaScript APIs out there :) [1].  Blob objects as they are 
> currently specified live "in memory" and represent "in memory" File 
> objects as well.  A change to the underlying file isn't captured in the 
> Blob snapshot; moreover, if the file moves or is no longer present at 
> time of read, an error event is fired while processing a read operation.  
> The object URL may be dereferenced, but will result in a 404.

Makes sense.


> The Streaming API explored by WHATWG uses the Object URL scheme for 
> videoconferencing use cases [2], and so the scheme itself is suitable 
> for "resources" that are more dynamic than memory-resident Blob objects. 
> Segment-plays/segment dereferencing in general can be handled through 
> media fragments; the scheme can naturally be accompanied by fragment 
> identifiers.

Indeed.


On Thu, 30 Jun 2011, Aaron Colwell wrote:
> 
> I've been working on an adaptive streaming prototype that uses 
> JavaScript to fetch chunks of media and feeds them to the video tag for 
> decoding. The idea is to let the adaptation algorithm and CDN 
> interactions happen in JavaScript so that they can evolve without the 
> need for browser changes. I'm looking for some guidance about the 
> preferred method for adding this type of functionality. I'm new to this 
> process so please bear with me.

Currently this isn't supported.

Can you elaborate on why you'd rather do this by hand instead of using the 
browsers' streaming features?


> I've also been looking at the WebRTC MediaStream API and was wondering 
> if it makes more sense to create an object similar to the 
> LocalMediaStream object. This has the benefits of unifying how media 
> streams are handled independent of whether they come from a camera or a 
> JavaScript based streaming algorithm. This could also enable sending the 
> media stream through a Peer-to-peer connection instead of only allowing 
> a camera as a source. Here is an example of the type of object I'm 
> talking about.
> 
> interface GeneratedMediaStream : MediaStream {
>   void init(in DOMString type, in UInt8Array init_data);
>   void appendData(in DOMString trackId, in UInt8Array data);
>   void endOfStream();
> 
>   readonly attribute MultipleTrackList audioTracks;
>   readonly attribute ExclusiveTrackList videoTracks;
> };

I imagine we'll support something like this eventually, probably by having 
a new interface for author-generated streams, probably something like what 
roc suggests below, but we should probably get basic video and P2P streams 
working before adding something like this.


On Fri, 1 Jul 2011, Robert O'Callahan wrote:
> 
> I think MediaStreams should not be dealing with compressed data except as an
> optimization when access to decoded data is not required anywhere in the
> stream pipeline.

Indeed.


> If you want to do processing of decoded stream data (which I do --- see 
> http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html), 
> then introducing a decoder inside the stream processing graph creates 
> all sorts of complications.

Right.


> I think the natural way to support the functionality you're looking for 
> is to extend the concept of Blob URLs. Right now you can create a binary 
> Blob, mint a URL for it and set that URL as the source for a media 
> element. The only extension you need is the ability to append data to 
> the Blob while retaining the same URL; you would need to initially mark 
> the Blob as "open" to indicate to URL consumers that the data stream has 
> not ended. That extension would be useful for all sorts of things 
> because you can use those Blob URLs anywhere. An alternative would be to 
> create a new kind of object representing an appendable sequence of Blobs 
> and create an API to mint URLs for it.

Right.


On Wed, 6 Jul 2011, Shwetank Dixit wrote:
> On Fri, 18 Mar 2011 19:32:49 +0530, Lachlan Hunt wrote:
> > On 2011-03-18 05:45, Ian Hickson wrote:
> > > On Thu, 16 Sep 2010, Jonathan Dixon wrote:
> > > > Further, it could be useful to provide a way to query the video 
> > > > source as to whether the camera is oriented relative to the screen 
> > > > (if the underlying system knows; consider a phone device with both 
> > > > a main camera and self-view camera). This is needed to drive the 
> > > > decision on whether to do this horizontal flip or not. In fact, 
> > > > such an application may want to somehow indicate a preference for 
> > > > the self-view camera when multiple cameras are present in the 
> > > > selection list. c.f. a movie-making app which would prefer the 
> > > > outward facing camera.
> > > 
> > > In getUserMedia() the input is extensible; we could definitely add 
> > > "prefer-user-view" or "prefer-environment-view" flags to the method 
> > > (with better names, hopefully, but consider that 'rear' and 'front' 
> > > are misleading terms -- the front camera on a DSLR faces outward 
> > > from the user, the front camera on a mobile phone faces toward the 
> > > user). The user still has to OK the use of the device, though, so 
> > > maybe it should just be left up to the user to pick the camera? 
> > > They'll need to be able to switch it on the fly, too, which again 
> > > argues to make this a UA feature.
> > 
> > We could just add flags to the options string like this:
> > 
> > "video;view=user, audio" or "video;view=environment, audio"
> > 
> > It's worth pointing out that The HTML Media Capture draft from the DAP 
> > WG uses the terms "camera" and "camcorder" for this purpose, but I 
> > find these terms to be very ambiguous and inappropriate, and so we 
> > should not use them here.
>
> Just wanted to know whether there is any consensus on this or not? 
> Mobile phones are coming out with dual cameras (front and back facing) 
> and depending on the use case, the developer might want access to either 
> the front or back one. (For example, for a simple camera app, a back 
> facing will do, but for a web conferencing app, the front facing will be 
> required). At least, the developer should be able to specify which one 
> to enable by default, which then can be changed the user if needed.

The spec currently uses "video user" and "video environment".


> Another question is flash. As far as I have seen, there seems to be no 
> option to specify whether the camera needs to use flash or not. Is this 
> decision left up to the device? (If someone is making an app which is 
> just clicking a picture of the person, then it would be nice to have the 
> camera use flash in low light conditions).

getUserMedia() returns a video stream, so it wouldn't use a flash.


On Wed, 6 Jul 2011, Rob Manson wrote:
>
> There are also tablet devices with stereo cameras on the back and single 
> on the front too.  Stereo will become increasingly common.

getUserMedia() is intended to support returning multiple video tracks for 
this kind of thing. A video track could also just be natively 3D.

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

From robert at ocallahan.org  Wed Jul 13 20:00:07 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Jul 2011 15:00:07 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
	<CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
	<CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>
Message-ID: <CAOp6jLYP8ks3cAnjahjBjfd9P_UxXOi_2OUJBjW439hcre87+Q@mail.gmail.com>

On Thu, Jul 14, 2011 at 4:35 AM, Aaron Colwell <acolwell at google.com> wrote:

> I am open to suggestions. My intent was that the browser would not attempt
> to cache any data passed into append(). It would just demux the buffers that
> are sent in. When a seek is requested, it flushes whatever it has and waits
> for more data from append().  If the web application wants to do caching it
> can use the WebStorage or File APIs. If the browser's media engine needs a
> certain amount of "preroll" data before it starts playback it can signal
> this explicitly through new attributes or just use HAVE_FUTURE_DATA
> & HAVE_ENOUGH_DATA readyStates to signal when it has enough.


OK, I sorta get the idea. I think you're defining a new interface to the
media processing pipeline that integrates with the demuxer and codecs at a
different level to regular media resource loading. (For example, all the
browser's built-in logic for seeking and buffering would have to be disabled
and/or bypassed.) As such, it would have to be carefully specified,
potentially in a container- or codec-dependent way, unlike APIs like Blobs
which work "just like" regular media resource loading and can thus work with
any container/codec.

I'm not sure what the best way to do this is, to be honest. It comes down to
the use-cases. If you want to experiment with different seeking strategies,
can't you just do that in Chrome itself? If you want scriptable adaptive
streaming (or even if you don't) then I think we want APIs for seamless
transitioning along a sequence of media resources, or between resources
loaded in parallel.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

From annevk at opera.com  Wed Jul 13 21:49:30 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 14 Jul 2011 06:49:30 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <4E1E0A61.5070205@gmx.de>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de>
Message-ID: <op.vylecs0564w2qv@annevk-macbookpro.local>

On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke <julian.reschke at gmx.de>  
wrote:
> Yes, but we can *define* the flag in HTML and write down what it means  
> with respect to plugin APIs.

It seems much better to wait until it can actually be implemented.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From jonas at sicking.cc  Wed Jul 13 23:22:48 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 13 Jul 2011 23:22:48 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <op.vylecs0564w2qv@annevk-macbookpro.local>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de> <op.vylecs0564w2qv@annevk-macbookpro.local>
Message-ID: <CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>

On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren <annevk at opera.com> wrote:
>
> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke <julian.reschke at gmx.de> wrote:
>>
>> Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs.
>
> It seems much better to wait until it can actually be implemented.

Especially since it's not at all clear to me that a specific opt-in
mechanism is at all needed once we have the appropriate plugin APIs
implemented. And those APIs are needed anyway if we want to allow
plugins in any form in the sandbox.

/ Jonas

From julian.reschke at gmx.de  Thu Jul 14 01:16:18 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 14 Jul 2011 10:16:18 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de>
	<op.vylecs0564w2qv@annevk-macbookpro.local>
	<CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
Message-ID: <4E1EA5D2.4060702@gmx.de>

On 2011-07-14 08:22, Jonas Sicking wrote:
> On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren<annevk at opera.com>  wrote:
>>
>> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke<julian.reschke at gmx.de>  wrote:
>>>
>>> Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs.
>>
>> It seems much better to wait until it can actually be implemented.
>
> Especially since it's not at all clear to me that a specific opt-in
> mechanism is at all needed once we have the appropriate plugin APIs
> implemented. And those APIs are needed anyway if we want to allow
> plugins in any form in the sandbox.

"When the attribute is set, the content is treated as being from a 
unique origin, forms and scripts are disabled, links are prevented from 
targeting other browsing contexts, and plugins are disabled."

A browser negotiating something with plugins using that API and enabling 
them despite @sandbox would violate the above requirement, no?

From shwetankd at opera.com  Thu Jul 14 01:33:36 2011
From: shwetankd at opera.com (Shwetank Dixit)
Date: Thu, 14 Jul 2011 14:03:36 +0530
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
Message-ID: <op.vylop7byim6vpa@shwetank-dixits-macbook.local>

On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:

>
>> Another question is flash. As far as I have seen, there seems to be no
>> option to specify whether the camera needs to use flash or not. Is this
>> decision left up to the device? (If someone is making an app which is
>> just clicking a picture of the person, then it would be nice to have the
>> camera use flash in low light conditions).
> getUserMedia() returns a video stream, so it wouldn't use a flash.

Wouldn't it make sense to have a provision for flash separately then? I  
think a lot of apps would like just a picture instead of video, and in  
those cases, flash would be required. Maybe a seperate provision in the  
spec which defines whether to use flash, and if so, for how many  
miliseconds. Is that doable?
-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/

From whatwg.org at boblet.net  Thu Jul 14 02:38:09 2011
From: whatwg.org at boblet.net (Oli Studholme)
Date: Thu, 14 Jul 2011 18:38:09 +0900
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1C2FFB.5060909@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<4E16EF63.8080709@gmail.com>
	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
	<4E1B3864.9050207@gmail.com>
	<CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>
	<4E1C2FFB.5060909@gmail.com>
Message-ID: <CAJpND8nWmviqW2g-vPpfijKEBnWqOvMkn9FGFBE4h9ri1DYw5w@mail.gmail.com>

Hi Bjartur,

On Tue, Jul 12, 2011 at 8:28 PM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> ?ann ?ri 12.j?l 2011 09:15, skrifa?i Oli Studholme:

> Datetimes will usually be presented in a localized format to humans.

I think at most user agents will offer users the option to localise
datetime attributes. I don?t think such localisation would be the
default. This is because even in one localisation there are multiple
ways to present dates, and automatically changing a short date form to
a long localised date form may break layout (which user agents avoid
wherever possible).

>> How would the user agent
>> know which way the author wants to present attribution?
>>
> By fetching and reading a linked stylesheet. I think it's easier to style
> attributes then text nodes polluted with delimiters such as "from" and "by"
> that make reordering hard.

This is an interesting idea. However I think this would be a large
increase in complexity (code & l10n) for user agents, and for little
gain. If the user agent was also translating the content then this
might be considered, but merely styling block quote attribution this
way would involve many options per language (depending on what
attributes were present and what data they displayed).

There are a *lot* of potential attributes just for citation.
http://microformats.org/wiki/citation lists 22. Even providing for all
of these will still exclude other potential block quote-related
information, such as notes, copyright etc

> More importantly, how is the author to know how the user wants attribution
> presented?

Heh. Generally users are happy with the author?s content as long as
they can read it. I think there?d be few people in the world that
would care enough to add user styles to change e.g. from a
bibliographic to an author-date system citation. For more than this
you may need to wait for the semantic web ;)

>> Again I have no idea how a user agent would follow these rules.
>> Arbitrarily showing one thing in one viewport size and something else
>> at a different size would be a bug (arbitrarily meaning without
>> author/user intervention, such as via CSS).
>
> A feature to one, a bug to another. The existence of the CSS height and
> width media features suggests that catering style to varying viewport sizes
> is desired by others than just me. I don't see why a user agent should seek
> an authors' permission to style a document for an unusually sized viewport,
> nor require users to write their own stylesheets instead of shipping
> customizable stylesheets.

However you?re advocating the user agent follow these rules without
author/user intervention. The reason that adaptive layout isn?t done
by default by user agents (with some notable exceptions in mobile) is
that it has the potential to break things, in such a way that neither
the author or user can fix.

> For a lack of a valid URI identifying myself, I used an unregistered
> uri-scheme ("kennitala") and my national ID as the scheme-specific part. The
> exact URI in question is unimportant to the example, but I see no reason to
> restrict values of cite to locators only, as opposed to identifiers in
> general. Quoting books identified by ISBN numbers seems like a good enough
> use case to me.

But what would a user agent do with an ISBN number? if there?s a URL
at least the user agent can theoretically present a link, like how the
cite attribute is supposed to work. I also just realised you used this
in your footer example for an href. This would present text styled as
a link that doesn?t respond to clicks, a usability problem.

>> This proves Jeremy's earlier point about attributes being a bad place
>> to store data. Unless you look at the source you?d never notice these
>> mistakes.
>>
> Sure I would, had I actually tried to, say, render them or validate before
> posting them on the Internet. I refrained from doing so as I knew this to be
> invalid markup, anyway. Where datetime to be a valid attribute of blockquote

You are assuming the rest of the internet?s authors are as
conscientious as you are :/ humans are very adept at making mistakes.
hidden data makes mistakes in this data far harder to identify and
correct

> No, that would be quite an odd rendering. More likely renderings:
>
> ?ann annan apr?l 1997 skrifa?i Bjartur Thorlacius:
>> Lorem ipsum
>
>
> On the second April, 1997 Bjartur Thorlacius wrote:
>> Lorem ipsum
>
> ? Lorem ipsum
> ? ? ? ?? Bjartur Thorlacius
>
> It all depends on the user's localized stylesheet.

this requires the user agent to localise the attributes before
displaying them. what about for languages which aren?t localised in
the user?s stylesheet?

>> There?s also the possibility of adding another inline element, such as
>> <credit>, which could let someone credit an author of a quote, or e.g.
>> to credit a photographer of an image together<figure> ?and
>> <figcaption>.
>>
> So <credit> would be an inline version of <footer>, to be contained in <q>?
> Would it not be more consistent to use attributes, in that case? Note that
> <figcaption> may contain <footer>s.

I?m not sure on the earlier discussion about <credit>, and actually
it?s only my assumption that it?d be inline. I?m not even sure if it
would contain all credited information (including perhaps copyright
data), or just the creator?s name. Hopefully someone will weigh in on
this?

>> While something like<a> ?and<cite> ?in a<footer> ?could work for
>> citation, I still don?t have a good idea about citing explicitly when
>> the citation is inline (on the last line of the block quote), or for
>> <q>.
>>
> I do: use the same attributes as for <blockquote>.
> Referencing people as works as I did in my examples is probably
> bad (read: terrible) style. There should be a sepearate @author attribute
> for attributing an author, distinct from the @cite attribute for citing the
> work.

what about for notes on a blockquote, such as ?emphasis mine?? you?d
need another attribute. what about for when you?d like to contain
HTML, such as ?<em>emphasis</em> mine?? attributes prevent this use
case.

> On a third thought, using a <footer> child of <blockquote> doesn't seem so
> confusing after all, but it'd be even less confusing to HTML newcomers were
> it named e.g. <credit>. But then it would not be an appropriate element for
> "fat footers", whatever they are. I don't see what citations and "fat
> footers" have in common.

in graphic design a footer contains supplementary information about
the content it follows. the spec initially disallowed ?fat footers?,
but the naming and common usage would have led to people using them
for fat footers regardless of the spec. they still contain
supplementary information about their sectioning element or sectioning
root. This semantic connection seems stronger to me than one based on
arbitrary size

peace - oli studholme

From karld at opera.com  Thu Jul 14 03:49:56 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 06:49:56 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
Message-ID: <CAE46406-D675-4428-B6B8-8511352AB696@opera.com>


Le 8 juil. 2011 ? 07:20, Jeremy Keith a ?crit :
> 1) Oli has shown the real-world use cases for attribution *within* blockquotes.

using that for years (almost every day), an example
http://www.la-grange.net/2011/06/05/fruit

<blockquote cite="urn:isbn:978-2-07-07533-7">
    <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
    <p>? <q>M?me si l'on vient me chercher<br/>
        Comment, abandonnant la ros?e<br/>
        De pareil lotus,<br/>
        Retournerai-je<br/>
        Dans le monde changeant et frivole ?</q> ?</p>
    <p>et j'envoyais ce p?tale.</p>
    <p class="source">
        <cite class="auteur">Shonagon, Sei</cite>, 
        <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
</blockquote>


mentioned here 
http://lists.w3.org/Archives/Public/www-html/2005Jun/0201

My favorite issue being when there is a mix of cite in the prose and blockquotes, there is no mechanism to associate the right cite with the right blockquote and this is happening often when you write about things referring to different sources.
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Dec/0016


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From jkorpela at cs.tut.fi  Thu Jul 14 04:09:06 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 14 Jul 2011 14:09:06 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
Message-ID: <4E1ECE52.7090506@cs.tut.fi>

14.07.2011 13:49, Karl Dubost wrote:

> using that for years (almost every day), an example
> http://www.la-grange.net/2011/06/05/fruit
>
> <blockquote cite="urn:isbn:978-2-07-07533-7">
>      <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
>      <p>?<q>M?me si l'on vient me chercher<br/>
>          Comment, abandonnant la ros?e<br/>
>          De pareil lotus,<br/>
>          Retournerai-je<br/>
>          Dans le monde changeant et frivole ?</q>  ?</p>
>      <p>et j'envoyais ce p?tale.</p>
>      <p class="source">
>          <cite class="auteur">Shonagon, Sei</cite>,
>          <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
> </blockquote>

That?s quite good, though I think <footer class="source"> would be in 
principle better than <p class="source">, though using <footer> still 
requires some precautions in practice (I mean ?teaching? it to old IE 
using document.createElement('footer') in JavaScript, so that your 
styling will take effect).

Microdata or microformats might be used to standardize the use of 
specific attributes to be used, like class="credits", class="author", 
class="title" etc., if desired. But I don?t think that?s particularly 
important.

(I don't like to nitpick on the author identification, but wouldn?t
<cite class="auteur" lang="jp-Latn">Sh?nagon, Sei</cite> be better?)

> My favorite issue being when there is a mix of cite in the prose and blockquotes,
 > there is no mechanism to associate the right cite with the right 
blockquote

It would be nice to be able to associate credits with quotations at the 
markup level, but in practice, presenting credits visibly (or audibly or 
touchably) is much more important. No law requires us to provide credits 
that way, but laws do require us to provide credits the way they are 
normally provided in good style (or in a better way).

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From svartman95 at gmail.com  Thu Jul 14 05:58:58 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 12:58:58 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAJpND8nWmviqW2g-vPpfijKEBnWqOvMkn9FGFBE4h9ri1DYw5w@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>	<4E1B3864.9050207@gmail.com>	<CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>	<4E1C2FFB.5060909@gmail.com>
	<CAJpND8nWmviqW2g-vPpfijKEBnWqOvMkn9FGFBE4h9ri1DYw5w@mail.gmail.com>
Message-ID: <4E1EE812.6010208@gmail.com>

?ann fim 14.j?l 2011 09:38, skrifa?i Oli Studholme:
> in graphic design a footer contains supplementary information about
> the content it follows. the spec initially disallowed ?fat footers?,
> but the naming and common usage would have led to people using them
> for fat footers regardless of the spec. they still contain
> supplementary information about their sectioning element or sectioning
> root. This semantic connection seems stronger to me than one based on
> arbitrary size
>
Would it not be less confusing to forbid 'fat footers' and rename footer 
-> credit?

From svartman95 at gmail.com  Thu Jul 14 06:10:06 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 13:10:06 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1ECE52.7090506@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi>
Message-ID: <4E1EEAAE.3050701@gmail.com>

?ann fim 14.j?l 2011 11:09, skrifa?i Jukka K. Korpela:
> 14.07.2011 13:49, Karl Dubost wrote:
>> <blockquote cite="urn:isbn:978-2-07-07533-7">
>> <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
>> <p>?<q>M?me si l'on vient me chercher<br/>
>> Comment, abandonnant la ros?e<br/>
>> De pareil lotus,<br/>
>> Retournerai-je<br/>
>> Dans le monde changeant et frivole ?</q> ?</p>
>> <p>et j'envoyais ce p?tale.</p>
>> <p class="source">
>> <cite class="auteur">Shonagon, Sei</cite>,
>> <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
>> </blockquote>
Yes, but for usability reasons the cite[@class=titre] should represent a 
hyperlink to the cited book. Is an user agent to find a cite descendant 
of <blockquote> and make it represent a hyperlink to the cited resource 
(identified by the URI in the cite attribute of blockquote)?

> (I don't like to nitpick on the author identification, but wouldn?t
> <cite class="auteur" lang="jp-Latn">Sh?nagon, Sei</cite> be better?)
I don't think author names are allowed in <cite> in HTML 5.

From timeless at gmail.com  Thu Jul 14 06:23:00 2011
From: timeless at gmail.com (timeless)
Date: Thu, 14 Jul 2011 09:23:00 -0400
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <op.vylop7byim6vpa@shwetank-dixits-macbook.local>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
	<op.vylop7byim6vpa@shwetank-dixits-macbook.local>
Message-ID: <CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>

I'd expect a web app to have no idea about device camera
specifications and thus to not be able to properly specify a flash
duration. I don't see how such a thing is valuable.

If a user is in a movie theater, or a museum, it's quite likely they
won't notice a web app is forcing a flash. Let the user control flash
through a useragent only or host application only mode. I believe the
hazards of exposing flash duration outweigh any benefits. The only
application class I know of built using control of camera flash is
"flash-light", and that's both a hack and not guaranteed to be
workable for all possible flash technologies.

On 7/14/11, Shwetank Dixit <shwetankd at opera.com> wrote:
> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
>
>>
>>> Another question is flash. As far as I have seen, there seems to be no
>>> option to specify whether the camera needs to use flash or not. Is this
>>> decision left up to the device? (If someone is making an app which is
>>> just clicking a picture of the person, then it would be nice to have the
>>> camera use flash in low light conditions).
>> getUserMedia() returns a video stream, so it wouldn't use a flash.
>
> Wouldn't it make sense to have a provision for flash separately then? I
> think a lot of apps would like just a picture instead of video, and in
> those cases, flash would be required. Maybe a seperate provision in the
> spec which defines whether to use flash, and if so, for how many
> miliseconds. Is that doable?
> --
> Shwetank Dixit
> Web Evangelist,
> Site Compatibility / Developer Relations / Core Engineering Group
> Member - W3C Mobile Web for Social Development (MW4D) Group
> Member - Web Standards Project (WaSP) - International Liaison Group
> Opera Software - www.opera.com
>
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>

-- 
Sent from my mobile device

From jonas at sicking.cc  Thu Jul 14 08:01:52 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 14 Jul 2011 08:01:52 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <4E1EA5D2.4060702@gmx.de>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de> <op.vylecs0564w2qv@annevk-macbookpro.local>
	<CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
	<4E1EA5D2.4060702@gmx.de>
Message-ID: <CA+c2ei9sYhpzvMMK+nSxaLByvromXVQzCeD1so8zJ3CGRKjLUw@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:16 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2011-07-14 08:22, Jonas Sicking wrote:
>>
>> On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren<annevk at opera.com>
>> ?wrote:
>>>
>>> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke<julian.reschke at gmx.de>
>>> ?wrote:
>>>>
>>>> Yes, but we can *define* the flag in HTML and write down what it means
>>>> with respect to plugin APIs.
>>>
>>> It seems much better to wait until it can actually be implemented.
>>
>> Especially since it's not at all clear to me that a specific opt-in
>> mechanism is at all needed once we have the appropriate plugin APIs
>> implemented. And those APIs are needed anyway if we want to allow
>> plugins in any form in the sandbox.
>
> "When the attribute is set, the content is treated as being from a unique
> origin, forms and scripts are disabled, links are prevented from targeting
> other browsing contexts, and plugins are disabled."
>
> A browser negotiating something with plugins using that API and enabling
> them despite @sandbox would violate the above requirement, no?

True. I would be fine with removing the plugin requirement. Or
changing it such that it states that plugins can only be loaded if
it's done in a manner that ensures that all other requirements are
still fulfilled. Or just dealing with this once there actually are
plugins and plugin APIs which could be loaded while still fulfilling
the other requirements.

/ Jonas

From acolwell at google.com  Thu Jul 14 09:08:41 2011
From: acolwell at google.com (Aaron Colwell)
Date: Thu, 14 Jul 2011 09:08:41 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLYP8ks3cAnjahjBjfd9P_UxXOi_2OUJBjW439hcre87+Q@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
	<CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
	<CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>
	<CAOp6jLYP8ks3cAnjahjBjfd9P_UxXOi_2OUJBjW439hcre87+Q@mail.gmail.com>
Message-ID: <CAA0c1bB9hWxysKZ4OFQHrio4d6CtpQr-OcNMROXk=yF3Yi5quw@mail.gmail.com>

On Wed, Jul 13, 2011 at 8:00 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Jul 14, 2011 at 4:35 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> I am open to suggestions. My intent was that the browser would not attempt
>> to cache any data passed into append(). It would just demux the buffers that
>> are sent in. When a seek is requested, it flushes whatever it has and waits
>> for more data from append().  If the web application wants to do caching it
>> can use the WebStorage or File APIs. If the browser's media engine needs a
>> certain amount of "preroll" data before it starts playback it can signal
>> this explicitly through new attributes or just use HAVE_FUTURE_DATA
>> & HAVE_ENOUGH_DATA readyStates to signal when it has enough.
>
>
> OK, I sorta get the idea. I think you're defining a new interface to the
> media processing pipeline that integrates with the demuxer and codecs at a
> different level to regular media resource loading. (For example, all the
> browser's built-in logic for seeking and buffering would have to be disabled
> and/or bypassed.)


Yes.


> As such, it would have to be carefully specified, potentially in a
> container- or codec-dependent way, unlike APIs like Blobs which work "just
> like" regular media resource loading and can thus work with any
> container/codec.
>

My hope is that the data passed to append will basically look like the "live
streaming" form of containers like Ogg & WebM so this isn't totally foreign
to the existing browser code. We'd probably have to spec the level of
support for Ogg chaining and multiple WebM segments but I don't think that
should be too bad. Seeking is where the trickiness happens and I was just
planning on making it look like a new "live" stream whose starting timestamp
indicates the actual point seeked to.

I was tempted to create an API that just passed in compressed video/audio
frames and made JavaScript do all of the demuxing, but I thought people
might find that too radical.


>
> I'm not sure what the best way to do this is, to be honest. It comes down
> to the use-cases. If you want to experiment with different seeking
> strategies, can't you just do that in Chrome itself? If you want scriptable
> adaptive streaming (or even if you don't) then I think we want APIs for
> seamless transitioning along a sequence of media resources, or between
> resources loaded in parallel.
>
>
I think the best course of action is for me to get my prototype in a state
where others can play with it and I can demonstrate some of the uses that
I'm trying to enable. I think that will make this a little more concrete.
 I'll keep this list posted on my progress.

Thanks for your help,
Aaron

From ifette at google.com  Thu Jul 14 11:45:21 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 11:45:21 -0700
Subject: [whatwg] a rel=attachment
Message-ID: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>

Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is to set a
content-disposition header. *However, sometimes it is not possible for the
page author to have control over the response headers sent by the
server.*(A related example is offline apps, which may wish to provide
the user with
a way to "download" a file stored locally using the filesystem API but again
can't set any headers.) It would be nice to provide the page author with a
client side mechanism to trigger a download.

After mulling this over with some application developers who are trying to
use this functionality, it seems like adding a "rel" attribute to the <a>
tag would be a straightforward, minimally invasive way to address this use
case. <a rel=attachment href=blah.pdf> would indicate that the browser
should treat this link as if the response came with a content-disposition:
attachment header, and offer to download/save the file for the user.

-Ian

From jackalmage at gmail.com  Thu Jul 14 11:49:44 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 11:49:44 -0700
Subject: [whatwg] Microdata - Handling the case where a string is upgraded
	to an object
Message-ID: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>

Some IRC discussion this morning concerned the scenario where an API
starts by exposing a property as a string, but later wants to change
it to be a complex object.

This appears to be a reasonably common scenario.  For example, a
vocabulary with a "name" property may start with it being a string,
and then later change to an object exposing "firstname"/"lastname"/etc
properties.  A vocabulary for a music library may start by having
"track" as a string, then later expanding it to expose the track
title, the individual artist, the running time, etc.

In a very similar vein, the CSSOM is currently defined to always
return property values as strings.  We want to instead return complex
objects that expose useful information and interfaces specialized on
the value's type, however.  For compat reasons, we have to use an
entirely different accessor in order to expose this type of thing.

It seems that this may be a useful problem to solve in Microdata.  We
can expose either an attribute or a privileged property name for the
object's "name"/"title"/"string representation".  Then, when using the
.items accessor, objects can be returned with a custom .toString that
returns that value, so they can be used as strings in legacy code.

Thoughts?

~TJ

From kevinmarks at gmail.com  Thu Jul 14 11:59:02 2011
From: kevinmarks at gmail.com (Kevin Marks)
Date: Thu, 14 Jul 2011 11:59:02 -0700
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
Message-ID: <CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>

There is another common pattern, seen in blogging a lot, of putting
the citation at the top eg
As <cite class="vcard"><a href="http://www.gyford.com/phil/"
class="url" rel="acquaintance met colleague"><abbr title="Phil Gyford"
class="fn">Phil</abbr></a></cite> wrote about the <a
href="http://www.gyford.com/phil/writing/2009/04/28/geocities.php">ugly
and neglected fragments</a> of Geocities:</p>

<blockquote>
  <p>GeoCities is an awful, ugly, decrepit mess. And this is why it
will be sorely missed. It?s not only a fine example of the amateur web
vernacular but much of it is an increasingly rare example of a
<em>period</em> web vernacular. GeoCities sites show what normal,
non-designer, people will create if given the tools available around
the turn of the millennium.</p>
</blockquote>

(from jeremy) or pretty much any post here:

http://www.theatlantic.com/ta-nehisi-coates/

Would a <header> pattern in the blockquote work for this?

If I was writing a detector for this pattern, <a> followed by a colon
and  <blockquote> would do it pretty reliably...

On Fri, Jul 8, 2011 at 4:20 AM, Jeremy Keith <jeremy at adactio.com> wrote:
>
> Oli wrote:
> > I?ve outlined the problem and some potential solutions (with their
> > pros and cons) in:
> > ?http://oli.jp/2011/blockquote/
>
> Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/
>
> Oli continues:
> > I think the blockquote spec should be changed to allow the inclusion
> > of notes and attribution (quote metadata), perhaps by the addition of
> > a sentence like:
> > ??Block quotes may also contain annotations or attribution, inline or
> > in an optional footer element?
> > This would change blockquote from being purely source content, to
> > being source content with possible metadata inline or in a footer.
> > However I don?t think that?s a problem, as these things increase the
> > value of the quoted content. I think a spec change is necessary to
> > accommodate common quoting practices.
>
> This sounds good to me.
>
> 1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the "Pave the cowpaths" principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material):
>
> http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths
>
> "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
>
>
> 2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle "Solve real problems."
>
> http://www.w3.org/TR/html-design-principles/#solve-real-problems
>
> "Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today."
>
>
> 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle "Avoid needless complexity."
>
> http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity
>
> "Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand."
>
>
> 4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle "Support existing content."
>
> http://www.w3.org/TR/html-design-principles/#support-existing-content
>
> "The benefit of the proposed change should be weighed against the likely cost of breaking content"
>
> Jeremy
>
> --
> Jeremy Keith
>
> a d a c t i o
>
> http://adactio.com/
>
>

From ifette at google.com  Thu Jul 14 12:00:16 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 12:00:16 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CAF4kx8eo97CYxPULzvy3goaMXR_Ns2yCqfvVPQ_269ip9+KFMA@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>

> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
> After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.
>
> -Ian
>

I should also point out that there was a similar proposal from Dennis
Joachimsthaler last year. There was a fair amount of discussion on the
thread back and forth; near the end Hixie's recommendation [1] was to
propose this as a rel= attribute and push forward with implementation. That
is essentially what we intend to do.

[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028148.html

-Ian

From karld at opera.com  Thu Jul 14 12:03:43 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 15:03:43 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <00DACDFE-FA6B-4DA2-BDD6-1A73ACB9EC12@opera.com>


Le 14 juil. 2011 ? 14:45, Ian Fette (????????) a ?crit :
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example).

Which current websites?

> it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.



Are you then proposing to reverse the contextual click on the link to give the option, "view in the browser". All browsers have currently implemented "save this link as"?

It may please some users. As a user, I will place this in the category of super annoying features. It then means I would need a preference in the browser to disable it. 

Then it is at least 3 modifications to implement it.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From ifette at google.com  Thu Jul 14 12:08:19 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 12:08:19 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <00DACDFE-FA6B-4DA2-BDD6-1A73ACB9EC12@opera.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<00DACDFE-FA6B-4DA2-BDD6-1A73ACB9EC12@opera.com>
Message-ID: <CAF4kx8cSKqj+B0AWayhFchjFXiRDZeJBUY2Xg7ZKq6X-w29XAQ@mail.gmail.com>

On Thu, Jul 14, 2011 at 12:03 PM, Karl Dubost <karld at opera.com> wrote:

>
> Le 14 juil. 2011 ? 14:45, Ian Fette (????????) a ?crit :
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example).
>
> Which current websites?
>
> Take gmail as one example off the top of my head. If any of these files are
present as an attachment I get an option to view or download.



> > it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
>
>
> Are you then proposing to reverse the contextual click on the link to give
> the option, "view in the browser". All browsers have currently implemented
> "save this link as"?
>
> It may please some users. As a user, I will place this in the category of
> super annoying features. It then means I would need a preference in the
> browser to disable it.
>
> Then it is at least 3 modifications to implement it.
>


Not for all links, no, only links that have rel=attachment. And I would
assume that on such a link, yes, perhaps a "view inline" right click option
may make sense. I wouldn't expect this to be used on anywhere near a
majority of links, but an author can already try to craft a download link --
it's just that in many cases it's either requiring them to jump through
hoops or impossible (e.g. offline apps).


>
> --
> Karl Dubost - http://dev.opera.com/
> Developer Relations & Tools, Opera Software
>
>

From andy at pigsonthewing.org.uk  Thu Jul 14 12:15:03 2011
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu, 14 Jul 2011 20:15:03 +0100
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CABiXOE=9Dy7usKGF9_j827=YGjSfCTtv_S9TtmeDj_KB_1y5gg@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>:
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the
> server.*(A related example is offline apps, which may wish to provide
> the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
> After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.

How would this be different to the already-available rel="enclosure" ?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

From ifette at google.com  Thu Jul 14 12:22:43 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 12:22:43 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABiXOE=9Dy7usKGF9_j827=YGjSfCTtv_S9TtmeDj_KB_1y5gg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABiXOE=9Dy7usKGF9_j827=YGjSfCTtv_S9TtmeDj_KB_1y5gg@mail.gmail.com>
Message-ID: <CAF4kx8dNZyfmg0YsxAHusF1SaJp=oogNx8LHQhmC1As1pF5Zzg@mail.gmail.com>

2011/7/14 Andy Mabbett <andy at pigsonthewing.org.uk>

> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> > page author to have control over the response headers sent by the
> > server.*(A related example is offline apps, which may wish to provide
> > the user with
> > a way to "download" a file stored locally using the filesystem API but
> again
> > can't set any headers.) It would be nice to provide the page author with
> a
> > client side mechanism to trigger a download.
> >
> > After mulling this over with some application developers who are trying
> to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
> How would this be different to the already-available rel="enclosure" ?
>

It seems quite similar, except that afaik no browser yet acts on enclosure.
I don't want to get into bikeshedding discussions, both enclosure and
attachment have precedent, I simply want to implement this :)


>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>

From svartman95 at gmail.com  Thu Jul 14 12:26:20 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 19:26:20 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
Message-ID: <CAOKKrgNzTvZWxeY641q+z0NYOYArd-AV1vHbu+VyZSQtd6QXSA@mail.gmail.com>

On 7/14/11, Kevin Marks <kevinmarks at gmail.com> wrote:
> There is another common pattern, seen in blogging a lot, of putting
> the citation at the top eg
> As <cite class="vcard"><a href="http://www.gyford.com/phil/"
> class="url" rel="acquaintance met colleague"><abbr title="Phil Gyford"
> class="fn">Phil</abbr></a></cite> wrote about the <a
> href="http://www.gyford.com/phil/writing/2009/04/28/geocities.php">ugly
> and neglected fragments</a> of Geocities:</p>
>
> <blockquote>
>   <p>GeoCities is an awful, ugly, decrepit mess. And this is why it
> will be sorely missed. It?s not only a fine example of the amateur web
> vernacular but much of it is an increasingly rare example of a
> <em>period</em> web vernacular. GeoCities sites show what normal,
> non-designer, people will create if given the tools available around
> the turn of the millennium.</p>
> </blockquote>
>
> (from jeremy) or pretty much any post here:
>
> http://www.theatlantic.com/ta-nehisi-coates/
>
> Would a <header> pattern in the blockquote work for this?
>
> If I was writing a detector for this pattern, <a> followed by a colon
> and  <blockquote> would do it pretty reliably...
>
Ideally, the same markup should be used to mark citations up whether
they're displayed one way or another. Whether to render author name(s)
before or after the quotation is a matter of style.

From svartman95 at gmail.com  Thu Jul 14 12:35:41 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 19:35:41 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CAOKKrgNxQt_WXZ_88HO_kV65uH=SnSQ=W2C9V3si97uFJ2KuxA@mail.gmail.com>

On 7/14/11, Ian Fette (????????) <ifette at google.com> wrote:
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the
> server.*(A related example is offline apps, which may wish to provide
> the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
As already stated you can use rel="enclosure". Alternatively, you can
specify the type attribute with the appropriate value and let the user
agent offer to write it to permanent storage.

From karld at opera.com  Thu Jul 14 12:35:49 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 15:35:49 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
Message-ID: <9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>


Le 14 juil. 2011 ? 14:59, Kevin Marks a ?crit :
> If I was writing a detector for this pattern, <a> followed by a colon
> and  <blockquote> would do it pretty reliably...

yup unfortunately there are also many cases where you have more names in an introducing paragraph. It is happening when I'm writing, and the issue is then to tie the right person with the right blockquote/q

I like the pattern id/for pattern of forms. We could imagine

<p>
<span for="quoteA" class="author">Sir John Typo</span> 
has written plenty of a wonderful thing 
in <cite for="quoteA">Amazing title</cite> very similar to those in
<span for="quoteB" class="author">Susan Spellchecker</span>'s writings

<blockquote id="quoteA">
[?]
</blockquote>

compare to <cite for="quoteB">Amazing title</cite>

<blockquote id="quoteB">
</blockquote>


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From glenn at zewt.org  Thu Jul 14 12:36:13 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 14 Jul 2011 15:36:13 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>

> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
>

This has been raised a couple times:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
was derailed partway through)

I've wanted this several times and I'm strongly in favor of it.

After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
>

This isn't enough; the filename needs to be overridable as well, as it is
with Content-Disposition.  My recommendation has been:

<a href=image.jpg download>
<a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>

where the first is equivalent to Content-Disposition: attachment, and the
second is equivalent to Content-Disposition: attachment;
filename=picture.jpg.

-- 
Glenn Maynard

From tantek at cs.stanford.edu  Thu Jul 14 12:51:17 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 12:51:17 -0700
Subject: [whatwg] proposal: extend <time> to markup durations
Message-ID: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>

Some in the microformats community have been making good use of the
<time> element, e.g. for publishing hCalendar, and implementing
consuming/converting hCalendar [1] with good success.

It would be great if the <time> element could support expressing
durations as well for the use cases as needed by the hMedia and hAudio
microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal, examples, faq, discussion (please contribute)

http://wiki.whatwg.org/wiki/Time_element#duration

Thanks,

Tantek

[1] http://microformats.org/wiki/h2vx#HTML5_support

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From ifette at google.com  Thu Jul 14 13:13:33 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 13:13:33 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
Message-ID: <CAF4kx8eMH0ThXo4KEBPFRCyLZKJ2oZmSRxE7cqHwopaTMb_fjQ@mail.gmail.com>

The download=filename seems like a nice proposal (assuming that the filename
is optional, and if not specified it just takes whatever the name would
otherwise be). It also neatly solves the filename issue without cluttering
the a tag with tons of options.

On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>
> Many websites wish to offer a file for download, even though it could
>> potentially be viewed inline (take images, PDFs, or word documents as an
>> example). Traditionally the only way to achieve this is to set a
>> content-disposition header. *However, sometimes it is not possible for the
>>
>
> This has been raised a couple times:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through)
>
> I've wanted this several times and I'm strongly in favor of it.
>
> After mulling this over with some application developers who are trying to
>> use this functionality, it seems like adding a "rel" attribute to the <a>
>> tag would be a straightforward, minimally invasive way to address this use
>> case. <a rel=attachment href=blah.pdf> would indicate that the browser
>>
>
> This isn't enough; the filename needs to be overridable as well, as it is
> with Content-Disposition.  My recommendation has been:
>
> <a href=image.jpg download>
> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>
>
> where the first is equivalent to Content-Disposition: attachment, and the
> second is equivalent to Content-Disposition: attachment;
> filename=picture.jpg.
>
> --
> Glenn Maynard
>
>

From darin at chromium.org  Thu Jul 14 13:16:57 2011
From: darin at chromium.org (Darin Fisher)
Date: Thu, 14 Jul 2011 13:16:57 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
Message-ID: <CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>

On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> >
>
> This has been raised a couple times:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
> was derailed partway through)
>
> I've wanted this several times and I'm strongly in favor of it.
>

Yes, it seems very useful.



>
> After mulling this over with some application developers who are trying to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> >
>
> This isn't enough; the filename needs to be overridable as well, as it is
> with Content-Disposition.  My recommendation has been:
>
> <a href=image.jpg download>
> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>
>
> where the first is equivalent to Content-Disposition: attachment, and the
> second is equivalent to Content-Disposition: attachment;
> filename=picture.jpg.
>
>
This is an interesting variation!  I like that it addresses the issue of
providing a name for the download.  Using the term "download" here is also
nice.

I know that there is also a proposal to add a FileSaver API.  I like that as
well, _but_ it is very nice to be able to simply decorate an anchor tag.  In
many cases, that will be a lot simpler for developers than using JavaScript
to construct a FileSaver.  I think it makes sense to implement both.

On the other thread, Michal Zalewski raised a concern about giving
client-side JS the power to name files.  It looks like that discussion did
not conclude, but I will note that even without the proposal here to name
the download, an attacker could still have control over the downloaded
filename.  They could either manufacture a file using the FileSystem API,
and then get a filesystem: URL to that file, or they could simply use a
server to produce an URL with a C-D header of their choosing.  It seems like
we are well past the point of trying to limit a web page authors ability to
influence the downloaded filename.  Fortunately, however, user agents can
protect the user from potentially harmful downloads.  Chrome for instance
asks the user to confirm the download of a EXE file before we ever write a
file to the filesystem with a .exe extension.

-Darin

From tantek at cs.stanford.edu  Thu Jul 14 13:32:15 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 13:32:15 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
Message-ID: <CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>

2011/7/14 Darin Fisher <darin at chromium.org>:
> On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>>
>> > Many websites wish to offer a file for download, even though it could
>> > potentially be viewed inline (take images, PDFs, or word documents as an
>> > example). Traditionally the only way to achieve this is to set a
>> > content-disposition header. *However, sometimes it is not possible for
>> the
>> >
>>
>> This has been raised a couple times:
>>
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>>
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
>> was derailed partway through)
>>
>> I've wanted this several times and I'm strongly in favor of it.
>>
>
> Yes, it seems very useful.

Indeed, and has been pointed out, already specified (since 2005) and
implemented as well for HTML:

http://microformats.org/wiki/rel-enclosure

re-using the "enclosure" term from the Atom format (thus minimal bikeshedding)


>> After mulling this over with some application developers who are trying to
>> > use this functionality, it seems like adding a "rel" attribute to the <a>
>> > tag would be a straightforward, minimally invasive way to address this
>> use
>> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
>> >
>>
>> This isn't enough; the filename needs to be overridable as well, as it is
>> with Content-Disposition. ?My recommendation has been:
>>
>> <a href=image.jpg download>
>> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>
>>
>> where the first is equivalent to Content-Disposition: attachment, and the
>> second is equivalent to Content-Disposition: attachment;
>> filename=picture.jpg.
>>
>>
> This is an interesting variation! ?I like that it addresses the issue of
> providing a name for the download. ?Using the term "download" here is also
> nice.

Agreed.

I've captured the suggestion on a brainstorming page:

http://microformats.org/wiki/rel-enclosure-brainstorming

Feel free to contribute or iterate.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From darin at chromium.org  Thu Jul 14 13:46:38 2011
From: darin at chromium.org (Darin Fisher)
Date: Thu, 14 Jul 2011 13:46:38 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
Message-ID: <CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:32 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> 2011/7/14 Darin Fisher <darin at chromium.org>:
> > On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
> >
> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>
> >>
> >> > Many websites wish to offer a file for download, even though it could
> >> > potentially be viewed inline (take images, PDFs, or word documents as
> an
> >> > example). Traditionally the only way to achieve this is to set a
> >> > content-disposition header. *However, sometimes it is not possible for
> >> the
> >> >
> >>
> >> This has been raised a couple times:
> >>
> >>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
> >>
> >>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
> >> was derailed partway through)
> >>
> >> I've wanted this several times and I'm strongly in favor of it.
> >>
> >
> > Yes, it seems very useful.
>
> Indeed, and has been pointed out, already specified (since 2005) and
> implemented as well for HTML:
>
> http://microformats.org/wiki/rel-enclosure
>
> re-using the "enclosure" term from the Atom format (thus minimal
> bikeshedding)
>
>
> >> After mulling this over with some application developers who are trying
> to
> >> > use this functionality, it seems like adding a "rel" attribute to the
> <a>
> >> > tag would be a straightforward, minimally invasive way to address this
> >> use
> >> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> >> >
> >>
> >> This isn't enough; the filename needs to be overridable as well, as it
> is
> >> with Content-Disposition.  My recommendation has been:
> >>
> >> <a href=image.jpg download>
> >> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg
> download=picture.jpg>
> >>
> >> where the first is equivalent to Content-Disposition: attachment, and
> the
> >> second is equivalent to Content-Disposition: attachment;
> >> filename=picture.jpg.
> >>
> >>
> > This is an interesting variation!  I like that it addresses the issue of
> > providing a name for the download.  Using the term "download" here is
> also
> > nice.
>
> Agreed.
>
> I've captured the suggestion on a brainstorming page:
>
> http://microformats.org/wiki/rel-enclosure-brainstorming
>
> Feel free to contribute or iterate.
>
> Thanks,
>
> Tantek
>
>
Why do you feel it is important to specify rel=enclosure in addition to the
download attribute?

Thanks,
-Darin

From tantek at cs.stanford.edu  Thu Jul 14 13:48:18 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 13:48:18 -0700
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
	<9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
Message-ID: <CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>

In agreement with Jeremy, I too have found the blockquote/q cite
attribute to be nearly as ignored as the longdesc attribute, despite
having conducted talks and written tutorials about how to use the
cite="" attribute (makes me think that the non-visible-effect-URL
attributes on elements should be considered an anti-pattern, evidenced
by the fact that they (cite, longdesc, profile etc.) have all failed
to get any meaningful uptake among web developers).

On slightly a more positive note:

On Thu, Jul 14, 2011 at 12:35, Karl Dubost <karld at opera.com> wrote:
>
> Le 14 juil. 2011 ? 14:59, Kevin Marks a ?crit :
>> If I was writing a detector for this pattern, <a> followed by a colon
>> and ?<blockquote> would do it pretty reliably...
>
> yup unfortunately there are also many cases where you have more names in an introducing paragraph. It is happening when I'm writing, and the issue is then to tie the right person with the right blockquote/q
>
> I like the pattern id/for pattern of forms. We could imagine
>
> <p>
> <span for="quoteA" class="author">Sir John Typo</span>
> has written plenty of a wonderful thing
> in <cite for="quoteA">Amazing title</cite> very similar to those in
> <span for="quoteB" class="author">Susan Spellchecker</span>'s writings
>
> <blockquote id="quoteA">
> [?]
> </blockquote>
>
> compare to <cite for="quoteB">Amazing title</cite>
>
> <blockquote id="quoteB">
> </blockquote>

I really like this pattern.

<label for="input-id"> is a known working and in use pattern.

Thus I feel much more confident advocating use of the parallel:

<cite for="quote-id">

With one concern - multiple blockquotes. Thus the for attribute should
be a space separated set of IDREFs. E.g. this pattern (often seen on
blog posts analyzing articles and other blog posts)

<cite for="quote1 quote2">Some quoted title of a work</cite>
<blockquote id="quote1"> one quotation </blockquote>
<p> .. intervening commentary .. </p>
<blockquote id="quote2"> another quotation </blockquote>
<p> .. more commentary ..</p>

Though that example is vulnerable to bad copy/paste errors. It
requires two markup updates (done consistently) for each copy/paste: a
new id on each new blockquote, and having to update the original cite
element for each additional blockquote.


That example redone with today's cite attribute would be:

<cite id="cite1">Some quoted title of a work</cite>
<blockquote cite="#cite1"> one quotation </blockquote>
<p> .. intervening commentary .. </p>
<blockquote cite="#cite1"> another quotation </blockquote>
<p> .. more commentary ..</p>

which is then much more copy/paste proof if/when the author adds more
blockquotes from the same source that they're commenting on - fewer
bits of markup (none) to update.

So I don't know. Perhaps <cite for> handles the 80/20 one cite / one
quote case better and that's good enough to add it, and then perhaps
we keep the old cite="" attribute for the one cite / multiple quote
case?

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From tantek at cs.stanford.edu  Thu Jul 14 13:52:11 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 13:52:11 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>
Message-ID: <CAOACb=LGnySWvH0G+Qf4NC0yMP-_ovxS2_uthHk413LH+QJHow@mail.gmail.com>

On Thu, Jul 14, 2011 at 13:46, Darin Fisher <darin at chromium.org> wrote:
>
>
> On Thu, Jul 14, 2011 at 1:32 PM, Tantek ?elik <tantek at cs.stanford.edu>
> wrote:
>>
>> 2011/7/14 Darin Fisher <darin at chromium.org>:
>> > On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
>> >
>> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>> >>
>> >> > Many websites wish to offer a file for download, even though it could
>> >> > potentially be viewed inline (take images, PDFs, or word documents as
>> >> > an
>> >> > example). Traditionally the only way to achieve this is to set a
>> >> > content-disposition header. *However, sometimes it is not possible
>> >> > for
>> >> the
>> >> >
>> >>
>> >> This has been raised a couple times:
>> >>
>> >>
>> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>> >>
>> >>
>> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
>> >> was derailed partway through)
>> >>
>> >> I've wanted this several times and I'm strongly in favor of it.
>> >>
>> >
>> > Yes, it seems very useful.
>>
>> Indeed, and has been pointed out, already specified (since 2005) and
>> implemented as well for HTML:
>>
>> http://microformats.org/wiki/rel-enclosure
>>
>> re-using the "enclosure" term from the Atom format (thus minimal
>> bikeshedding)
>>
>>
>> >> After mulling this over with some application developers who are trying
>> >> to
>> >> > use this functionality, it seems like adding a "rel" attribute to the
>> >> > <a>
>> >> > tag would be a straightforward, minimally invasive way to address
>> >> > this
>> >> use
>> >> > case. <a rel=attachment href=blah.pdf> would indicate that the
>> >> > browser
>> >> >
>> >>
>> >> This isn't enough; the filename needs to be overridable as well, as it
>> >> is
>> >> with Content-Disposition. ?My recommendation has been:
>> >>
>> >> <a href=image.jpg download>
>> >> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg
>> >> download=picture.jpg>
>> >>
>> >> where the first is equivalent to Content-Disposition: attachment, and
>> >> the
>> >> second is equivalent to Content-Disposition: attachment;
>> >> filename=picture.jpg.
>> >>
>> >>
>> > This is an interesting variation! ?I like that it addresses the issue of
>> > providing a name for the download. ?Using the term "download" here is
>> > also
>> > nice.
>>
>> Agreed.
>>
>> I've captured the suggestion on a brainstorming page:
>>
>> http://microformats.org/wiki/rel-enclosure-brainstorming
>>
>> Feel free to contribute or iterate.
>>
>> Thanks,
>>
>> Tantek
>>
>
> Why do you feel it is important to specify rel=enclosure in addition to the
> download attribute?
> Thanks,
> -Darin

Other way around.

rel="enclosure" is sufficient for today's use cases because authors
simply name the file accordingly on their server and then
implementations simply use the last segment of the URL as the filename
- presto 80/20 case solved (and solved 6 years ago with no
modification needed to HTML for it to be valid).

Having to specify a "download" attribute that reflects a filename
different from the last segment of the URL is the minority case, but
still sufficient to justify addition of the attribute.

Also the empty download attribute doesn't work as it is supposed to be
equivalent to download="download" which would simply name the file
"download" which is unlikely what author or user want.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From glenn at zewt.org  Thu Jul 14 13:53:19 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 14 Jul 2011 16:53:19 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
Message-ID: <CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>

2011/7/14 Darin Fisher <darin at chromium.org>

> I know that there is also a proposal to add a FileSaver API.  I like that
> as well, _but_ it is very nice to be able to simply decorate an anchor tag.
>  In many cases, that will be a lot simpler for developers than using
> JavaScript to construct a FileSaver.  I think it makes sense to implement
> both.
>

FileSaver is useful in its own right, but it's not a great fit for this.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html

That reminds me of something download=filename can't do: assign a filename
while leaving it inline, so "save as" and other operations can have a
specified filename.  That would require two separate properties.  One case
I've come across is <img>, where I want to display an image, but provide a
different filename for save-as.  Separating the filename would allow this to
be applied generically both links and inline resources: <img
src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>.

In that case, rel=enclosure would probably make sense.

On the other thread, Michal Zalewski raised a concern about giving
> client-side JS the power to name files.
>

That subthread just seemed to be asking whether browsers should implement
Content-Disposition, which didn't seem relevant--they already have, for
years.

Separately, there was a security question raised about the ability to serve
a file off of a third-party site with a different filename than was
intended.  For example, uploading a file which is both an executable trojan
and a valid JPEG to an image hosting site, and linking to it externally,
overriding its filename to .EXE.  The question there isn't about being able
to serve executables--you can always do that--but being able to serve
executables that appear to be from the image hosting site.  Arguably, it
could 1: cause users to trust the file because it appears to be from a site
they recognize, or 2: cause the site to be blamed for the trojan.

I mention it so people don't have to scour the previous threads for it, but
I think it's uncompelling.  It just seems like something UI designers would
need to take into consideration.  (In my opinion, the trust and blame for
saving a file to disk should be applied to the host *linking* the file, and
not from the site hosting the file, which makes the above irrelevant.)

-- 
Glenn Maynard

From darin at chromium.org  Thu Jul 14 13:58:32 2011
From: darin at chromium.org (Darin Fisher)
Date: Thu, 14 Jul 2011 13:58:32 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
Message-ID: <CAP0-QpsBZu_xWY3eELnTDcKUVrforC+_0+nbZ3RQ4NCmMQHawA@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Darin Fisher <darin at chromium.org>
>
>> I know that there is also a proposal to add a FileSaver API.  I like that
>> as well, _but_ it is very nice to be able to simply decorate an anchor tag.
>>  In many cases, that will be a lot simpler for developers than using
>> JavaScript to construct a FileSaver.  I think it makes sense to implement
>> both.
>>
>
> FileSaver is useful in its own right, but it's not a great fit for this.
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html
>
> That reminds me of something download=filename can't do: assign a filename
> while leaving it inline, so "save as" and other operations can have a
> specified filename.  That would require two separate properties.  One case
> I've come across is <img>, where I want to display an image, but provide a
> different filename for save-as.  Separating the filename would allow this to
> be applied generically both links and inline resources: <img
> src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>.
>
> In that case, rel=enclosure would probably make sense.
>

Yeah, that makes a lot of sense.  I'm fine with using rel=enclosure too.


>
> On the other thread, Michal Zalewski raised a concern about giving
>> client-side JS the power to name files.
>>
>
> That subthread just seemed to be asking whether browsers should implement
> Content-Disposition, which didn't seem relevant--they already have, for
> years.
>
> Separately, there was a security question raised about the ability to serve
> a file off of a third-party site with a different filename than was
> intended.  For example, uploading a file which is both an executable trojan
> and a valid JPEG to an image hosting site, and linking to it externally,
> overriding its filename to .EXE.  The question there isn't about being able
> to serve executables--you can always do that--but being able to serve
> executables that appear to be from the image hosting site.  Arguably, it
> could 1: cause users to trust the file because it appears to be from a site
> they recognize, or 2: cause the site to be blamed for the trojan.
>
> I mention it so people don't have to scour the previous threads for it, but
> I think it's uncompelling.  It just seems like something UI designers would
> need to take into consideration.  (In my opinion, the trust and blame for
> saving a file to disk should be applied to the host *linking* the file, and
> not from the site hosting the file, which makes the above irrelevant.)
>
>
Agreed.  I suspect that users will associate a download with whatever host
they see in the location bar.

-Darin

From jackalmage at gmail.com  Thu Jul 14 13:59:35 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 13:59:35 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
Message-ID: <CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:32 PM, Tantek ?elik <tantek at cs.stanford.edu> wrote:
> Indeed, and has been pointed out, already specified (since 2005) and
> implemented as well for HTML:
>
> http://microformats.org/wiki/rel-enclosure
>
> re-using the "enclosure" term from the Atom format (thus minimal bikeshedding)

"enclosure" is a completely opaque name.  I have no idea how it is
meant to refer to "download the linked resource instead of navigating
to it".  If I think about it in terms of Atom I can *kinda* imagine
it, but it feels like a bad term there, and it would be an even worse
term in HTML.

A boolean @download attribute is much clearer and more direct.  If
you're using @download to name the file as well, then adding a @rel
value is unneeded.

~TJ

From karld at opera.com  Thu Jul 14 14:18:00 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 17:18:00 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
	<9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
	<CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
Message-ID: <19BA895C-998E-492A-A356-0F8BC9227E49@opera.com>


Le 14 juil. 2011 ? 16:48, Tantek ?elik a ?crit :
> cite="" attribute (makes me think that the non-visible-effect-URL
> attributes on elements

Yup. :) and there are ways to improve what the browser doesn't do :) 
(though I really think the browser should)
I made a prototype for this

https://github.com/karlcow/QuoteLink
https://addons.opera.com/addons/extensions/details/quotelink/

any suggestions for improving are welcome.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From karld at opera.com  Thu Jul 14 14:25:29 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 17:25:29 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <2C226A9A-E24F-49E6-8341-C1B378361FFF@opera.com>


Le 14 juil. 2011 ? 14:45, Ian Fette (????????) a ?crit :
> <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.

A random thought just occured to me (maybe dumb)
But is it a relation qualifier or in fact a target?
In http://dev.w3.org/html5/spec/browsers.html#valid-browsing-context-name-or-keyword

    A valid browsing context name or keyword is any string
    that is either a valid browsing context name or that is
    an ASCII case-insensitive match for one of: _blank,
    _self, _parent, or _top.
                    
what about adding 

<a href="foo.pdf" target="_download">Save a Tree, Eat a beaver</a>


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From jackalmage at gmail.com  Thu Jul 14 14:35:40 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 14:35:40 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAOACb=LGnySWvH0G+Qf4NC0yMP-_ovxS2_uthHk413LH+QJHow@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>
	<CAOACb=LGnySWvH0G+Qf4NC0yMP-_ovxS2_uthHk413LH+QJHow@mail.gmail.com>
Message-ID: <CAAWBYDC=93kHX88LTNQB1gqqc4NTPpZZ1UcBwqQxdOeb6NBqow@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:52 PM, Tantek ?elik <tantek at cs.stanford.edu> wrote:
> Also the empty download attribute doesn't work as it is supposed to be
> equivalent to download="download" which would simply name the file
> "download" which is unlikely what author or user want.

This is incorrect.  If you omit an attribute's value it becomes the
empty string.  See this testcase:

<!DOCTYPE html>
<body foo>
</body>
<script>
alert(document.body.getAttribute('foo'));
</script>

(In SGML languages, omitting an attribute's value was *actually*
omitting the attribute name, and the name was inferred from looking in
the DTD for what attribute had that as a possible enumerated value.
This is why XHTML1 requires boolean attributes to be written as
foo='foo'.  XHTML5, though, prefers the form foo='', as that makes the
value identical to what it would be as an HTML boolean attribute.)

~TJ

From ian at hixie.ch  Thu Jul 14 14:36:36 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Jul 2011 21:36:36 +0000 (UTC)
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>

On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
>
> Some in the microformats community have been making good use of the 
> <time> element, e.g. for publishing hCalendar, and implementing 
> consuming/converting hCalendar [1] with good success.
> [1] http://microformats.org/wiki/h2vx#HTML5_support
> 
> It would be great if the <time> element could support expressing 
> durations as well for the use cases as needed by the hMedia and hAudio 
> microformats as well as other use-cases (Wikipedia, IMDB).
> 
> Simple proposal, examples, faq, discussion (please contribute)
> 
> http://wiki.whatwg.org/wiki/Time_element#duration

I haven't studied the above yet, but I just wanted to bring up a trial 
balloon for a possible alternative solution: drop <time> and replace it 
with a generic solution.

There are several use cases for <time>:

A. Easier styling of dates and times from CSS.

B. A way to mark up the publication date/time for an article (e.g. for 
conversion to Atom).

C. A way to mark up machine-readable times and dates for use in 
Microformats or microdata.

Use cases A and B do not seem to have much traction.

Use case C applies to more than just dates, and the lack of solution for 
stuff outside dates and times is being problematic to many communities.

Proposal: we dump use cases A and B, and pivot <time> on use case C, 
changing it to <data> and making it like the <abbr> for machine-readable 
data, primarily for use by Microformats and HTML's microdata feature.


(I've also filed this as a bug here:
   http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240
I generally prefer to only have issues discussed either in e-mail or in a 
bug, but Tantek informs me that for technical reasons he can't discuss 
this on the bug and his input is more important to me than convention, 
thus my bringing this up here again!)

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

From jackalmage at gmail.com  Thu Jul 14 14:44:15 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 14:44:15 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
Message-ID: <CAAWBYDCEJcie1aiS=6syQFQxGmM6+M1NT9LsbuP2aO6AAKgQVQ@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard <glenn at zewt.org> wrote:
> That reminds me of something download=filename can't do: assign a filename
> while leaving it inline, so "save as" and other operations can have a
> specified filename. ?That would require two separate properties. ?One case
> I've come across is <img>, where I want to display an image, but provide a
> different filename for save-as. ?Separating the filename would allow this to
> be applied generically both links and inline resources: <img
> src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>.

Optimizing for the user choosing to right-click=>Save seems like a
much more niche case than linking to a file that should be downloaded.

Plus, you could address it by just wrapping the <img> in an <a>:

<a href=uglyurl.jpg download=prettyurl.jpg><img src=uglyurl.jpg></a>

Alternately, there's nothing saying that @download can't be useful on
<img> directly.  It would still be embedded normally, but @download
would set the download filename the same way that it does on <a>.  (It
seems more obvious to me that the download filename is in @download
than @filename - the latter seems likely to confused people into
thinking that it's involved somehow in linking to the image, or that
you're required to set the filename on all images).

~TJ

From jackalmage at gmail.com  Thu Jul 14 14:51:37 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 14:51:37 -0700
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>

On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
>> Some in the microformats community have been making good use of the
>> <time> element, e.g. for publishing hCalendar, and implementing
>> consuming/converting hCalendar [1] with good success.
>> [1] http://microformats.org/wiki/h2vx#HTML5_support
>>
>> It would be great if the <time> element could support expressing
>> durations as well for the use cases as needed by the hMedia and hAudio
>> microformats as well as other use-cases (Wikipedia, IMDB).
>>
>> Simple proposal, examples, faq, discussion (please contribute)
>>
>> http://wiki.whatwg.org/wiki/Time_element#duration
>
> I haven't studied the above yet, but I just wanted to bring up a trial
> balloon for a possible alternative solution: drop <time> and replace it
> with a generic solution.
>
> There are several use cases for <time>:
>
> A. Easier styling of dates and times from CSS.
>
> B. A way to mark up the publication date/time for an article (e.g. for
> conversion to Atom).
>
> C. A way to mark up machine-readable times and dates for use in
> Microformats or microdata.
>
> Use cases A and B do not seem to have much traction.
>
> Use case C applies to more than just dates, and the lack of solution for
> stuff outside dates and times is being problematic to many communities.
>
> Proposal: we dump use cases A and B, and pivot <time> on use case C,
> changing it to <data> and making it like the <abbr> for machine-readable
> data, primarily for use by Microformats and HTML's microdata feature.

I'm fine with this, but as I expressed when this was discussed
earlier, I think this should be more explicitly aimed at Microdata,
with something like <itemdata @itemprop @data>...</itemdata>.

This makes it less immediately applicable to Microformats, but in my
opinion Microformats should switch to using Microdata as their
embedding syntax, as that would solve their "you have to write a
custom parser for each vocab" problem.

(I want to address usecase A at some point, but it's a complicated
problem that I don't have anywhere near the bandwidth for.  It doesn't
necessarily require <time>, though - <itemdata> would work just fine
if CSS specified a particular date format that the data had to be in.)

~TJ

From svartman95 at gmail.com  Thu Jul 14 14:55:32 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 21:55:32 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <2C226A9A-E24F-49E6-8341-C1B378361FFF@opera.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<2C226A9A-E24F-49E6-8341-C1B378361FFF@opera.com>
Message-ID: <CAOKKrgOqcVg2rh-4r0Rz0g6zd4nCeBTo=bAv_k8h3=yb8EpEmQ@mail.gmail.com>

On 7/14/11, Karl Dubost <karld at opera.com> wrote:
> what about adding
>
> <a href="foo.pdf" target="_download">Save a Tree, Eat a beaver</a>
>
This seems like the best solution to me. A filename hint has two use
cases: a suggestion for a local identifier, and providing a filename
extension for systems that use them to identify file types with
incomplete or nonexistent /etc/mime.type media type mappings. I'll
only name so many pictures "pic.jpg", so I suggest using the
descriptive (and thus verbose) value of the title attribute. The worst
problem will be encoding the name on filesystems such as FAT.

<a href="//samplecdn.example/pix/2011/7/14/party/cake"
title="S?kkula?ikaka me? ?s" target="_download">Afm?liskaka m?n</a>

From ian at hixie.ch  Thu Jul 14 15:21:58 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Jul 2011 22:21:58 +0000 (UTC)
Subject: [whatwg] Styling <details>
In-Reply-To: <4D9BBA29.3040107@lachy.id.au>
References: <4D9BBA29.3040107@lachy.id.au>
Message-ID: <Pine.LNX.4.64.1107142204470.2079@ps20323.dreamhostps.com>


(This isn't the final reply on this thread, but I thought I should give a 
heads-up as to the general direction I am expecting us to go in here.)

On Wed, 6 Apr 2011, Lachlan Hunt wrote:
>
>   We've been experimenting with the styling of the details element, 
> trying to figure out the most sensible way style it.  We have tried to 
> find a solution that behaves the way authors expect, provides for easy 
> restyling by authors and avoiding the troubles associated with magic 
> styles that can't be expressed in CSS.
> 
> The rendering section of the spec is currently very inadequate and does 
> not describe accurate styles.  Also, the sample XBL binding given in the 
> XBL 2.0 draft is also inadequate for a number of reasons.

I think the long term solution here is some sort of widget definition 
binding language like XBL. I don't think it makes sense to do it purely in 
CSS. Discolsure widgets have all kinds of subtle behaviours like animation 
during disclosure, hover effects on the triangle, etc. Some systems use a 
"More..." or "Details..." button, some use a triangle, some use +/-.

On the short term, I would recommend using the 'icon' property to allow 
authors to override the icon.

I agree that what the spec says is currently inadequate, but without a 
binding language, I don't think it makes sense to spend time trying to 
improve it, since any improvement would be a stop-gap measure.

The same applies to pretty much all the other form controls.

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

From glenn at zewt.org  Thu Jul 14 15:45:35 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 14 Jul 2011 18:45:35 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAWBYDCEJcie1aiS=6syQFQxGmM6+M1NT9LsbuP2aO6AAKgQVQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
	<CAAWBYDCEJcie1aiS=6syQFQxGmM6+M1NT9LsbuP2aO6AAKgQVQ@mail.gmail.com>
Message-ID: <CABirCh-bOafsmhoXfTgU2ZuFVqt58zWjm4gxtUmqy4FR8FPmFA@mail.gmail.com>

On Thu, Jul 14, 2011 at 5:44 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

>  Optimizing for the user choosing to right-click=>Save seems like a
> much more niche case than linking to a file that should be downloaded.
>
> Plus, you could address it by just wrapping the <img> in an <a>:
>
> <a href=uglyurl.jpg download=prettyurl.jpg><img src=uglyurl.jpg></a>
>

I don't want to turn my images into links--and in some cases the images are
already links to something else, or use click for other site UI.

A similar and probably more common use case is links to files which can be
viewed usefully in the browser, and are also often saved to disk; very
frequently PDFs.  Using <a href=ugly.pdf download=pretty.pdf> would obstruct
users who want to view the link in the browser.

I don't feel very strongly about this, and download=filename is clean and
straightforward, but we should at least consider the use cases of specifying
a filename without implying C-D: attachment.

-- 
Glenn Maynard

From tantek at cs.stanford.edu  Thu Jul 14 18:24:12 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 18:24:12 -0700
Subject: [whatwg] Styling <details>
In-Reply-To: <Pine.LNX.4.64.1107142204470.2079@ps20323.dreamhostps.com>
References: <4D9BBA29.3040107@lachy.id.au>
	<Pine.LNX.4.64.1107142204470.2079@ps20323.dreamhostps.com>
Message-ID: <CAOACb=Kqj_x-sxcvfKx06qoNMwg2eRoNfUC8bWcA82qUL90buA@mail.gmail.com>

On Thu, Jul 14, 2011 at 15:21, Ian Hickson <ian at hixie.ch> wrote:
>
> (This isn't the final reply on this thread, but I thought I should give a
> heads-up as to the general direction I am expecting us to go in here.)
>
> On Wed, 6 Apr 2011, Lachlan Hunt wrote:
>>
>> ? We've been experimenting with the styling of the details element,
>> trying to figure out the most sensible way style it. ?We have tried to
>> find a solution that behaves the way authors expect, provides for easy
>> restyling by authors and avoiding the troubles associated with magic
>> styles that can't be expressed in CSS.
>>
>> The rendering section of the spec is currently very inadequate and does
>> not describe accurate styles. ?Also, the sample XBL binding given in the
>> XBL 2.0 draft is also inadequate for a number of reasons.
>
> I think the long term solution here is some sort of widget definition
> binding language like XBL. I don't think it makes sense to do it purely in
> CSS. Discolsure widgets have all kinds of subtle behaviours like animation
> during disclosure, hover effects on the triangle, etc. Some systems use a
> "More..." or "Details..." button, some use a triangle, some use +/-.
>
> On the short term, I would recommend using the 'icon' property to allow
> authors to override the icon.

Agreed.

FYI: http://dev.w3.org/csswg/css3-ui/#icon

Feel free to follow-up feedback on that to www-style at w3.org.

> I agree that what the spec says is currently inadequate, but without a
> binding language, I don't think it makes sense to spend time trying to
> improve it, since any improvement would be a stop-gap measure.
>
> The same applies to pretty much all the other form controls.

Also agreed.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From tantek at cs.stanford.edu  Thu Jul 14 19:17:07 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 19:17:07 -0700
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
	<CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>
Message-ID: <CAOACb=+KUk8fa9P8Zx_WSwoT-rfDth05-1pcFiET8WnS6-24Yw@mail.gmail.com>

On Thu, Jul 14, 2011 at 14:51, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
>>> Some in the microformats community have been making good use of the
>>> <time> element, e.g. for publishing hCalendar, and implementing
>>> consuming/converting hCalendar [1] with good success.
>>> [1] http://microformats.org/wiki/h2vx#HTML5_support
>>>
>>> It would be great if the <time> element could support expressing
>>> durations as well for the use cases as needed by the hMedia and hAudio
>>> microformats as well as other use-cases (Wikipedia, IMDB).
>>>
>>> Simple proposal, examples, faq, discussion (please contribute)
>>>
>>> http://wiki.whatwg.org/wiki/Time_element#duration
>>
>> I haven't studied the above yet, but I just wanted to bring up a trial
>> balloon for a possible alternative solution: drop <time> and replace it
>> with a generic solution.
>>
>> There are several use cases for <time>:
>>
>> A. Easier styling of dates and times from CSS.
>>
>> B. A way to mark up the publication date/time for an article (e.g. for
>> conversion to Atom).
>>
>> C. A way to mark up machine-readable times and dates for use in
>> Microformats or microdata.
>>
>> Use cases A and B do not seem to have much traction.


Use case A hasn't been a priority for anyone in the CSSWG no.

However, use case B is being incrementally adopted, both as specified
for pubdate, e.g.:
* https://singpolyma.net/blog/
* http://adactio.com/journal/

and using <time> with the hAtom microformat in particular rather than
pubdate (thus avoiding DRY violations with the help of the
microformats value class pattern)
* http://tantek.com/

There's probably more out there - but there are a few real world
example you can try out.


>> Use case C applies to more than just dates, and the lack of solution for
>> stuff outside dates and times is being problematic to many communities.

True. However the primary real-world use case of C has been hCalendar events.
Publishing example at http://tantek.com/
And consuming/parsing implementation: http://dev.h2vx.com/ics/

I'd say use cases "more than just dates" require open documentation on
a public wiki, otherwise we're designing from "theoretical needs"
which are pretty low priority IIRC.


>> Proposal: we dump use cases A and B, and pivot <time> on use case C,
>> changing it to <data> and making it like the <abbr> for machine-readable
>> data, primarily for use by Microformats and HTML's microdata feature.
>
> I'm fine with this,

I'm not and I think it's a mistake because <data> (and the <abbr>
pattern before that when liberally applied) leads to encouraging lazy
double-encoding of data which is a DRY violation (and thus bad for
{meta}data accuracy/quality over time).

Instead I think the <time> element approach is correct.

First prove the need for double-encoding on a case by case basis, and
then create an element for each proven data-type use-case.

E.g. next on this list IMHO would be a  <number> element for example,
since it's clear from some of the examples where quantities or numbers
are involved - e.g. the hReview-aggregate microformat, that publishers
use human/locale/design-specific numbers

e.g.
<number value="10000">10,000</number>
<number value="10000">10.000</number>
<number value="10000">10k</number>

etc.

Obvious FAQ:

"Won't we end up with a billion new tags?" (actual expression from
IRC, not deliberate strawman)

No we won't.

No matter how you slice it there will be a very limited number of
specific data types that require dual representation (evidence: all
existing schema languages have a small fixed number of atomic scalar
types).

I would be surprised if more than half dozen or so data-type-specific
elements were added ever for this, I could be mistaken, but I'd rather
be proven wrong by evidence demonstrating 5-6 are not enough, than
overgeneralizing now.


> but as I expressed when this was discussed
> earlier, I think this should be more explicitly aimed at Microdata,
> with something like <itemdata @itemprop @data>...</itemdata>.
> This makes it less immediately applicable to Microformats...

A @data *global* attribute would work equally well for Microdata,
microformats, and RDFa, and yes would be preferred over a <data>
element, so no need to worry there.


> but in my
> opinion Microformats should switch to using Microdata as their
> embedding syntax, as that would solve their "you have to write a
> custom parser for each vocab" problem.

Simpler and more incremental (based on existing practice) solution to
the customize-parser-per-microformat-problem already under way here:

http://microformats.org/wiki/microformats-2

Certainly not as fully specified as microdata yet, but I expect all
the same RDF/JSON generation algorithms will work - and the syntax
will be simpler for typical developers and typical web pages.


> (I want to address usecase A at some point, but it's a complicated
> problem that I don't have anywhere near the bandwidth for. ?It doesn't
> necessarily require <time>, though - <itemdata> would work just fine
> if CSS specified a particular date format that the data had to be in.)

Agreed on all counts. I proposed a language/locale specific
"date-style" property (akin to "list-style-type") in a CSS WG meeting
years ago (2003 or 2004 I think) but it didn't generate sufficient
interest at the time (nor since).

Thanks,

Tantek
-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

From brucel at opera.com  Fri Jul 15 01:07:32 2011
From: brucel at opera.com (Bruce Lawson)
Date: Fri, 15 Jul 2011 09:07:32 +0100
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <CAOACb=+KUk8fa9P8Zx_WSwoT-rfDth05-1pcFiET8WnS6-24Yw@mail.gmail.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
	<CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>
	<CAOACb=+KUk8fa9P8Zx_WSwoT-rfDth05-1pcFiET8WnS6-24Yw@mail.gmail.com>
Message-ID: <op.vynh6uveh8on37@bruce-pc>

On Fri, 15 Jul 2011 03:17:07 +0100, Tantek ?elik <tantek at cs.stanford.edu>  
wrote:

> On Thu, Jul 14, 2011 at 14:51, Tab Atkins Jr. <jackalmage at gmail.com>  
> wrote:
>> On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:

>>>
>>> I haven't studied the above yet, but I just wanted to bring up a trial
>>> balloon for a possible alternative solution: drop <time> and replace it
>>> with a generic solution.
>>>
>>> There are several use cases for <time>:
>>>
>>> A. Easier styling of dates and times from CSS.
>>>
>>> B. A way to mark up the publication date/time for an article (e.g. for
>>> conversion to Atom).
>>>
>>> C. A way to mark up machine-readable times and dates for use in
>>> Microformats or microdata.
>>>
>>> Use cases A and B do not seem to have much traction.

I think it's too early to tell whether there is "traction". I wonder  
whether any of the new semantics (article, nav, section, header etc) have  
much traction yet, simply because they don't yet have many obvious  
"consumers" - eg, browsers, crawlers, search engines [as far as we know]  
aren't making use of them yet. Also, developers are still understandably  
getting used to the more whizzbang aspects of HTML like canvas, video etc.

>
>>> Proposal: we dump use cases A and B, and pivot <time> on use case C,
>>> changing it to <data> and making it like the <abbr> for  
>>> machine-readable
>>> data, primarily for use by Microformats and HTML's microdata feature.

I disagree.

Opera has just begun to support <time> in Opera 11.50 (demo  
http://people.opera.com/miket/2011/5/time.html) [Disclosure: Opera is my  
employer but I'm speaking for myself here, not representing them].

We're seeing <time> used "In the wild", for example on recipes  
http://www.jennybristow.com/category/recipes/, reddit  
http://www.reddit.com/ ("submitted 5 hours ago"), http://smashsummit.com/,  
the default 2011 WordPress theme  
http://theme.wordpress.com/themes/twentyeleven/ and consequently many  
WordPress blogs

We also see schema.org encouraging the use of <time>  
http://schema.org/docs/gs.html#advanced_dates and given the importance of  
Bing, Yahoo and Google it;s fair to assume that web developers will adopt  
these patterns.

In my opinion, rather than dump <time>, we should consider changing the  
spec so the schema.org use-cases such as time periods

<time itemprop="cookTime" datetime="PT1H30M">1 1/2 hrs</time>

and "fuzzy" dates like 2011-11 for November 2011 are acceptable: there  
have been previous mails to the WG from wikipedia authors, genealogists  
and those working on museum websites stating that the utility of the  
current <time> element is diminished because of the requirement for  
precise dates which isn't always possible for historians.


-- 
Hang loose and stay groovy,

Bruce Lawson
www.brucelawson.co.uk (personal)
www.twitter.com/brucel

From julian.reschke at gmx.de  Fri Jul 15 01:08:48 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 15 Jul 2011 10:08:48 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CA+c2ei9sYhpzvMMK+nSxaLByvromXVQzCeD1so8zJ3CGRKjLUw@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de>
	<op.vylecs0564w2qv@annevk-macbookpro.local>
	<CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
	<4E1EA5D2.4060702@gmx.de>
	<CA+c2ei9sYhpzvMMK+nSxaLByvromXVQzCeD1so8zJ3CGRKjLUw@mail.gmail.com>
Message-ID: <4E1FF590.4070403@gmx.de>

On 2011-07-14 17:01, Jonas Sicking wrote:
> ...
> True. I would be fine with removing the plugin requirement. Or
> changing it such that it states that plugins can only be loaded if
> it's done in a manner that ensures that all other requirements are
> still fulfilled. Or just dealing with this once there actually are
> plugins and plugin APIs which could be loaded while still fulfilling
> the other requirements.
> ...

Well, the spec is in W3C LC. So if we think this requirement needs to be 
rephrased then it should be brought up as a problem.

Best regards, Julian

From jkorpela at cs.tut.fi  Fri Jul 15 07:50:00 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Fri, 15 Jul 2011 17:50:00 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1EEAAE.3050701@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
Message-ID: <4E205398.9000905@cs.tut.fi>

14.07.2011 16:10, Bjartur Thorlacius wrote:

> ?ann fim 14.j?l 2011 11:09, skrifa?i Jukka K. Korpela:
>> 14.07.2011 13:49, Karl Dubost wrote:
>>> <blockquote cite="urn:isbn:978-2-07-07533-7">
>>> <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
>>> <p>?<q>M?me si l'on vient me chercher<br/>
>>> Comment, abandonnant la ros?e<br/>
>>> De pareil lotus,<br/>
>>> Retournerai-je<br/>
>>> Dans le monde changeant et frivole ?</q> ?</p>
>>> <p>et j'envoyais ce p?tale.</p>
>>> <p class="source">
>>> <cite class="auteur">Shonagon, Sei</cite>,
>>> <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
>>> </blockquote>
> Yes, but for usability reasons the cite[@class=titre] should represent a
> hyperlink to the cited book.

Should it? Even when the book has no URL? If you expect urn:isbn:? to 
work anytime soon in any significant browser, you?re very optimistic.

Browsers currently treat <cite> just like <i> (except that it has a 
different name). There is no sign of advance functionality emerging. It 
does not matter how usable something is when it does not exist at all.

> Is an user agent to find a cite descendant
> of <blockquote> and make it represent a hyperlink to the cited resource
> (identified by the URI in the cite attribute of blockquote)?

That would be rather pointless.

If there is an online resource to link to, you can simply make the title 
a link to it, explicitly. Then you can also style the link to desired, 
and it will stand out as a link (unless the author styles it badly).

I forgot to mention that the ISBN number should be included visibly in 
the credits, especially because it is usually the simplest and sometimes 
the only reasonable way to identify a book unambiguously (and can be 
copied and pasted into a suitable bibliographic search form). It?s 
metadata, but metadata that need not and should not be hidden but 
presented in textual content. At most it might be included into elements 
that are not initially displayed but become available when the user so 
requests?possibly some day via the <details> element if browsers 
implement it well.

The cite attribute in <blockquote> should really be moved to the 
non-recommended part of HTML. It hardly ever serves a useful purpose, 
and it tends to mislead authors into including important information 
_only_ in the attribute, which has no browser support worth mentioning 
(despite having been in HTML for over 13 years).

>> (I don't like to nitpick on the author identification, but wouldn?t
>> <cite class="auteur" lang="jp-Latn">Sh?nagon, Sei</cite> be better?)
> I don't think author names are allowed in <cite> in HTML 5.

They aren?t, but HTML5 linters (?validators?) won?t report the issue, as 
they don?t understand the meanings of words.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From ap at webkit.org  Fri Jul 15 09:08:57 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 15 Jul 2011 09:08:57 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
Message-ID: <397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>


14.07.2011, ? 13:59, Tab Atkins Jr. ???????(?):

>> re-using the "enclosure" term from the Atom format (thus minimal bikeshedding)
> 
> "enclosure" is a completely opaque name.  I have no idea how it is
> meant to refer to "download the linked resource instead of navigating
> to it".  If I think about it in terms of Atom I can *kinda* imagine
> it, but it feels like a bad term there, and it would be an even worse
> term in HTML.
> 
> A boolean @download attribute is much clearer and more direct.  If
> you're using @download to name the file as well, then adding a @rel
> value is unneeded.


What meaning will this attribute have on a platform that simply doesn't expose the notion of a file?

I think that this attribute could be quite confusing, and it will likely become more confusing with time, as more platforms arise that have creative ways of presenting data to users. 

It also doesn't naturally help understanding that it's just poor man's Content-Disposition:attachment. From this point of view, I like Ian's original proposal (rel=attachment) more.

- WBR, Alexey Proskuryakov


From svartman95 at gmail.com  Fri Jul 15 09:44:04 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Fri, 15 Jul 2011 16:44:04 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E205398.9000905@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
Message-ID: <CAOKKrgOwzOYGPLfCDGD9z9TDeUpEs2zLL60j3pDi+05rG7JymA@mail.gmail.com>

On 7/15/11, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 14.07.2011 16:10, Bjartur Thorlacius wrote:
>> I don't think author names are allowed in <cite> in HTML 5.
>
> They aren?t, but HTML5 linters (?validators?) won?t report the issue, as
> they don?t understand the meanings of words.
That doesn't make it any more valid.

From svartman95 at gmail.com  Fri Jul 15 09:56:10 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Fri, 15 Jul 2011 16:56:10 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E205398.9000905@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
Message-ID: <CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>

On 7/15/11, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> Should it? Even when the book has no URL? If you expect urn:isbn:? to
> work anytime soon in any significant browser, you?re very optimistic.
>
Wikipedia and Amazon (among others) have all the mechanisms already.
Such ISBN handlers could even be registered by JavaScripts.

> Browsers currently treat <cite> just like <i> (except that it has a
> different name). There is no sign of advance functionality emerging. It
> does not matter how usable something is when it does not exist at all.
>
<Cite> is not nearly as useful as @cite.

> I forgot to mention that the ISBN number should be included visibly in
> the credits, especially because it is usually the simplest and sometimes
> the only reasonable way to identify a book unambiguously (and can be
> copied and pasted into a suitable bibliographic search form). It?s
So you're saying that users should rather search for the term ISBN,
select the following number, copy it, remove/add hyphens as necessary
and then paste it to a suitable bibliographic search form? Instead of
registering a suitable bibliographic search form once, and having the
user agent do the hard work in a click or two?

> metadata, but metadata that need not and should not be hidden but
> presented in textual content. At most it might be included into elements
> that are not initially displayed but become available when the user so
> requests?possibly some day via the <details> element if browsers
> implement it well.
>
But browsers need to be told that that number close to the quotation
is an ISBN. And if you always hide it in <details>, user agents may be
compelled to expand it by default, making it unusable for e.g. hiding
answers to a quiz.

> The cite attribute in <blockquote> should really be moved to the
> non-recommended part of HTML. It hardly ever serves a useful purpose,
> and it tends to mislead authors into including important information
> _only_ in the attribute, which has no browser support worth mentioning
> (despite having been in HTML for over 13 years).
>
Before you said <cite> was implemented as <i>, and your point is that
the cite attribute is useless? They're barely related, @cite contains
an URI, that an user agent might be able to use in an automated
fashion. <Cite> contains a human-readable name of a work. That'll
rarely be machine-readable.

From ifette at google.com  Fri Jul 15 10:05:53 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 10:05:53 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
Message-ID: <CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>

On Fri, Jul 15, 2011 at 9:08 AM, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> 14.07.2011, ? 13:59, Tab Atkins Jr. ???????(?):
>
> >> re-using the "enclosure" term from the Atom format (thus minimal
> bikeshedding)
> >
> > "enclosure" is a completely opaque name.  I have no idea how it is
> > meant to refer to "download the linked resource instead of navigating
> > to it".  If I think about it in terms of Atom I can *kinda* imagine
> > it, but it feels like a bad term there, and it would be an even worse
> > term in HTML.
> >
> > A boolean @download attribute is much clearer and more direct.  If
> > you're using @download to name the file as well, then adding a @rel
> > value is unneeded.
>
>
> What meaning will this attribute have on a platform that simply doesn't
> expose the notion of a file?
>

I would assume the platform would treat <a href="blah.php?id=123"
download="blah.pdf"> the same way as if it had followed a link to blah.php
and received a Content-Disposition: attachment; filename=blah.pdf header.
It's not introducing any new problems, and I would expect the behaviour to
be consistent.


>
> I think that this attribute could be quite confusing, and it will likely
> become more confusing with time, as more platforms arise that have creative
> ways of presenting data to users.
>
>
I agree we don't want to prevent creative UI in the future / platforms that
don't necessarily deal with files in the traditional way. However I don't
think this actually introduces any new problems, it just allows something
that can already be specified in server-side code to be specified in
client-side code.


> It also doesn't naturally help understanding that it's just poor man's
> Content-Disposition:attachment. From this point of view, I like Ian's
> original proposal (rel=attachment) more.
>

Yes and no - both are sort of a poor man's Content-Disposition :) The
question is whether we need to handle filename, and the proposal of
download=filename at least maps content-disposition fully and compactly.


>
> - WBR, Alexey Proskuryakov
>
>

From shwetankd at opera.com  Fri Jul 15 10:55:55 2011
From: shwetankd at opera.com (Shwetank Dixit)
Date: Fri, 15 Jul 2011 23:25:55 +0530
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
 and other feedback
In-Reply-To: <CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
	<op.vylop7byim6vpa@shwetank-dixits-macbook.local>
	<CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>
Message-ID: <op.vyn9fc1qim6vpa@shwetank-dixits-macbook.local>

On Thu, 14 Jul 2011 18:53:00 +0530, timeless <timeless at gmail.com> wrote:

> I'd expect a web app to have no idea about device camera
> specifications and thus to not be able to properly specify a flash
> duration. I don't see how such a thing is valuable.
>
> If a user is in a movie theater, or a museum, it's quite likely they
> won't notice a web app is forcing a flash. Let the user control flash
> through a useragent only or host application only mode. I believe the
> hazards of exposing flash duration outweigh any benefits. The only
> application class I know of built using control of camera flash is
> "flash-light", and that's both a hack and not guaranteed to be
> workable for all possible flash technologies.

Just like, just allowing the web app to use the camera as it is will not  
make sense, and presumably, user agents will implement a authorization by  
the user before the app gains access to the camera (something like 'This  
application requests access to the camera. Allow for now/Always  
Allow/Never Allow/Close' just like you do in geolocation right now) ...  
just like that, you could do it for flash, where the app only gains access  
to it if the user allows it. If that is the implementation, i do not think  
there would be much hazards in allowing flash access.

Apart from helping capture images/video in low light conditions, there are  
a few other use cases for flash such as the flash light thing you  
mentioned, as well as a possible S.O.S type app.

I'm fine if the consensus is that the device/user agent will handle the  
issue of flash by showing some sort of control where the user can click  
between 'flash on/off/auto'. That will cover *most* of the use cases,  
which is recording images/video in low light conditions. If so, then it  
might be good to specify that somewhere in the spec just to make things a  
bit clearer?

>
> On 7/14/11, Shwetank Dixit <shwetankd at opera.com> wrote:
>> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
>>
>>>
>>>> Another question is flash. As far as I have seen, there seems to be no
>>>> option to specify whether the camera needs to use flash or not. Is  
>>>> this
>>>> decision left up to the device? (If someone is making an app which is
>>>> just clicking a picture of the person, then it would be nice to have  
>>>> the
>>>> camera use flash in low light conditions).
>>> getUserMedia() returns a video stream, so it wouldn't use a flash.
>>
>> Wouldn't it make sense to have a provision for flash separately then? I
>> think a lot of apps would like just a picture instead of video, and in
>> those cases, flash would be required. Maybe a seperate provision in the
>> spec which defines whether to use flash, and if so, for how many
>> miliseconds. Is that doable?
>> --
>> Shwetank Dixit
>> Web Evangelist,
>> Site Compatibility / Developer Relations / Core Engineering Group
>> Member - W3C Mobile Web for Social Development (MW4D) Group
>> Member - Web Standards Project (WaSP) - International Liaison Group
>> Opera Software - www.opera.com
>>
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>
>


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/

From glenn at zewt.org  Fri Jul 15 11:24:05 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 15 Jul 2011 14:24:05 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
Message-ID: <CABirCh8kc6Pup-BMYDvKbowwpq=Otp3Xh2v0SN+8YYqOu54Q1A@mail.gmail.com>

2011/7/15 Ian Fette (????????) <ifette at google.com>

> Yes and no - both are sort of a poor man's Content-Disposition :) The
> question is whether we need to handle filename, and the proposal of
> download=filename at least maps content-disposition fully and compactly.
>

Not fully; it lacks an equivalent for "Content-Disposition: inline;
filename=file".

-- 
Glenn Maynard

From ian at hixie.ch  Fri Jul 15 11:34:07 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 18:34:07 +0000 (UTC)
Subject: [whatwg] Geolocation - Browser usability issues with regards to
 asking user permission
In-Reply-To: <4D9F03D5.6020407@opera.com>
References: <BANLkTik3cvtph_w0hJ9GqYWj-kXpUBBhKQ@mail.gmail.com>
	<BANLkTimh8OKy6GK7YMT1yYpm=M0UPdvG7A@mail.gmail.com>
	<4D9F03D5.6020407@opera.com>
Message-ID: <Pine.LNX.4.64.1107142232160.2079@ps20323.dreamhostps.com>

On Wed, 6 Apr 2011, Andrew de Andrade wrote:
>
> Depending on the browser and device, permission will be asked either in 
> a bar across the top of the browser (Firefox and Chrome on the desktop) 
> or with a modal dialog (Safari on the desktop and on the iPhone). [...]
> 
> As the creator of a site that uses geolocation, these two different 
> implementations of the permissions dialog concerns me. In my tests with 
> users, I've noticed that with Firefox and Chrome, many users don't 
> notice the bar across the top and thus features of the web application 
> end up crippled because the app doesn't have access to the user's 
> location and this degrades the user experience.

As with all user interface choices browser vendors have to make, some work 
better than others. Different goals can result in different choices, too; 
for example, it might be the goal of one user agent to make it clear to 
the user that they should share their location, while another user agent 
might decide that it's better to the user have to explicitly look for a 
way to share their location, since then they won't do it by mistake.


> [Proposal:]
> 2) The HTML5 specification defines how browsers should implement this 
> consistently --> either a bar across the top OR modal dialog box, but 
> not both.

It's user interface: we're not going to specify it. This is the kind of 
thing browsers can compete on.

In any case, it's impractical: If we said it should be a non-modal 
graphical bar, how would a browser that doesn't have a screen but instead 
reads everything out using speech synthesis do it? If we said it had to be 
a red icon, what about browsers targeting cultures where the colour "red" 
is considered offensive? If we said that the user agent should offer the 
option to give the user's location or no location, what about users that 
want to lie about their location? There are just too many possible 
variables here to define the UI, even if we wanted to.


> 3) Each browser chooses their default interface approach (bar or modal 
> dialog), but the Geolocation API specification allows for the webapp 
> developer to override this default.

This doesn't work because those options might not be available in the 
first place. What if the operating system the browser is running on 
doesn't have the concept of a modal dialog? What if it's a line-driven 
text browser, with no concept of a non-modal alert?


> Those apps for which location is essencial for the user experience can 
> choose to always display a modal dialog box before the user proceeds to 
> use the webapp.

What if the user never wants a dialog?


On Wed, 6 Apr 2011, Peter Kasting wrote:
> 
> If users don't notice or understand the geolocation prompts in a 
> particular browser, I think the appropriate response is to provide 
> feedback to the browser vendor that users are not successfully 
> navigating their UI.

Indeed.


On Fri, 8 Apr 2011, Rich Tibbett wrote:
> Biju wrote:
> > What I want from browser vendors is make 
> > navigator.geolocation.getCurrentPosition and 
> > navigator.geolocation.watchPosition ONLY callable from a CLICK event. 
> > I thought we all learned lesson from window.open popups
> 
> window.open is still entirely underspecified in standards when it comes 
> to its behavior in trusted vs. non-trusted click event invocation. The 
> first thing somebody would need to is document how window.open works 
> according to different modes of invocation. Then at least we would have 
> a model to be able to discuss for other similar scenarios.

The HTML spec defines this, but in a somewhat wishy-washy way intended to 
allow UAs to experiment with different constraints. Is this something that 
needs defining more precisely?

In general I haven't specified this in detail because the model of 
trusting user clicks doesn't work (due to clickjacking attacks).

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

From jonas at sicking.cc  Fri Jul 15 11:39:15 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Jul 2011 11:39:15 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>:
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the
> server.*(A related example is offline apps, which may wish to provide
> the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
> After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.

We've discussed a different solution to the same problem at mozilla.
The solution we discussed was allowing FileSaver to in addition to
taking a blob argument, allow it to take a url argument.

One concern which was brought up was the ability to cause the user to
download a file from a third party site. I.e. this would allow
evil.com to trick the user into downloading an email from the users
webmail, or download a page from their bank which contains all their
banking information. It might be easier to then trick the user into
re-uploading the saved file to evil.com since from a user's
perspective, it looked like the file came from evil.com

Another possible attack goes something like:
1. evil.com tricks the user into downloading sensitive data from bank.com
2. evil.com then asks the user to download a html from evil.com and
open the newly downloaded file
3. the html file contains script which reads the contents from the
file downloaded from bank.com and sends it back to evil.com

Step 1 and 2 require the user to answer "yes" to a dialog displayed by
the browser. However it's well known that users very often hit
whichever button they suspect will make the dialog go away, rather
than actually read the contents of the dialog.
Step 3 again requires the user to answer "yes" to a dialog displayed
by the browser in at least some browsers. Same caveat applies though.

One very simple remedy to this would be to require CORS opt-in for
cross-site downloads. For same-site downloads no special opt-in would
be required of course.

It's also possible that it would be ok to do this without any opt-ins
since there are a good number of actions that the user has to take in
all these scenarios. Definitely something that I'd be ok with
discussing with our security team.

Tentatively I would feel safer with the CORS option though. And again,
for same-site downloads this isn't a problem at all, but I suspect
that in many cases the file to be downloaded is hosted on a separate
server.

Oh, and I don't have strong opinions at this time on if rel=attachment
or FileSaver or both should be the way to trigger this functionality.

/ Jonas

From ifette at google.com  Fri Jul 15 11:40:27 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 11:40:27 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh8kc6Pup-BMYDvKbowwpq=Otp3Xh2v0SN+8YYqOu54Q1A@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
	<CABirCh8kc6Pup-BMYDvKbowwpq=Otp3Xh2v0SN+8YYqOu54Q1A@mail.gmail.com>
Message-ID: <CAF4kx8cDgGevMoXXCiyvTMsg26Gy_T6fTbBmjL+n=X9-U+bQbw@mail.gmail.com>

On Fri, Jul 15, 2011 at 11:24 AM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/15 Ian Fette (????????) <ifette at google.com>
>
> Yes and no - both are sort of a poor man's Content-Disposition :) The
>> question is whether we need to handle filename, and the proposal of
>> download=filename at least maps content-disposition fully and compactly.
>>
>
> Not fully; it lacks an equivalent for "Content-Disposition: inline;
> filename=file".
>
>
Ok, not fully, but at least covering what I would view to be the important
use cases that are actually used in practice.


> --
> Glenn Maynard
>
>

From ian at hixie.ch  Fri Jul 15 11:43:25 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 18:43:25 +0000 (UTC)
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
 algorithm
In-Reply-To: <BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>

On Fri, 8 Apr 2011, Tab Atkins Jr. wrote:
>
> In the legacy color parsing algorithm 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value>, 
> steps 5 and 6 concern CSS color names - 'transparent' should raise an 
> error, and color names should be respected.  All other CSS color 
> syntaxes, though, such as the rgba() function, are just passed through 
> to the rest of the algorithm and appropriately mangled.
> 
> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we just 
> try to parse it as a CSS color.  If we succeed, we use that color.  
> Otherwise, we chunk it into the legacy parsing algorithm and do what the 
> spec says.  So, for example, <font color=rgba(255,0,0,.5)>foo</font> is 
> actually displayed as partially-transparent red instead of dark green 
> (following the algorithm mangles the string into #050).
> 
> Could we change those two steps to just say "If keyword is a valid CSS 
> color value, then return the simple color corresponding to that value."?  
> (I guess, to fully match Webkit, you need to change the definition of 
> "simple color" to take alpha into account.)

On Fri, 8 Apr 2011, Boris Zbarsky wrote:
> 
> But it does match other UAs....
> 
> Do you have web compat data here?
> 
> I would much rather stick with color parsing as defined in HTML4 modulo 
> the "not a color name, treat it as a hex color even if it doesn't start 
> with '#'" quirk than replace the "is it a color name?" test with a "does 
> it parse as a CSS color?" test.

On Wed, 13 Apr 2011, Philip Taylor wrote:
> 
> I don't know if this is relevant or useful but anyway: 
> http://philip.html5.org/data/font-colors.txt has some basic data for 
> <font color> values, http://philip.html5.org/data/bgcolors.txt for <body 
> bgcolor>. (Each line is the number of URLs that value was found on (from 
> the set from http://philip.html5.org/data/dotbot-20090424.txt), followed 
> by the XML-encoded value.)

Looks like there are values that would be affected by this change.

I've left it as-is. I think compat here is vastly more important than 
adding new capabilities, since this is only used for legacy features.

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

From jackalmage at gmail.com  Fri Jul 15 11:51:53 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 15 Jul 2011 11:51:53 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
	algorithm
In-Reply-To: <Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
	<Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>

On Fri, Jul 15, 2011 at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 8 Apr 2011, Tab Atkins Jr. wrote:
>> In the legacy color parsing algorithm
>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value>,
>> steps 5 and 6 concern CSS color names - 'transparent' should raise an
>> error, and color names should be respected. ?All other CSS color
>> syntaxes, though, such as the rgba() function, are just passed through
>> to the rest of the algorithm and appropriately mangled.
>>
>> This doesn't match Webkit's behavior. ?Instead of steps 5 and 6, we just
>> try to parse it as a CSS color. ?If we succeed, we use that color.
>> Otherwise, we chunk it into the legacy parsing algorithm and do what the
>> spec says. ?So, for example, <font color=rgba(255,0,0,.5)>foo</font> is
>> actually displayed as partially-transparent red instead of dark green
>> (following the algorithm mangles the string into #050).
>>
>> Could we change those two steps to just say "If keyword is a valid CSS
>> color value, then return the simple color corresponding to that value."?
>> (I guess, to fully match Webkit, you need to change the definition of
>> "simple color" to take alpha into account.)
>
> On Fri, 8 Apr 2011, Boris Zbarsky wrote:
>>
>> But it does match other UAs....
>>
>> Do you have web compat data here?
>>
>> I would much rather stick with color parsing as defined in HTML4 modulo
>> the "not a color name, treat it as a hex color even if it doesn't start
>> with '#'" quirk than replace the "is it a color name?" test with a "does
>> it parse as a CSS color?" test.
>
> On Wed, 13 Apr 2011, Philip Taylor wrote:
>>
>> I don't know if this is relevant or useful but anyway:
>> http://philip.html5.org/data/font-colors.txt has some basic data for
>> <font color> values, http://philip.html5.org/data/bgcolors.txt for <body
>> bgcolor>. (Each line is the number of URLs that value was found on (from
>> the set from http://philip.html5.org/data/dotbot-20090424.txt), followed
>> by the XML-encoded value.)
>
> Looks like there are values that would be affected by this change.
>
> I've left it as-is. I think compat here is vastly more important than
> adding new capabilities, since this is only used for legacy features.

I recently patched WebKit to match the spec anyway, so that's fine.  ^_^

I'll note, though, that the spec algorithm seems to be Firefox's
behavior, which differs in a few significant points from IE's.  In
particular, IE doesn't strip whitespace from the color, doesn't have
the same "truncate at 128 bytes" behavior, and doesn't recognize a
3-digit hex color as a CSS color (instead parsing it with legacy
rules).

I doubt it matters too much, but was there any particular reason you
went with Firefox over IE here?

~TJ

From dbaron at dbaron.org  Fri Jul 15 11:57:18 2011
From: dbaron at dbaron.org (L. David Baron)
Date: Fri, 15 Jul 2011 11:57:18 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
 algorithm
In-Reply-To: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
Message-ID: <20110715185718.GA23248@pickering.dbaron.org>

On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote:
> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we
> just try to parse it as a CSS color.

As I pointed out in
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html
this isn't compatible with doing the following simultaneously:
 * using the algorithm given, which converts the values to colors at
   parse time
 * correctly handling dynamic changes of system appearance for the
   system color values

Correctly handling dynamic changes of system appearance here would
be a significant amount of work even if the algorithm here changed,
and I'd really rather not add that support for a legacy feature, nor
would I like to have an inconsistency between CSS and HTML as to
whether system colors are dynamically updated.

-David

-- 
?   L. David Baron                         http://dbaron.org/   ?
?   Mozilla Corporation               http://www.mozilla.com/   ?

From ifette at google.com  Fri Jul 15 11:58:35 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 11:58:35 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
Message-ID: <CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>

2011/7/15 Jonas Sicking <jonas at sicking.cc>

> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> > page author to have control over the response headers sent by the
> > server.*(A related example is offline apps, which may wish to provide
> > the user with
> > a way to "download" a file stored locally using the filesystem API but
> again
> > can't set any headers.) It would be nice to provide the page author with
> a
> > client side mechanism to trigger a download.
> >
> > After mulling this over with some application developers who are trying
> to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
> We've discussed a different solution to the same problem at mozilla.
> The solution we discussed was allowing FileSaver to in addition to
> taking a blob argument, allow it to take a url argument.
>
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com
>
> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file
> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com
>
> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.
> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.
>
> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.
>
> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.
>
> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.
>
> Oh, and I don't have strong opinions at this time on if rel=attachment
> or FileSaver or both should be the way to trigger this functionality.
>
> / Jonas
>

I agree FileSaver is useful and has its place, but I don't think it negates
the need for something like rel=attachment or download=filename. For one,
FileSaver currently operates on blobs and as you mention would have to be
modified to handle URLs or streams more generally. Second, it would force
developers to use javascript links and/or set up click listeners and so
forth, which could be annoying for users (losing the ability to copy the URL
etc).

I don't understand why we would add CORS as a requirement for this. You can
already link to things from another origin, the fact that they may be
downloaded rather than displayed and then the user somehow tricked to upload
them seems like a rather remote concern...  if I now want to link to a
StarCraft 2 patch and give the browser a hint that it's a download (so that
maybe in the future the browser might be able to have more intelligent UI
when I hover over it, or at least not pop up a new window that just then
spawns a download) requiring CORS seems quite overkill, especially if the
response would have triggered a download anyways.

I guess the interesting question is "If the response would not have
otherwise triggered a download, and the request is cross-origin, should that
require CORS" and personally I would say no, this is still a remote enough
concern that I would not worry about it.

-Ian

From jackalmage at gmail.com  Fri Jul 15 12:01:40 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 15 Jul 2011 12:01:40 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
	algorithm
In-Reply-To: <20110715185718.GA23248@pickering.dbaron.org>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<20110715185718.GA23248@pickering.dbaron.org>
Message-ID: <CAAWBYDDrj6uUJz5rBr+4fxPtmozfAZEiM9fqb6Ld0rQorbcBgw@mail.gmail.com>

On Fri, Jul 15, 2011 at 11:57 AM, L. David Baron <dbaron at dbaron.org> wrote:
> On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote:
>> This doesn't match Webkit's behavior. ?Instead of steps 5 and 6, we
>> just try to parse it as a CSS color.
>
> As I pointed out in
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html
> this isn't compatible with doing the following simultaneously:
> ?* using the algorithm given, which converts the values to colors at
> ? parse time
> ?* correctly handling dynamic changes of system appearance for the
> ? system color values
>
> Correctly handling dynamic changes of system appearance here would
> be a significant amount of work even if the algorithm here changed,
> and I'd really rather not add that support for a legacy feature, nor
> would I like to have an inconsistency between CSS and HTML as to
> whether system colors are dynamically updated.

WebKit now matches the spec (and Firefox) anyway, so the issue is moot.

~TJ

From jonas at sicking.cc  Fri Jul 15 13:09:17 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Jul 2011 13:09:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
Message-ID: <CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>

2011/7/15 Ian Fette (????????) <ifette at google.com>:
> 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>
>> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
>> > Many websites wish to offer a file for download, even though it could
>> > potentially be viewed inline (take images, PDFs, or word documents as an
>> > example). Traditionally the only way to achieve this is to set a
>> > content-disposition header. *However, sometimes it is not possible for
>> the
>> > page author to have control over the response headers sent by the
>> > server.*(A related example is offline apps, which may wish to provide
>> > the user with
>> > a way to "download" a file stored locally using the filesystem API but
>> again
>> > can't set any headers.) It would be nice to provide the page author with
>> a
>> > client side mechanism to trigger a download.
>> >
>> > After mulling this over with some application developers who are trying
>> to
>> > use this functionality, it seems like adding a "rel" attribute to the <a>
>> > tag would be a straightforward, minimally invasive way to address this
>> use
>> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
>> > should treat this link as if the response came with a
>> content-disposition:
>> > attachment header, and offer to download/save the file for the user.
>>
>> We've discussed a different solution to the same problem at mozilla.
>> The solution we discussed was allowing FileSaver to in addition to
>> taking a blob argument, allow it to take a url argument.
>>
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party site. I.e. this would allow
>> evil.com to trick the user into downloading an email from the users
>> webmail, or download a page from their bank which contains all their
>> banking information. It might be easier to then trick the user into
>> re-uploading the saved file to evil.com since from a user's
>> perspective, it looked like the file came from evil.com
>>
>> Another possible attack goes something like:
>> 1. evil.com tricks the user into downloading sensitive data from bank.com
>> 2. evil.com then asks the user to download a html from evil.com and
>> open the newly downloaded file
>> 3. the html file contains script which reads the contents from the
>> file downloaded from bank.com and sends it back to evil.com
>>
>> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> the browser. However it's well known that users very often hit
>> whichever button they suspect will make the dialog go away, rather
>> than actually read the contents of the dialog.
>> Step 3 again requires the user to answer "yes" to a dialog displayed
>> by the browser in at least some browsers. Same caveat applies though.
>>
>> One very simple remedy to this would be to require CORS opt-in for
>> cross-site downloads. For same-site downloads no special opt-in would
>> be required of course.
>>
>> It's also possible that it would be ok to do this without any opt-ins
>> since there are a good number of actions that the user has to take in
>> all these scenarios. Definitely something that I'd be ok with
>> discussing with our security team.
>>
>> Tentatively I would feel safer with the CORS option though. And again,
>> for same-site downloads this isn't a problem at all, but I suspect
>> that in many cases the file to be downloaded is hosted on a separate
>> server.
>>
>> Oh, and I don't have strong opinions at this time on if rel=attachment
>> or FileSaver or both should be the way to trigger this functionality.
>>
>> / Jonas
>>
>
> I agree FileSaver is useful and has its place, but I don't think it negates
> the need for something like rel=attachment or download=filename. For one,
> FileSaver currently operates on blobs and as you mention would have to be
> modified to handle URLs or streams more generally. Second, it would force
> developers to use javascript links and/or set up click listeners and so
> forth, which could be annoying for users (losing the ability to copy the URL
> etc).

As stated, I don't have a strong preference here. I suspect ultimately
we'll end up wanting both a markup based and an API based solution
here.

> I guess the interesting question is "If the response would not have
> otherwise triggered a download, and the request is cross-origin, should that
> require CORS" and personally I would say no, this is still a remote enough
> concern that I would not worry about it.

Indeed, that is the interesting question.

I know that I would personally feel a lot more comfortable if the site
opted in to allowing downloads of the resource in question. But it's
quite possible that I'm overly paranoid.

Though one thing to keep in mind is sites that explicitly state that a
resource should *not* reach the users disk. This is today often done
using "Cache-Control: no-store". Seems scary to allow such content to
be saved based on a cross-site request.

/ Jonas

From julian.reschke at gmx.de  Fri Jul 15 13:15:17 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 15 Jul 2011 22:15:17 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
Message-ID: <4E209FD5.80805@gmx.de>

On 2011-07-15 19:05, Ian Fette (????????) wrote:
> ..
>> It also doesn't naturally help understanding that it's just poor man's
>> Content-Disposition:attachment. From this point of view, I like Ian's
>> original proposal (rel=attachment) more.
>>
>
> Yes and no - both are sort of a poor man's Content-Disposition :) The
> question is whether we need to handle filename, and the proposal of
> download=filename at least maps content-disposition fully and compactly.
> ...

Well, one difference is that C-D is under the control of the owner of 
the resource being linked to (ideally), while attributes set somewhere 
else might not.

So there is a security-related aspect to this.

Best regards, Julian

From ian at hixie.ch  Fri Jul 15 13:18:04 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 20:18:04 +0000 (UTC)
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
 algorithm
In-Reply-To: <CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
	<Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
	<CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107152014060.3775@ps20323.dreamhostps.com>

On Fri, 15 Jul 2011, Tab Atkins Jr. wrote:
> 
> I'll note, though, that the spec algorithm seems to be Firefox's 
> behavior, which differs in a few significant points from IE's.  In 
> particular, IE doesn't strip whitespace from the color, doesn't have the 
> same "truncate at 128 bytes" behavior, and doesn't recognize a 3-digit 
> hex color as a CSS color (instead parsing it with legacy rules).
> 
> I doubt it matters too much, but was there any particular reason you 
> went with Firefox over IE here?

See:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372

Basically, it looks like IE does strip whitespace in some cases, the main 
difference is that it doesn't handle #123 the same as #112233. Since that 
would introduce an incompatibility with CSS, and since there was no 
interop on that case, I figured (based on input from Aryeh and dbaron) we 
might as well go with the sane behaviour.

Interop isn't perfect here so there's not really any winning whatever we do.

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

From ian at hixie.ch  Fri Jul 15 13:24:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 20:24:10 +0000 (UTC)
Subject: [whatwg] <details>, <summary> and styling
In-Reply-To: <235E71A0BBF14725854030F4C04807B6@JukanPC>
References: <op.vs3w0wvrm3w6te@kunnskapet.oslo.osa>
	<235E71A0BBF14725854030F4C04807B6@JukanPC>
Message-ID: <Pine.LNX.4.64.1107152021360.2079@ps20323.dreamhostps.com>

On Mon, 11 Apr 2011, Jukka K. Korpela wrote:
> Wilhelm Joys Andersen wrote:
> > 
> >    "If there is no child summary element [of the details element], the
> >    user agent should provide its own legend (e.g. "Details")." [1]
> > 
> > How exactly should this legend be provided?
> 
> Since the situation raises implementation difficulties, it would be best 
> to make the summary element required in a details element, i.e. to force 
> authors to provide a summary.

It is required. That doesn't force authors to do anything, though.


> But it appears to be an undue burden to require browsers to provide a 
> default legend, which would need to be different for different 
> languages.

Making it required doesn't help user agents deal with pages where it is 
omitted.


> A key issue with the details element is that it does not degrade well. 
> It's difficult to say how much this could be improved. In any case, the 
> fact that the details themselves - the content of the details element 
> excluding the summary element - do not constitute an element makes 
> things rather difficult.

It's easy to wrap them in an element for fallback purposes.

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

From ian at hixie.ch  Fri Jul 15 13:33:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 20:33:10 +0000 (UTC)
Subject: [whatwg] <summary> and <details> elements' specification
In-Reply-To: <9EA7F4E9AAAA49A9BD020B51637172D8@JukanPC>
References: <op.vtrz90t3rkwrfs@herring.wroclaw.osa>
	<4DA30906.4060305@opera.com>
	<50CD6C4370FA48AFB0B377923E8B9F00@JukanPC>
	<BANLkTikzVb97vCFf5eReJmJVjHS=jey8Uw@mail.gmail.com>
	<9EA7F4E9AAAA49A9BD020B51637172D8@JukanPC>
Message-ID: <Pine.LNX.4.64.1107152026340.2079@ps20323.dreamhostps.com>

On Mon, 11 Apr 2011, Tomasz Jamroszczak wrote:
> 
> Instead of making <summary> inside <details> working as <legend> inside 
> <fieldset>, we can throw away the <details> tag and make <summary> work 
> like <label> element with form element.  There's no need for "open" 
> attribute, instead already existing "hidden" attribute can be used on 
> any HTML element. Clicking on <summary> adds or removes "hidden" 
> attribute from element with given id.
> 
> 	Here's default UA style:
> 
> summary {
>  display: list-item;
>  list-style-type: -o-disclosure-closed;
> }
> [hidden] {
>  display: none;
> }
> 
> 	Here's example HTML:
> 
> <summary for="detailsId">This is summary. Click to show/close
> details.</summary>
> <div id="detailsId" hidden>...</div>

I don't think this really captures the way disclosure widgets work. On 
platforms that support them natively, the disclosure widget, the summary, 
and the details are all one unit.


> Pros:
> 1. Simple to understand by web page authors - its representation and semantics
> play well together.

It's not clear to me that it's any clearer -- in particular, for="" is 
especially bug prone.


> 2. No XBL involved.

We'd still have to have a binding for the animation effects.


> 3. Nicely rendered by browsers not supporting <summary> tag.

Isn't it the same as on browsers that don't support <details>?


> 4. No quirky rendering.

Not sure what you mean here. Why would anything have quirky rendering?


> 5. Less keywords to memorize by web authors, reusing existing keywords 
> in semantically correct way.

It trades <summary> and <details> for <summary>, for="", id="", and 
hidden="". I'm not sure that's much simpler.


> Cons:
> 6. Error-prone for web developers using copy-and-paste method.

That's a big con. :-)


On Tue, 12 Apr 2011, Jukka K. Korpela wrote:
> 
> Just as <label> could have been defined to be paired with (by default) 
> its next sibling or, perhaps better, with the next input field, 
> <summary> could be defined to be paired with its next sibling or, 
> perhaps better, with the next <details> element, by default.

This kind of magic association is, IMHO, very confusing for authors and 
not at all good language design.


> The element name "summary" is somewhat odd, and would appear even more 
> odd if liberated from appearing inside <details>. This element is really 
> meant to be a control for rendering vs. not rendering the contents of 
> the <details> element, and its contents is just a label for the control. 
> The example at 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element 
> is accompanied with the note "In these examples, the summary really just 
> summarises what the controls can change, and not the actual values, 
> which is less than ideal." In reality, the example seems to correspond 
> to _normal_ expected use of <details>, so the name "summary" is 
> misleading. Perhaps <control> would be better, but as it's really a 
> special kind of control only, how about <open>?

The idea is to encourage people to give a summary.

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

From ian at hixie.ch  Fri Jul 15 14:01:38 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 21:01:38 +0000 (UTC)
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<21B04E943C1341F0A867C1234DB30723@JukanPC>
	<BANLkTi=_8R2CRbTcXSFtSVAsD66682rznQ@mail.gmail.com>
	<A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
Message-ID: <Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>

On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
>
> I was surprised at seeing that the Finnish-language version of Google 
> Chrome 11 beta accepts a number with a comma, such as "4,2", in <input 
> type="number">. It silently converts the comma to a full stop, "4.2".
> 
> This looked like a useful feature at first sight, as decimal comma is 
> standard in Finnish as in most human languages. But this seems to 
> violate the rules, since <input type="number"> is defined as allowing a 
> "valid floating point number" (the definition of which clearly allows 
> FULL STOP as the only decimal separator) only and, moreover, there is 
> prescribed error processing: an error shall be returned, and the value 
> sanitization algorithm shall set the value to the empty string; ref.: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
>
> So the Google Chrome implementation is in error here, right?

No, it's exactly right. You are confusing the UI with the submitted value.


On Thu, 14 Apr 2011, Old?ich Vete?n?k wrote:
> 
> I am afraid that if the decimal separator (in rendering) doesn't behave 
> the way people expect it to, it will mean web developers will have to 
> deal with clients saying "We wan't to be able to enter a comma." The 
> "dealing" might mean not using <input type="number"> at all, which is 
> something we might not want...

That is a risk, it is true.


On Fri, 15 Apr 2011, Aryeh Gregor wrote:
> 
> I didn't read the whole thread, but: authors with specific needs will 
> always want to roll their own inputs for most of these things, and 
> that's fine.  If <input type=number> satisfies 80% of the use-cases, 
> that's fine.  As more authors start using the new input types, we'll get 
> feedback about what the most-requested features are, and we can consider 
> adding them at that time.  Trying to add more features to the new form 
> stuff is premature when we only have one really good implementation 
> (IMO: Gecko's), and that implementation is partial. The time to talk 
> about new features is when we have some amount of stability and 
> interoperability in existing features.

Indeed.


On Mon, 18 Apr 2011, Jukka K. Korpela wrote:
> 
> My original observation was that Google Chrome accepts a number with 
> decimal comma. It does that quite independently of the language. As far 
> as specifications go, it could just as well _only_ accept decimal comma. 
> Would that be perfectly suitable?

Per spec, yes.

Of course, it would be a pretty poor user experience. But that's just a UI 
issue. What it _should_ do is magically guess what the user meant and just 
do the right thing. Failing that, an approximation based on the user's 
preferences and locale, and the page's locale and style sheets.



On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
> 
> In general with the new input types, we have the problem that when they 
> are not supported but degrade to <input type="text">, the user would 
> need instructions on data format, e.g. saying that decimal point be used 
> or that a color be specified as #hhhhhh - and these would look stupid 
> when they are not needed. But this can probably be handled reasonably 
> using scripts that test for the support first. Or maybe it would be more 
> robust, transitionally, to include the instructions and <input 
> type="text"> in markup, with client-side scripting then trying to set 
> the state to, say, "number", and when successful, removing the 
> instructions (or replacing them with some different instructions).

Indeed.

Much discussion on this topic happened when we started on this work in 
2004 and 2005, I highly recommend perusing the archives around that time.


On Thu, 14 Apr 2011, John Tamplin wrote:
> 
> The entire web application, which includes both client and server-side 
> code, must have the same idea about what locale the user is using.  If 
> the app provides a drop-down box or preference setting to choose a 
> different locale, as most localized apps do, the web browser has to be 
> using the same locale for any native locale processing it uses.  
> Otherwise, you run a serious risk of having incorrect data -- if a user 
> types "10,000" in a field when they think they are using a locale with a 
> comma as the decimal separator, does the app receive that as 10000 or 
> 10.000?  If the app is running in en-US because the user requested it or 
> their system locale isn't supported by the app, and the browser sends 
> "10.000" as the value because the system locale is "de", then that is a 
> problem.

Indeed. To solve this, we need help from CSS. That's one of the reasons we 
created <output> in HTML.

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

From jackalmage at gmail.com  Fri Jul 15 14:09:15 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 15 Jul 2011 14:09:15 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
	algorithm
In-Reply-To: <Pine.LNX.4.64.1107152014060.3775@ps20323.dreamhostps.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
	<Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
	<CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>
	<Pine.LNX.4.64.1107152014060.3775@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDD=fY7f283qBR3UjM7VCxY4PeAn6DPb7g3KnahR9pfDsA@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:18 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 15 Jul 2011, Tab Atkins Jr. wrote:
>> I'll note, though, that the spec algorithm seems to be Firefox's
>> behavior, which differs in a few significant points from IE's. ?In
>> particular, IE doesn't strip whitespace from the color, doesn't have the
>> same "truncate at 128 bytes" behavior, and doesn't recognize a 3-digit
>> hex color as a CSS color (instead parsing it with legacy rules).
>>
>> I doubt it matters too much, but was there any particular reason you
>> went with Firefox over IE here?
>
> See:
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372
>
> Basically, it looks like IE does strip whitespace in some cases, the main
> difference is that it doesn't handle #123 the same as #112233. Since that
> would introduce an incompatibility with CSS, and since there was no
> interop on that case, I figured (based on input from Aryeh and dbaron) we
> might as well go with the sane behaviour.
>
> Interop isn't perfect here so there's not really any winning whatever we do.

That's fine.  I was just curious.  Like I said, WebKit now matches the
spec, so whatever.

~TJ

From ifette at google.com  Fri Jul 15 14:32:54 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 14:32:54 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E209FD5.80805@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
	<4E209FD5.80805@gmx.de>
Message-ID: <CAF4kx8dTi6T+j5SbLbfuJyG7yYbfLaNNpEKTTk9ztAO5iLZgNg@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:15 PM, Julian Reschke <julian.reschke at gmx.de>wrote:

> On 2011-07-15 19:05, Ian Fette (????????) wrote:
>
>> ..
>>
>>> It also doesn't naturally help understanding that it's just poor man's
>>> Content-Disposition:**attachment. From this point of view, I like Ian's
>>> original proposal (rel=attachment) more.
>>>
>>>
>> Yes and no - both are sort of a poor man's Content-Disposition :) The
>> question is whether we need to handle filename, and the proposal of
>> download=filename at least maps content-disposition fully and compactly.
>> ...
>>
>
> Well, one difference is that C-D is under the control of the owner of the
> resource being linked to (ideally), while attributes set somewhere else
> might not.
>
> So there is a security-related aspect to this.
>
> Best regards, Julian
>

So, in the interest of making progress, what if we tried...

download=filename

for same origin it's always downloaded (includes filesystem api from that
origin)
for cross-origin it's downloaded if we get a positive CORS response and/or
we get a content-disposition attachment
for cross-origin if we don't get positive CORS response OR
content-disposition:attachment we don't download

We can always start conservative and broaden out.

-Ian

From darin at chromium.org  Fri Jul 15 14:34:29 2011
From: darin at chromium.org (Darin Fisher)
Date: Fri, 15 Jul 2011 14:34:29 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
Message-ID: <CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> 2011/7/15 Ian Fette (????????) <ifette at google.com>:
> > 2011/7/15 Jonas Sicking <jonas at sicking.cc>
> >
> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
> >> > Many websites wish to offer a file for download, even though it could
> >> > potentially be viewed inline (take images, PDFs, or word documents as
> an
> >> > example). Traditionally the only way to achieve this is to set a
> >> > content-disposition header. *However, sometimes it is not possible for
> >> the
> >> > page author to have control over the response headers sent by the
> >> > server.*(A related example is offline apps, which may wish to provide
> >> > the user with
> >> > a way to "download" a file stored locally using the filesystem API but
> >> again
> >> > can't set any headers.) It would be nice to provide the page author
> with
> >> a
> >> > client side mechanism to trigger a download.
> >> >
> >> > After mulling this over with some application developers who are
> trying
> >> to
> >> > use this functionality, it seems like adding a "rel" attribute to the
> <a>
> >> > tag would be a straightforward, minimally invasive way to address this
> >> use
> >> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> >> > should treat this link as if the response came with a
> >> content-disposition:
> >> > attachment header, and offer to download/save the file for the user.
> >>
> >> We've discussed a different solution to the same problem at mozilla.
> >> The solution we discussed was allowing FileSaver to in addition to
> >> taking a blob argument, allow it to take a url argument.
> >>
> >> One concern which was brought up was the ability to cause the user to
> >> download a file from a third party site. I.e. this would allow
> >> evil.com to trick the user into downloading an email from the users
> >> webmail, or download a page from their bank which contains all their
> >> banking information. It might be easier to then trick the user into
> >> re-uploading the saved file to evil.com since from a user's
> >> perspective, it looked like the file came from evil.com
> >>
> >> Another possible attack goes something like:
> >> 1. evil.com tricks the user into downloading sensitive data from
> bank.com
> >> 2. evil.com then asks the user to download a html from evil.com and
> >> open the newly downloaded file
> >> 3. the html file contains script which reads the contents from the
> >> file downloaded from bank.com and sends it back to evil.com
> >>
> >> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> >> the browser. However it's well known that users very often hit
> >> whichever button they suspect will make the dialog go away, rather
> >> than actually read the contents of the dialog.
> >> Step 3 again requires the user to answer "yes" to a dialog displayed
> >> by the browser in at least some browsers. Same caveat applies though.
> >>
> >> One very simple remedy to this would be to require CORS opt-in for
> >> cross-site downloads. For same-site downloads no special opt-in would
> >> be required of course.
> >>
> >> It's also possible that it would be ok to do this without any opt-ins
> >> since there are a good number of actions that the user has to take in
> >> all these scenarios. Definitely something that I'd be ok with
> >> discussing with our security team.
> >>
> >> Tentatively I would feel safer with the CORS option though. And again,
> >> for same-site downloads this isn't a problem at all, but I suspect
> >> that in many cases the file to be downloaded is hosted on a separate
> >> server.
> >>
> >> Oh, and I don't have strong opinions at this time on if rel=attachment
> >> or FileSaver or both should be the way to trigger this functionality.
> >>
> >> / Jonas
> >>
> >
> > I agree FileSaver is useful and has its place, but I don't think it
> negates
> > the need for something like rel=attachment or download=filename. For one,
> > FileSaver currently operates on blobs and as you mention would have to be
> > modified to handle URLs or streams more generally. Second, it would force
> > developers to use javascript links and/or set up click listeners and so
> > forth, which could be annoying for users (losing the ability to copy the
> URL
> > etc).
>
> As stated, I don't have a strong preference here. I suspect ultimately
> we'll end up wanting both a markup based and an API based solution
> here.
>
> > I guess the interesting question is "If the response would not have
> > otherwise triggered a download, and the request is cross-origin, should
> that
> > require CORS" and personally I would say no, this is still a remote
> enough
> > concern that I would not worry about it.
>
> Indeed, that is the interesting question.
>
> I know that I would personally feel a lot more comfortable if the site
> opted in to allowing downloads of the resource in question. But it's
> quite possible that I'm overly paranoid.
>
> Though one thing to keep in mind is sites that explicitly state that a
> resource should *not* reach the users disk. This is today often done
> using "Cache-Control: no-store". Seems scary to allow such content to
> be saved based on a cross-site request.
>
> / Jonas
>


This security concern is very interesting.  I had not considered it before.

Putting that aside for a moment, I'm glad to hear that you also support
there being some declarative method of triggering a download.  Which of
the proposals are you leaning toward?

Personally, I'm most fond of the @download=filename method.  Reason:

1)  Unlike rel=something, @download is feature detectable at runtime via
("download" in document.createElement("a")).

2)  Unlike rel=something, @download provides a way to specify the name
of the file to save.  This makes the feature useful with data: URLs and
blob:
URLs (that are not backed by a single file).  This is valuable to me because
I can imagine wanting to save the contents of a <canvas>, and that probably
involves saving the data URL that you get from toDataURL().

3)  The target=_download idea is interesting, but I'm not sure we can safely
introduce new target values, and this also suffers from not providing a way
to
specify the downloaded filename.

4)  The idea of using both a rel=something and an attribute to specify the
file
name could work too, but it seems a bit overly verbose.  I'm not sure I see
enough benefit from this.  The idea of providing a name for <img> tags that
might be downloaded manually by the user is interesting, but it feels like a
far less interesting problem to solve.  If our solution solves this too,
then great,
but I wouldn't necessarily make it a requirement to solve this problem too.

Anyways, what do you think?  I'd really like to reach some consensus on what
the declarative method should look like.

Whatever security restrictions we come up with will need to apply to
FileSaver
too assuming FileSaver ends up taking an URL (and a filename!).

Thanks!
-Darin

From jonas at sicking.cc  Fri Jul 15 16:00:03 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Jul 2011 16:00:03 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
Message-ID: <CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>

2011/7/15 Darin Fisher <darin at chromium.org>:
> On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> 2011/7/15 Ian Fette (????????) <ifette at google.com>:
>> > 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>> >
>> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
>> >> > Many websites wish to offer a file for download, even though it could
>> >> > potentially be viewed inline (take images, PDFs, or word documents as
>> >> > an
>> >> > example). Traditionally the only way to achieve this is to set a
>> >> > content-disposition header. *However, sometimes it is not possible
>> >> > for
>> >> the
>> >> > page author to have control over the response headers sent by the
>> >> > server.*(A related example is offline apps, which may wish to provide
>> >> > the user with
>> >> > a way to "download" a file stored locally using the filesystem API
>> >> > but
>> >> again
>> >> > can't set any headers.) It would be nice to provide the page author
>> >> > with
>> >> a
>> >> > client side mechanism to trigger a download.
>> >> >
>> >> > After mulling this over with some application developers who are
>> >> > trying
>> >> to
>> >> > use this functionality, it seems like adding a "rel" attribute to the
>> >> > <a>
>> >> > tag would be a straightforward, minimally invasive way to address
>> >> > this
>> >> use
>> >> > case. <a rel=attachment href=blah.pdf> would indicate that the
>> >> > browser
>> >> > should treat this link as if the response came with a
>> >> content-disposition:
>> >> > attachment header, and offer to download/save the file for the user.
>> >>
>> >> We've discussed a different solution to the same problem at mozilla.
>> >> The solution we discussed was allowing FileSaver to in addition to
>> >> taking a blob argument, allow it to take a url argument.
>> >>
>> >> One concern which was brought up was the ability to cause the user to
>> >> download a file from a third party site. I.e. this would allow
>> >> evil.com to trick the user into downloading an email from the users
>> >> webmail, or download a page from their bank which contains all their
>> >> banking information. It might be easier to then trick the user into
>> >> re-uploading the saved file to evil.com since from a user's
>> >> perspective, it looked like the file came from evil.com
>> >>
>> >> Another possible attack goes something like:
>> >> 1. evil.com tricks the user into downloading sensitive data from
>> >> bank.com
>> >> 2. evil.com then asks the user to download a html from evil.com and
>> >> open the newly downloaded file
>> >> 3. the html file contains script which reads the contents from the
>> >> file downloaded from bank.com and sends it back to evil.com
>> >>
>> >> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> >> the browser. However it's well known that users very often hit
>> >> whichever button they suspect will make the dialog go away, rather
>> >> than actually read the contents of the dialog.
>> >> Step 3 again requires the user to answer "yes" to a dialog displayed
>> >> by the browser in at least some browsers. Same caveat applies though.
>> >>
>> >> One very simple remedy to this would be to require CORS opt-in for
>> >> cross-site downloads. For same-site downloads no special opt-in would
>> >> be required of course.
>> >>
>> >> It's also possible that it would be ok to do this without any opt-ins
>> >> since there are a good number of actions that the user has to take in
>> >> all these scenarios. Definitely something that I'd be ok with
>> >> discussing with our security team.
>> >>
>> >> Tentatively I would feel safer with the CORS option though. And again,
>> >> for same-site downloads this isn't a problem at all, but I suspect
>> >> that in many cases the file to be downloaded is hosted on a separate
>> >> server.
>> >>
>> >> Oh, and I don't have strong opinions at this time on if rel=attachment
>> >> or FileSaver or both should be the way to trigger this functionality.
>> >>
>> >> / Jonas
>> >>
>> >
>> > I agree FileSaver is useful and has its place, but I don't think it
>> > negates
>> > the need for something like rel=attachment or download=filename. For
>> > one,
>> > FileSaver currently operates on blobs and as you mention would have to
>> > be
>> > modified to handle URLs or streams more generally. Second, it would
>> > force
>> > developers to use javascript links and/or set up click listeners and so
>> > forth, which could be annoying for users (losing the ability to copy the
>> > URL
>> > etc).
>>
>> As stated, I don't have a strong preference here. I suspect ultimately
>> we'll end up wanting both a markup based and an API based solution
>> here.
>>
>> > I guess the interesting question is "If the response would not have
>> > otherwise triggered a download, and the request is cross-origin, should
>> > that
>> > require CORS" and personally I would say no, this is still a remote
>> > enough
>> > concern that I would not worry about it.
>>
>> Indeed, that is the interesting question.
>>
>> I know that I would personally feel a lot more comfortable if the site
>> opted in to allowing downloads of the resource in question. But it's
>> quite possible that I'm overly paranoid.
>>
>> Though one thing to keep in mind is sites that explicitly state that a
>> resource should *not* reach the users disk. This is today often done
>> using "Cache-Control: no-store". Seems scary to allow such content to
>> be saved based on a cross-site request.
>>
>> / Jonas
>
>
> This security concern is very interesting.  I had not considered it before.
> Putting that aside for a moment, I'm glad to hear that you also support
> there being some declarative method of triggering a download.  Which of
> the proposals are you leaning toward?
> Personally, I'm most fond of the @download=filename method.  Reason:
> 1)  Unlike rel=something, @download is feature detectable at runtime via
> ("download" in document.createElement("a")).
> 2)  Unlike rel=something, @download provides a way to specify the name
> of the file to save.  This makes the feature useful with data: URLs and
> blob:
> URLs (that are not backed by a single file).  This is valuable to me because
> I can imagine wanting to save the contents of a <canvas>, and that probably
> involves saving the data URL that you get from toDataURL().
> 3)  The target=_download idea is interesting, but I'm not sure we can safely
> introduce new target values, and this also suffers from not providing a way
> to
> specify the downloaded filename.
> 4)  The idea of using both a rel=something and an attribute to specify the
> file
> name could work too, but it seems a bit overly verbose.  I'm not sure I see
> enough benefit from this.  The idea of providing a name for <img> tags that
> might be downloaded manually by the user is interesting, but it feels like a
> far less interesting problem to solve.  If our solution solves this too,
> then great,
> but I wouldn't necessarily make it a requirement to solve this problem too.
> Anyways, what do you think?  I'd really like to reach some consensus on what
> the declarative method should look like.

I agree! I like the @download attribute the best so far for basically
the same reasons you enumerate. It's also a very memorable name.

It definitely is an interesting usecase that Glenn brought up about
being able to specify a save-as name without otherwise modifying the
behavior of a reference. However that seems like a much more rare
usecase and so not the one we should optimize for.

Another UI feature that this all would allow is the ability to
drag-out-to-save. I.e. if the user drags a <a href="..."
download="..."> to the desktop, the browser can treat that as a saving
action.

> Whatever security restrictions we come up with will need to apply to
> FileSaver
> too assuming FileSaver ends up taking an URL (and a filename!).

Absolutely!

I think that the model Ian summarized in his last email is a good one.
Same-origin is always allowed, cross-origin is only allowed if there
is CORS or content-disposition: attachment.

/ Jonas

From glenn at zewt.org  Fri Jul 15 16:43:45 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 15 Jul 2011 19:43:45 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
Message-ID: <CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>

2011/7/15 Jonas Sicking <jonas at sicking.cc>

> It definitely is an interesting usecase that Glenn brought up about
> being able to specify a save-as name without otherwise modifying the
> behavior of a reference. However that seems like a much more rare
> usecase and so not the one we should optimize for.
>

Bear in mind that "optimize for" doesn't mean "support at all"; if
download=filename is used, it seems unlikely that there will ever be *any*
client-side way to supply the filename without implying attachment, which is
a very different thing than "not optimizing for it".

I don't feel strongly enough about this to press it further, but <a
href=ugly download filename=pretty> also seems fairly clean, and avoids
combining parameters that really are orthogonal to one another.

-- 
Glenn Maynard

From tantek at cs.stanford.edu  Fri Jul 15 17:38:19 2011
From: tantek at cs.stanford.edu (=?utf-8?B?VGFudGVrIMOHZWxpaw==?=)
Date: Sat, 16 Jul 2011 00:38:19 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com><CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com><CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com><CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com><CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com><CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com><CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
Message-ID: <1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>

Agreed with Glenn, narrowing the semantic solves this problem neatly:

* filename="" attribute - what to name the file if saved by the user (by whatever means)
* existing rel="enclosure" spec - download the link when clicked/activated.

So the author can choose to do one, or the other, or both. Clean, simple, orthogonal.

Tantek
-----Original Message-----
From: Glenn Maynard <glenn at zewt.org>
Sender: whatwg-bounces at lists.whatwg.org
Date: Fri, 15 Jul 2011 19:43:45 
To: Jonas Sicking<jonas at sicking.cc>
Cc: whatwg<whatwg at whatwg.org>; Darin Fisher<darin at chromium.org>; <ifette at google.com>
Subject: Re: [whatwg] a rel=attachment

2011/7/15 Jonas Sicking <jonas at sicking.cc>

> It definitely is an interesting usecase that Glenn brought up about
> being able to specify a save-as name without otherwise modifying the
> behavior of a reference. However that seems like a much more rare
> usecase and so not the one we should optimize for.
>

Bear in mind that "optimize for" doesn't mean "support at all"; if
download=filename is used, it seems unlikely that there will ever be *any*
client-side way to supply the filename without implying attachment, which is
a very different thing than "not optimizing for it".

I don't feel strongly enough about this to press it further, but <a
href=ugly download filename=pretty> also seems fairly clean, and avoids
combining parameters that really are orthogonal to one another.

-- 
Glenn Maynard

From pkasting at google.com  Fri Jul 15 18:20:54 2011
From: pkasting at google.com (Peter Kasting)
Date: Fri, 15 Jul 2011 18:20:54 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
Message-ID: <CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>

On Fri, Jul 15, 2011 at 5:38 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> * existing rel="enclosure" spec - download the link when clicked/activated.


I object to rel="enclosure" purely on naming grounds.  It is completely
unintuitive.  I don't find the fact that a spec exists for it a compelling
reason to use it.  (Specs exist for lots of things, many of them bad.)

PK

From tantek at cs.stanford.edu  Fri Jul 15 18:25:27 2011
From: tantek at cs.stanford.edu (=?utf-8?B?VGFudGVrIMOHZWxpaw==?=)
Date: Sat, 16 Jul 2011 01:25:27 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com><CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com><CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com><CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com><CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com><CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com><CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com><1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry><CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
Message-ID: <1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>

Specs *and* publishers/consumers/implementations of rel-enclosure exist (see aforementioned wiki page). And the name is based on re-using the existing term with the same semantic from the Atom spec.

Sorry but the paint on that bikeshed dried a long time ago in an IETF working group far away. ;)

Tantek

-----Original Message-----
From: Peter Kasting <pkasting at google.com>
Date: Fri, 15 Jul 2011 18:20:54 
To: <tantek at cs.stanford.edu>
Cc: Glenn Maynard<glenn at zewt.org>; <whatwg-bounces at lists.whatwg.org>; Jonas Sicking<jonas at sicking.cc>; whatwg<whatwg at whatwg.org>; Darin Fisher<darin at chromium.org>; <ifette at google.com>
Subject: Re: [whatwg] a rel=attachment

On Fri, Jul 15, 2011 at 5:38 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> * existing rel="enclosure" spec - download the link when clicked/activated.


I object to rel="enclosure" purely on naming grounds.  It is completely
unintuitive.  I don't find the fact that a spec exists for it a compelling
reason to use it.  (Specs exist for lots of things, many of them bad.)

PK


From pkasting at google.com  Fri Jul 15 18:30:17 2011
From: pkasting at google.com (Peter Kasting)
Date: Fri, 15 Jul 2011 18:30:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
	<CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
	<1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>
Message-ID: <CAAHOzFBkTurVKkjpB0hBu+-W3DUWnk0TPP=5wSFqN6VA0+1+zQ@mail.gmail.com>

On Fri, Jul 15, 2011 at 6:25 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> ** Specs *and* publishers/consumers/implementations of rel-enclosure exist
> (see aforementioned wiki page).


The list on the wiki page, which I assume is non-exhaustive, is
extraordinarily uncompelling.


> And the name is based on re-using the existing term with the same semantic
> from the Atom spec.
>

Don't care.  Atom feeds and HTML pages are very different things.  Basically
I echo all of Tab's annoyances with this.

PK

From kevinmarks at gmail.com  Fri Jul 15 18:53:46 2011
From: kevinmarks at gmail.com (Kevin Marks)
Date: Fri, 15 Jul 2011 18:53:46 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAHOzFBkTurVKkjpB0hBu+-W3DUWnk0TPP=5wSFqN6VA0+1+zQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
	<CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
	<1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>
	<CAAHOzFBkTurVKkjpB0hBu+-W3DUWnk0TPP=5wSFqN6VA0+1+zQ@mail.gmail.com>
Message-ID: <CAD6ztsodRBKAa__ydxjp_WHH8spm-DnE9P2yDM59RFbM-8a=Wg@mail.gmail.com>

Enclosure is precisely this use case.

You can go back and grep
http://www.imc.org/atom-syntax/entire-arch.txt for enclosure for the
discussion if you like. After much debate, rel="enclosure" was used to
replace RSS's <enclosure> element, preserving the name.

This will lead you back via the RSS specs to this post by Dave Winer in 2001:

http://www.thetwowayweb.com/payloadsforrss

which makes the same analogy with email that you're using for "attachment"

The original example RSS file there:

http://static.userland.com/gems/backend/gratefulDead.xml

Is usefully rendered by Firefox and Safari, by translating the XML
file into an HTML representation that makes sense to users, and allows
subscription to it.

The same is true for any Atom or RSS feed containing podcasts.

Sadly, Chrome just shows a document dump of the XML tree, useless to anyone.

On Fri, Jul 15, 2011 at 6:30 PM, Peter Kasting <pkasting at google.com> wrote:
> On Fri, Jul 15, 2011 at 6:25 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:
>
>> ** Specs *and* publishers/consumers/implementations of rel-enclosure exist
>> (see aforementioned wiki page).
>
>
> The list on the wiki page, which I assume is non-exhaustive, is
> extraordinarily uncompelling.

Indeed, that could do with updating with newer examples and references
to oterh support.

>
>
>> And the name is based on re-using the existing term with the same semantic
>> from the Atom spec.
>>
>
> Don't care. ?Atom feeds and HTML pages are very different things. ?Basically
> I echo all of Tab's annoyances with this.
>

Atom/RSS Feeds are seen as useful HTML sources by many browser implementations.

From ifette at google.com  Fri Jul 15 18:59:17 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 18:59:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
Message-ID: <CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>

On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>
>> It definitely is an interesting usecase that Glenn brought up about
>> being able to specify a save-as name without otherwise modifying the
>> behavior of a reference. However that seems like a much more rare
>> usecase and so not the one we should optimize for.
>>
>
> Bear in mind that "optimize for" doesn't mean "support at all"; if
> download=filename is used, it seems unlikely that there will ever be *any*
> client-side way to supply the filename without implying attachment, which is
> a very different thing than "not optimizing for it".
>
> I don't feel strongly enough about this to press it further, but <a
> href=ugly download filename=pretty> also seems fairly clean, and avoids
> combining parameters that really are orthogonal to one another.
>

I really don't see the importance of the "name the thing that isn't going to
be downloaded" usecase; there are countless edge cases that we could concern
ourselves with in HTML but that few users will ever hit, this is one. (I
also suspect a user sophisticated enough to actually save something, e.g.
right click save as, is sophisticated enough to be able to type their own
filename.)I think it's better overall to keep the semantics as clean and
simple as possible. I suggest we move forward with <a href=blah
download=filename> with the origin considerations mentioned in the previous
email and move on.




>
> --
> Glenn Maynard
>
>

From jkorpela at cs.tut.fi  Fri Jul 15 21:52:51 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sat, 16 Jul 2011 07:52:51 +0300
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<21B04E943C1341F0A867C1234DB30723@JukanPC>
	<BANLkTi=_8R2CRbTcXSFtSVAsD66682rznQ@mail.gmail.com>
	<A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
	<Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>
Message-ID: <4E211923.1080608@cs.tut.fi>

16.07.2011 00:01, Ian Hickson wrote:

> Much discussion on this topic happened when we started on this work in
> 2004 and 2005, I highly recommend perusing the archives around that time.

Authors and implementors will need to be able to understand the topic 
without checking discussions archives, so the specs should say at least 
a little about the issue that the rules for user?s input may be quite 
different from the rules for the as stored and forwared. And users will 
be confused anyway, when user interfaces work oddly.

> On Thu, 14 Apr 2011, John Tamplin wrote:
>>
>> The entire web application, which includes both client and server-side
>> code, must have the same idea about what locale the user is using.  If
>> the app provides a drop-down box or preference setting to choose a
>> different locale, as most localized apps do, the web browser has to be
>> using the same locale for any native locale processing it uses.
>> Otherwise, you run a serious risk of having incorrect data -- if a user
>> types "10,000" in a field when they think they are using a locale with a
>> comma as the decimal separator, does the app receive that as 10000 or
>> 10.000?  If the app is running in en-US because the user requested it or
>> their system locale isn't supported by the app, and the browser sends
>> "10.000" as the value because the system locale is "de", then that is a
>> problem.
>
> Indeed. To solve this, we need help from CSS. That's one of the reasons we
> created<output>  in HTML.

This is about data representation and localization, not about optional 
stylistic suggestions, so CSS is a wrong way to deal with the issue. It 
will probably cause _further_ confusion.

I?m afraid the new input types for numeric data and for dates and times, 
even when implemented in browsers, will be of very limited usefulness 
and will cause more damage than good, unless the localization issues 
will be properly addressed.

It is part of the risk that they often _seemingly_ work. For example, an 
author would use <input type=number> and test the software thoroughly by 
his own standards, but the standards don?t include testing with the 
system?s UI language being other than English. So things seem to work 
until someone tries to put a bid of 10,000 dollars but gets it turned to 
10 dollars and loses, or makes a date for 7/4/2012 and gets it 
interpreted as April 7 when he meant July 4, or vice versa.

I?m afraid many authors will start using the new types eagerly when 
browser support comes sufficiently widespread. It looks so much better, 
cooler, and easier than parsing data yourself or requiring the user to 
type data in specifically instructed format. But it?s a dangerous illusion.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From andy at pigsonthewing.org.uk  Sat Jul 16 03:46:39 2011
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat, 16 Jul 2011 11:46:39 +0100
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
	<CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
Message-ID: <CABiXOE=mi46nqBQyiuoaY60o9Pi5RfsVZ99bggfTMbuhkHP2NA@mail.gmail.com>

On 16 July 2011 02:20, Peter Kasting <pkasting at google.com> wrote:
> On Fri, Jul 15, 2011 at 5:38 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:
>
>> * existing rel="enclosure" spec - download the link when clicked/activated.

> I object to rel="enclosure" purely on naming grounds. ?It is completely
> unintuitive. ?I don't find the fact that a spec exists for it a compelling
> reason to use it. ?(Specs exist for lots of things, many of them bad.)

The above bullet-point is also at odds with:

     http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html

in which it was claimed in August 2008 that rel="enclosure" is also
for streaming media:

    "... that hyperlink is intended to be downloaded (and/or streamed) and
     cached (and/or buffered)"

That said, it appears that the definition of rel="enclosure" at:

    http://microformats.org/wiki/rel-enclosure

was never updated to account for that, and this hAudio still has the issue:

   http://microformats.org/wiki/haudio-issues#D4:_2008-01-10__rel-enclosure_does_not_allow_for_links_to_streaming_files

which the August 2008 statement was suposedly intended to rectify.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

From darin at chromium.org  Sat Jul 16 13:48:43 2011
From: darin at chromium.org (Darin Fisher)
Date: Sat, 16 Jul 2011 13:48:43 -0700
Subject: [whatwg] a rel=attachment
Message-ID: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>

rel=anything makes me sad as it will mean more UA sniffing.  The fallback
behavior of loading the href inline could be dangerous.
On Jul 15, 2011 5:38 PM, "Tantek ?elik" <tantek at cs.stanford.edu> wrote:

From timeless at gmail.com  Sat Jul 16 22:26:20 2011
From: timeless at gmail.com (timeless)
Date: Sun, 17 Jul 2011 01:26:20 -0400
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <op.vyn9fc1qim6vpa@shwetank-dixits-macbook.local>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
	<op.vylop7byim6vpa@shwetank-dixits-macbook.local>
	<CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>
	<op.vyn9fc1qim6vpa@shwetank-dixits-macbook.local>
Message-ID: <CAACrNNeU=Yo4eFrRz9UQZXh9Q5hB33NXMH0Nsu-ctH5UwBjfsw@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:55 PM, Shwetank Dixit <shwetankd at opera.com> wrote:
> Just like, just allowing the web app to use the camera as it is will not
> make sense, and presumably, user agents will implement a authorization by
> the user before the app gains access to the camera (something like 'This
> application requests access to the camera. Allow for now/Always Allow/Never
> Allow/Close' just like you do in geolocation right now) ... just like that,
> you could do it for flash, where the app only gains access to it if the user
> allows it. If that is the implementation, i do not think there would be much
> hazards in allowing flash access.

Ignoring that there are in fact dangers for 'always allow' in the
location case. let's consider that it's probably the average choice of
a user (for geolocation, and you're suggesting the same ui for here,
thus it's probably what users will select without understanding any
risks).

if the user does choose always allow for this app, and later they're
in a museum or some other interesting location, suddenly they're in
trouble, even though originally when they allowed the thing it was ok.
that ui is not a good idea for this. the right approach is to just let
the user use their camera normally. the camera will manage flash (it
has to).

From jkorpela at cs.tut.fi  Sun Jul 17 07:09:54 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sun, 17 Jul 2011 17:09:54 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>
	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>
Message-ID: <4E22ED32.5080807@cs.tut.fi>

15.07.2011 19:56, Bjartur Thorlacius wrote:

> On 7/15/11, Jukka K. Korpela<jkorpela at cs.tut.fi>  wrote:
>> Should it? Even when the book has no URL? If you expect urn:isbn:? to
>> work anytime soon in any significant browser, you?re very optimistic.
>>
> Wikipedia and Amazon (among others) have all the mechanisms already.
> Such ISBN handlers could even be registered by JavaScripts.

Pardon? The issue is browser support to urn:isbn:?, not mechanisms that 
map ISBNs to some URLs in some system.

>> Browsers currently treat<cite>  just like<i>  (except that it has a
>> different name). There is no sign of advance functionality emerging. It
>> does not matter how usable something is when it does not exist at all.
>>
> <Cite>  is not nearly as useful as @cite.

<cite> is useful for using italics in a manner that makes you feel more 
structural. The cite attribute is completely useless unless you set up 
some processing of your own, just as a site could use for the foobar 
attribute (or data-foobar)

> So you're saying that users should rather search for the term ISBN,
> select the following number, copy it, remove/add hyphens as necessary
> and then paste it to a suitable bibliographic search form?

No, I?m saying that a proper quotation cites a book unambiguously, and 
ISBNs are a useful tool there and should then appear in content proper, 
not hidden in an attribute that browsers ignore. It?s wishful thinking 
to say that cite attributes magically turn ISBN numbers to cool queries 
or links. If a browser, or some client-side JavaScript, can do something 
like that to a cite attribute, it could equally well do that to content 
like ?ISBN? followed by a number of a certain type. That would be much 
more useful.

> But browsers need to be told that that number close to the quotation
> is an ISBN.

The string ?ISBN? is sufficient evidence of that.

> Before you said<cite>  was implemented as<i>, and your point is that
> the cite attribute is useless?

Yes.

 > They're barely related,

They are both supposed to be used for citations. I think <cite> is 
actually used quite a lot, though not always consistently, whereas the 
cite attribute mostly occurs in W3C and related documents.

 > @cite contains
> an URI, that an user agent might be able to use in an automated
> fashion.

Might be able, but doesn?t. Can you mention one browser that actually 
does something useful with it? And it isn?t a particularly new feature 
in specifications; browser vendors have had plenty of time to implement it.

> <Cite> contains a human-readable name of a work. That'll
> rarely be machine-readable.

HTML documents are always machine-readable. (Well, you _might_ just 
write HTML on a paper with a pen?)

Association of a URL of the quoted work with a blockquote element is not 
_required_. Human-readable indication of the quoted work and its author 
is a legal requirement as well as a matter of appropriateness, so it 
should have priority over any kind of linking. When there is markup for 
such indications, and even now that there isn?t, you can always _link_ 
to the quoted work?if you have something to link to.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From karld at opera.com  Sun Jul 17 07:25:54 2011
From: karld at opera.com (Karl Dubost)
Date: Sun, 17 Jul 2011 10:25:54 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E205398.9000905@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
Message-ID: <D811034D-B188-483E-A4C9-F69C0E8DC1B2@opera.com>


Le 15 juil. 2011 ? 10:50, Jukka K. Korpela a ?crit :
> Should it? Even when the book has no URL? If you expect urn:isbn:? to work anytime soon in any significant browser, you?re very optimistic.

in QuoteLink, I do a trick, eventually I should enable the provider of your choice.
But basically

if (cite.startsWith("urn:isbn:")) {
                isbn = cite.substring(9).replace(/\-/g, "");
                cite = "http://openlibrary.org/isbn/" + isbn;
            }

You could replace the openlibrary provider, by wikipedia, olcl, etc.
If we had a good model for describing authors, title, etc, we could even have a pre-populated form, giving the information for things which are not yet existent in Open Library. The first persons clicking on the link would have the opportunity to add the book. 



[1]: https://github.com/karlcow/QuoteLink
[2]: https://addons.opera.com/addons/extensions/details/quotelink/

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software


From nils at dieweltistgarnichtso.net  Sun Jul 17 08:07:09 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Jul 2011 17:07:09 +0200
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E22ED32.5080807@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>
	<4E22ED32.5080807@cs.tut.fi>
Message-ID: <20110717170709.73ed9b15@desudesudesu>

"Jukka K. Korpela" <jkorpela at cs.tut.fi> schrieb am Sun, 17 Jul 2011
17:09:54 +0300:

> 15.07.2011 19:56, Bjartur Thorlacius wrote:
> > [?]
> >
> > But browsers need to be told that that number close to the quotation
> > is an ISBN.
> 
> The string ?ISBN? is sufficient evidence of that.

Someone would need to standardize ?ISBN sniffing behaviour? for UAs
then. Could you make a proposal?

> [?]
> 
>  > @cite contains
> > an URI, that an user agent might be able to use in an automated
> > fashion.
> 
> Might be able, but doesn?t. Can you mention one browser that actually 
> does something useful with it? And it isn?t a particularly new
> feature in specifications; browser vendors have had plenty of time to
> implement it.

Are any reasons for not doing anything with that information known?
Probably a more basic issue: Is the cite attribute actually used?

> > <Cite> contains a human-readable name of a work. That'll
> > rarely be machine-readable.
> 
> HTML documents are always machine-readable. (Well, you _might_ just 
> write HTML on a paper with a pen?)

This is a category error. ?Machine-readable? in this context does not
mean ?digital information?. Fact: A scanned PDF of a printed out table
of expenses (yes, these occur) may not be ?machine-readable? in the
sense Bjartur Thorlacius used here. An ATOM feed certainly is.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From jkorpela at cs.tut.fi  Sun Jul 17 11:36:36 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sun, 17 Jul 2011 21:36:36 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <20110717170709.73ed9b15@desudesudesu>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>
	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>	<4E22ED32.5080807@cs.tut.fi>
	<20110717170709.73ed9b15@desudesudesu>
Message-ID: <4E232BB4.9020604@cs.tut.fi>

17.07.2011 18:07, Nils Dagsson Moskopp wrote:

>>> But browsers need to be told that that number close to the quotation
>>> is an ISBN.
>>
>> The string ?ISBN? is sufficient evidence of that.
>
> Someone would need to standardize ?ISBN sniffing behaviour? for UAs
> then. Could you make a proposal?

I think it would be rather trivial. The string ?ISBN? followed by 
something that matches the syntax of ISBN numbers, perhaps allowing some 
variation in punctuation, could be treated as an implicit link to a 
resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs.

The key issue is whether browser vendors have interest in it and which 
mechanism(s) would be used. After all, an ISBN could be in a multitude 
of ways, like querying an online bookshop, querying an online 
bibliographic system, or querying an site of books in digital format 
online. Which one should be used? Would it be useful? To be really 
useful, it should be handled so that the browser checks what it can get 
using the ISBN and then make that information available to user (how to 
get bibliographic info, how to read reviews, how to buy the book, how to 
borrow it in a library, download or read the book via the net for free 
or for fee).

> Are any reasons for not doing anything with that information known?
> Probably a more basic issue: Is the cite attribute actually used?

I don?t think it?s much used in the wild, except on pages by 
organizations that define HTML specs. What might be the motivation for 
browsers to do something special with it? Surely you could make things 
so that by clicking on a blockquote, the user accesses the resource 
pointed to by the cite attribute. Browsers could do that, and so could 
authors. But would users actually start clicking on quotations to see 
their sources? Surely they would far more probably click on the title of 
a work in visible credits if present and if it is a link, so what would 
the cite attribute help?

>>> <Cite>  contains a human-readable name of a work. That'll
>>> rarely be machine-readable.
>>
>> HTML documents are always machine-readable. (Well, you _might_ just
>> write HTML on a paper with a pen?)
>
> This is a category error. ?Machine-readable? in this context does not
> mean ?digital information?.

No, it?s not a category thing. It?s about the relativity of being 
?machine-readable.? You are probably thinking of data in a specific 
format designed to be easily parseable and useable by computer software, 
such as a URL, an ISO 8601 date notation, or an XML tag. But browsers 
already do many kinds of heuristics, parsing data that doesn?t really 
match the specs.

A title of a work is easily useable by software: put it inside quotation 
marks and throw it at Google, and the odds are that you get some useful 
links related to it, if there?s info on the work (and perhaps the work 
itself) on the web at all. Well, assuming that the title is relatively 
unique.

Titles of works are often more useful in the long run than URLs. URLs 
change far too often when sites are revamped or for other reasons.

I think a good start would be to add an optional (but usually 
recommended) <credits> or <source> element for use inside <blockquote>.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From svartman95 at gmail.com  Sun Jul 17 12:41:08 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 19:41:08 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
Message-ID: <4E233AD4.4080302@gmail.com>

?ann f?s 15.j?l 2011 18:39, skrifa?i Jonas Sicking:
> 2011/7/14 Ian Fette (????????)<ifette at google.com>:
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com
> 
Would it not be possible to send an unauthenticated request for the
file, if it's of different origin?

From svartman95 at gmail.com  Sun Jul 17 12:59:05 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 19:59:05 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
Message-ID: <4E233F09.5080304@gmail.com>

?ann f?s 15.j?l 2011 21:34, skrifa?i Darin Fisher:
> 2)  Unlike rel=something, @download provides a way to specify the name
> of the file to save.  This makes the feature useful with data: URLs and
> blob:
> URLs (that are not backed by a single file).  This is valuable to me because
> I can imagine wanting to save the contents of a<canvas>, and that probably
> involves saving the data URL that you get from toDataURL().
> 
> 3)  The target=_download idea is interesting, but I'm not sure we can safely
> introduce new target values, and this also suffers from not providing a way
> to
> specify the downloaded filename.
> 
Is there any other use case for providing the filename than using
canvas' toDataURL instead of blobs (a use case more simply served by
FileSaver)?

From w3c at adambarth.com  Sun Jul 17 13:05:17 2011
From: w3c at adambarth.com (Adam Barth)
Date: Sun, 17 Jul 2011 13:05:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
Message-ID: <CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>

2011/7/15 Jonas Sicking <jonas at sicking.cc>:
> We've discussed a different solution to the same problem at mozilla.
> The solution we discussed was allowing FileSaver to in addition to
> taking a blob argument, allow it to take a url argument.
>
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com

It seems like the solution to that problem is to be clear about where
the download is coming from.  Being clear about where downloads come
from is important in many scenarios, beyond just this setting.

> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file

Most browsers treat downloaded HTML files as "dangerous downloads,"
which means they get similar UI treatment to executable downloads.
For example, on Mac OS X, HTML downloads get the same "you're about to
open a dangerous file" warning from the operating system as executable
downloads.  If the attacker can convince the the user to click past
these dialogs, the attacker can convince the user to run arbitrary
code anyway, so there's nothing we can do to provide security in this
setting.

> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com

This sounds like a security vulnerability in the browser.  A better
security posture is to not allow downloaded content from one web site
read downloaded content from another web site, regardless of how the
content was downloaded.  For example, that's the current behavior of
Chrome and Internet Explorer.  Safari takes a different approach and
allows downloaded HTML content to access any file and any web site,
which means the attacker doesn't need to go through the elaborate
process you've outlined.  Merely performing step (3) is sufficient to
steal all the user's banking details today, which tells me that either
Safari is already vulnerable to this attack without this new feature
or that this threat isn't actually much of a risk.

(I know that Firefox has a policy that's somewhere in between the
strong local-file security policy used by Chrome and the weak policy
used by Safari, but Firefox's policy is too complex for me to
understand.  I know that protection of downloaded files was one of the
considerations that fed into the design of Firefox's policy, but I'll
leave it to others to common on whether it provided effective
protection in this scenario.)

> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.

In that model, the attacker can just run arbitrary code.  It's not
possible to provide security in that model, regardless of this
feature.

> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.

In this case, the caveats are important.  As described above, Chrome
is not vulnerable to this attack and Safari is vulnerable to this
attack even without this feature.

> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.

I'm not convinced there's a problem to solve here.  Wiring CORS into
the download system, by contrast, add a significant amount of
complexity to the implementation, which is costly.

> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.

I'm happy to talk it over with your security folks if they disagree
with the contents of this email.

> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.

It's important to think these scenarios through carefully, but in this
case I think we're fine without CORS.

Adam

From jonas at sicking.cc  Sun Jul 17 13:50:23 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Sun, 17 Jul 2011 13:50:23 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E233AD4.4080302@gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<4E233AD4.4080302@gmail.com>
Message-ID: <CA+c2ei8xdOi+FULXRygcsNn41wnuEQUVzQY1PHTNR5MC3Qog8A@mail.gmail.com>

On Sun, Jul 17, 2011 at 12:41 PM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> ?ann f?s 15.j?l 2011 18:39, skrifa?i Jonas Sicking:
>>
>> 2011/7/14 Ian Fette (????????)<ifette at google.com>:
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party site. I.e. this would allow
>> evil.com to trick the user into downloading an email from the users
>> webmail, or download a page from their bank which contains all their
>> banking information. It might be easier to then trick the user into
>> re-uploading the saved file to evil.com since from a user's
>> perspective, it looked like the file came from evil.com
>>
> Would it not be possible to send an unauthenticated request for the
> file, if it's of different origin?

That only solves part of the problem since if the file is located on a
private intranet behind a firewall, even unauthenticated requests can
return sensitive data.

Additionally, I strongly suspect people will want to be able to
download authenticated data cross site.

/ Jonas

From svartman95 at gmail.com  Sun Jul 17 15:18:12 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 22:18:12 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E232BB4.9020604@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>	<4E22ED32.5080807@cs.tut.fi>	<20110717170709.73ed9b15@desudesudesu>
	<4E232BB4.9020604@cs.tut.fi>
Message-ID: <4E235FA4.4040608@gmail.com>

?ann sun 17.j?l 2011 18:36, skrifa?i Jukka K. Korpela:
> 17.07.2011 18:07, Nils Dagsson Moskopp wrote:
>
> I think it would be rather trivial. The string ?ISBN? followed by
> something that matches the syntax of ISBN numbers, perhaps allowing some
> variation in punctuation, could be treated as an implicit link to a
> resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs.
>
> The key issue is whether browser vendors have interest in it and which
> mechanism(s) would be used. After all, an ISBN could be in a multitude
> of ways, like querying an online bookshop, querying an online
> bibliographic system, or querying an site of books in digital format
> online. Which one should be used? Would it be useful? To be really
> useful, it should be handled so that the browser checks what it can get
> using the ISBN and then make that information available to user (how to
> get bibliographic info, how to read reviews, how to buy the book, how to
> borrow it in a library, download or read the book via the net for free
> or for fee).
>
> I don?t think it?s much used in the wild, except on pages by
> organizations that define HTML specs. What might be the motivation for
> browsers to do something special with it? Surely you could make things
> so that by clicking on a blockquote, the user accesses the resource
> pointed to by the cite attribute. Browsers could do that, and so could
> authors. But would users actually start clicking on quotations to see
> their sources? Surely they would far more probably click on the title of
> a work in visible credits if present and if it is a link, so what would
> the cite attribute help?
>
Good point

> No, it?s not a category thing. It?s about the relativity of being
> ?machine-readable.? You are probably thinking of data in a specific
> format designed to be easily parseable and useable by computer software,
> such as a URL, an ISO 8601 date notation, or an XML tag. But browsers
> already do many kinds of heuristics, parsing data that doesn?t really
> match the specs.
>
You *could* interpret handwritten text on a piece of paper using a 
machine and parse it as HTML. I'm not volunteering for making a machine 
for that task.

> A title of a work is easily useable by software: put it inside quotation
> marks and throw it at Google, and the odds are that you get some useful
> links related to it, if there?s info on the work (and perhaps the work
> itself) on the web at all. Well, assuming that the title is relatively
> unique.
>

> Titles of works are often more useful in the long run than URLs. URLs
> change far too often when sites are revamped or for other reasons.
>
ISBNs are more useful in the long run than titles. Good titles get 
reused far too often.

> I think a good start would be to add an optional (but usually
> recommended) <credits> or <source> element for use inside <blockquote>.
>
What about the common case of multiple quotations credited to the same 
source (interleaved with comments).

From ben.schwarz at gmail.com  Sun Jul 17 15:46:16 2011
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Mon, 18 Jul 2011 08:46:16 +1000
Subject: [whatwg] Custom protocol handlers
Message-ID: <EC88788A9BC540669510CB476C6B8753@gmail.com>

After recently discovering custom protocol handlers[1], it struck me that it would be difficult to provide a decent user experience for those who used browsers which did not support the feature.

There have been previous calls to add further methods to the custom protocol ecosystem, such as a mozilla bug from 2008[2], and a separate discussion from January 2009[3]. However there?s been no solution, so I'd like to raise the issue of the registerProtocolHandler feature again.

Here are some user stories that I feel represent these issues:

1) 

As a web developer
I want to be able to tell when registration of protocols/schemes has either failed or been successful
So that I can provide a fluid user experience

2)
As a web developer
I want to be able to ascertain whether the user-agent supports the registerProtocolHandler feature
So that I can have an alternate experience for the user

Note: I have submitted a pull request to Modernizr to cover story #2[4], I left my story above for posterity. 

3) 
As a web designer / developer
I want to be able to ascertain if another website has registered a custom protocol handler in the user?s browser
So that I can knowingly design and implement an integration experience

4) 
As a web designer / developer
I want to be able to ascertain whether the user has "installed" a custom protocol handler within their operating system
So that I can knowingly design and implement an integration experience



Footnotes:

[1] http://updates.html5rocks.com/2011/06/Registering-a-custom-protocol-handler
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=440620
[3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/018101.html
[4] https://github.com/Modernizr/Modernizr/pull/324/files

Further feature reference:
? https://developer.mozilla.org/En/DOM/Window.navigator.registerProtocolHandler
? https://developer.mozilla.org/en/Web-based_protocol_handlers
? http://developers.whatwg.org/timers.html#custom-handlers


NB:

Thanks for the review from Mr Doug Schepers & Mr Oli Studholme

Cheers, 

Ben

From svartman95 at gmail.com  Sun Jul 17 16:10:55 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 23:10:55 +0000
Subject: [whatwg] Custom protocol handlers
In-Reply-To: <EC88788A9BC540669510CB476C6B8753@gmail.com>
References: <EC88788A9BC540669510CB476C6B8753@gmail.com>
Message-ID: <4E236BFF.5090401@gmail.com>

?ann sun 17.j?l 2011 22:46, skrifa?i Ben Schwarz:
>
> 3)
> As a web designer / developer
> I want to be able to ascertain if another website has registered a custom protocol handler in the user?s browser
> So that I can knowingly design and implement an integration experience
>
> 4)
> As a web designer / developer
> I want to be able to ascertain whether the user has "installed" a custom protocol handler within their operating system
> So that I can knowingly design and implement an integration experience
>
Your requirements seem reasonable at first glance, but it's hard to tell 
if and how to give this information without a concrete example of how it 
is going to be used. How is designing and implementing an "integration 
experience" possible with the information that a competitor has 
registered a protocol handler?

From karger at mit.edu  Sun Jul 17 16:13:36 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 02:13:36 +0300
Subject: [whatwg] namespaces in html5
Message-ID: <4E236CA0.1080501@mit.edu>

Dear whatwg,

   I wish to submit a comment regarding the (non) use of namespaces in 
html5.  But I hope you might help me track down the relevant issue off 
which to hang that comment.  Some time ago I found a lengthy discussion 
of whether html5 should use namespaces, with an over-simplified summary 
being "we haven't seen any important use cases for them, so let's not 
bother".  I would like to respond to that discussion by proposing a use 
case, but I cannot find it.  Searching the bugzilla database has failed. 
  Would you happen to recall participating in this discussion and know 
where it is?

thanks
David Karger

From glenn at zewt.org  Sun Jul 17 20:05:14 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Sun, 17 Jul 2011 23:05:14 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
Message-ID: <CABirCh_5FtmESk6FBQEB=yBuwDEVBN1X_k7ELk6oz-icvqA5ig@mail.gmail.com>

2011/7/15 Ian Fette (????????) <ifette at google.com>

> I really don't see the importance of the "name the thing that isn't going
> to be downloaded" usecase; there are countless edge cases that we could
> concern ourselves with in HTML but that few users will ever hit, this is
> one.
>

A common case is generated PDFs, which are regularly both saved to disk and
viewed in-browser (eg. tax forms which are viewed to print and then saved
for records).

 (I also suspect a user sophisticated enough to actually save something,
> e.g. right click save as, is sophisticated enough to be able to type their
> own filename.)
>

As a user sophisticated enough to enter a filename, I still want the browser
to do it for me.  "The user can do it by hand" isn't an argument for
requiring them to.

You don't always need to "right click save as", either.  For example, a user
with no browser PDF support will generally receive a window like Firefox's
"open with/save as" prompt, which should also be able to use this as a hint,
without forcing users *with* browser PDF support to save to disk.
Similarly, dragging to the desktop, dragging into other applications, batch
downloading (eg. via DownThemAll), and so on.

I think it's better overall to keep the semantics as clean and simple as
> possible.
>

I don't think combining orthogonal concepts is clean or simple.  It seems
like a step back from Content-Disposition, where these concepts are already
cleanly separated.

(Sorry for pressing this point, since I don't feel extremely strongly about
it, but I just felt these arguments against it were a bit weak.)


2011/7/15 Darin Fisher <darin at chromium.org>:
> URLs (that are not backed by a single file).  This is valuable to me
because
> I can imagine wanting to save the contents of a <canvas>, and that
probably
> involves saving the data URL that you get from toDataURL().

You'd probably want Canvas.toBlob and FileSaver for this, once both are
implemented.

-- 
Glenn Maynard

From jonas at sicking.cc  Sun Jul 17 20:40:56 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Sun, 17 Jul 2011 20:40:56 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
Message-ID: <CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>

On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth <w3c at adambarth.com> wrote:
> 2011/7/15 Jonas Sicking <jonas at sicking.cc>:
>> We've discussed a different solution to the same problem at mozilla.
>> The solution we discussed was allowing FileSaver to in addition to
>> taking a blob argument, allow it to take a url argument.
>>
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party site. I.e. this would allow
>> evil.com to trick the user into downloading an email from the users
>> webmail, or download a page from their bank which contains all their
>> banking information. It might be easier to then trick the user into
>> re-uploading the saved file to evil.com since from a user's
>> perspective, it looked like the file came from evil.com
>
> It seems like the solution to that problem is to be clear about where
> the download is coming from. ?Being clear about where downloads come
> from is important in many scenarios, beyond just this setting.

Sure, I'm just not sure that we'll ever be able to get very high
percentage of people actually understanding and making sure they make
a informed decision based on this.

>> Another possible attack goes something like:
>> 1. evil.com tricks the user into downloading sensitive data from bank.com
>> 2. evil.com then asks the user to download a html from evil.com and
>> open the newly downloaded file
>
> Most browsers treat downloaded HTML files as "dangerous downloads,"
> which means they get similar UI treatment to executable downloads.
> For example, on Mac OS X, HTML downloads get the same "you're about to
> open a dangerous file" warning from the operating system as executable
> downloads. ?If the attacker can convince the the user to click past
> these dialogs, the attacker can convince the user to run arbitrary
> code anyway, so there's nothing we can do to provide security in this
> setting.
>
>> 3. the html file contains script which reads the contents from the
>> file downloaded from bank.com and sends it back to evil.com
>
> This sounds like a security vulnerability in the browser. ?A better
> security posture is to not allow downloaded content from one web site
> read downloaded content from another web site, regardless of how the
> content was downloaded. ?For example, that's the current behavior of
> Chrome and Internet Explorer. ?Safari takes a different approach and
> allows downloaded HTML content to access any file and any web site,
> which means the attacker doesn't need to go through the elaborate
> process you've outlined. ?Merely performing step (3) is sufficient to
> steal all the user's banking details today, which tells me that either
> Safari is already vulnerable to this attack without this new feature
> or that this threat isn't actually much of a risk.

That wasn't the security model IE used last I checked. At least at
that time it would refuse to run any scripts while displaying a
warning to the user telling them that they needed to opt-in to scripts
on the page. Opting in was a simple matter of pressing a "yes button"
though and so is something that a decent number of people likely will
do. However it's possible that IE has changed since then.

I just tried and this doesn't appear to be what chrome does. I'd love
to hear the details about chrome's strategy.

> (I know that Firefox has a policy that's somewhere in between the
> strong local-file security policy used by Chrome and the weak policy
> used by Safari, but Firefox's policy is too complex for me to
> understand. ?I know that protection of downloaded files was one of the
> considerations that fed into the design of Firefox's policy, but I'll
> leave it to others to common on whether it provided effective
> protection in this scenario.)

Firefox *basically* lets the page read the contents of the folder that
the html file is in, as well as any sub folders. There are some tricky
situations where more than that is allowed, but that's generally not
relevant to this discussion.

However since Firefox allows the page to read the contents of the same
folder, this means that the script would be allowed to read files
downloaded from other sites.

>> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> the browser. However it's well known that users very often hit
>> whichever button they suspect will make the dialog go away, rather
>> than actually read the contents of the dialog.
>
> In that model, the attacker can just run arbitrary code. ?It's not
> possible to provide security in that model, regardless of this
> feature.

I'm not quite sure what you mean here?

>> One very simple remedy to this would be to require CORS opt-in for
>> cross-site downloads. For same-site downloads no special opt-in would
>> be required of course.
>
> I'm not convinced there's a problem to solve here. ?Wiring CORS into
> the download system, by contrast, add a significant amount of
> complexity to the implementation, which is costly.

The fact that it's a bit more work for the browser implementation
seems like a good tradeoff if it means less data stolen from users. So
this isn't an argument that carries much weight for me.

>> It's also possible that it would be ok to do this without any opt-ins
>> since there are a good number of actions that the user has to take in
>> all these scenarios. Definitely something that I'd be ok with
>> discussing with our security team.
>
> I'm happy to talk it over with your security folks if they disagree
> with the contents of this email.

Sure, we can schedule a security review of this feature if this is a
route that we really want to go. I'll contact you off this list.

/ Jonas

From w3c at adambarth.com  Sun Jul 17 21:05:02 2011
From: w3c at adambarth.com (Adam Barth)
Date: Sun, 17 Jul 2011 21:05:02 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
Message-ID: <CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>

On Sun, Jul 17, 2011 at 8:40 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth <w3c at adambarth.com> wrote:
>> 2011/7/15 Jonas Sicking <jonas at sicking.cc>:
>>> We've discussed a different solution to the same problem at mozilla.
>>> The solution we discussed was allowing FileSaver to in addition to
>>> taking a blob argument, allow it to take a url argument.
>>>
>>> One concern which was brought up was the ability to cause the user to
>>> download a file from a third party site. I.e. this would allow
>>> evil.com to trick the user into downloading an email from the users
>>> webmail, or download a page from their bank which contains all their
>>> banking information. It might be easier to then trick the user into
>>> re-uploading the saved file to evil.com since from a user's
>>> perspective, it looked like the file came from evil.com
>>
>> It seems like the solution to that problem is to be clear about where
>> the download is coming from. ?Being clear about where downloads come
>> from is important in many scenarios, beyond just this setting.
>
> Sure, I'm just not sure that we'll ever be able to get very high
> percentage of people actually understanding and making sure they make
> a informed decision based on this.
>
>>> Another possible attack goes something like:
>>> 1. evil.com tricks the user into downloading sensitive data from bank.com
>>> 2. evil.com then asks the user to download a html from evil.com and
>>> open the newly downloaded file
>>
>> Most browsers treat downloaded HTML files as "dangerous downloads,"
>> which means they get similar UI treatment to executable downloads.
>> For example, on Mac OS X, HTML downloads get the same "you're about to
>> open a dangerous file" warning from the operating system as executable
>> downloads. ?If the attacker can convince the the user to click past
>> these dialogs, the attacker can convince the user to run arbitrary
>> code anyway, so there's nothing we can do to provide security in this
>> setting.
>>
>>> 3. the html file contains script which reads the contents from the
>>> file downloaded from bank.com and sends it back to evil.com
>>
>> This sounds like a security vulnerability in the browser. ?A better
>> security posture is to not allow downloaded content from one web site
>> read downloaded content from another web site, regardless of how the
>> content was downloaded. ?For example, that's the current behavior of
>> Chrome and Internet Explorer. ?Safari takes a different approach and
>> allows downloaded HTML content to access any file and any web site,
>> which means the attacker doesn't need to go through the elaborate
>> process you've outlined. ?Merely performing step (3) is sufficient to
>> steal all the user's banking details today, which tells me that either
>> Safari is already vulnerable to this attack without this new feature
>> or that this threat isn't actually much of a risk.
>
> That wasn't the security model IE used last I checked. At least at
> that time it would refuse to run any scripts while displaying a
> warning to the user telling them that they needed to opt-in to scripts
> on the page. Opting in was a simple matter of pressing a "yes button"
> though and so is something that a decent number of people likely will
> do. However it's possible that IE has changed since then.
>
> I just tried and this doesn't appear to be what chrome does. I'd love
> to hear the details about chrome's strategy.

Chrome treats every local HTML document as having a unique origin
(i.e., as defined by HTML5 for the sandbox attribute).  That means
local HTML files can't read other files in the user's file system,
including other downloads.  This policy makes some users sad, but we
feel the security benefits outweigh that amount of sadness.

>> (I know that Firefox has a policy that's somewhere in between the
>> strong local-file security policy used by Chrome and the weak policy
>> used by Safari, but Firefox's policy is too complex for me to
>> understand. ?I know that protection of downloaded files was one of the
>> considerations that fed into the design of Firefox's policy, but I'll
>> leave it to others to common on whether it provided effective
>> protection in this scenario.)
>
> Firefox *basically* lets the page read the contents of the folder that
> the html file is in, as well as any sub folders. There are some tricky
> situations where more than that is allowed, but that's generally not
> relevant to this discussion.
>
> However since Firefox allows the page to read the contents of the same
> folder, this means that the script would be allowed to read files
> downloaded from other sites.

There's no exception for the Downloads folder?  In that case, Firefox
is vulnerable to downloaded HTML documents (e.g., email attachments)
spying on all the user's other downloads (e.g., tax returns).  That
sounds like a vulnerability that should be fixed regardless of whether
we add this feature.

>>> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>>> the browser. However it's well known that users very often hit
>>> whichever button they suspect will make the dialog go away, rather
>>> than actually read the contents of the dialog.
>>
>> In that model, the attacker can just run arbitrary code. ?It's not
>> possible to provide security in that model, regardless of this
>> feature.
>
> I'm not quite sure what you mean here?

If the user is willing to "very often hit whatever button they suspect
will make the dialog go away," then the attacker can run arbitrary
code on their computer by triggering a download of an EXE and getting
the user to click through however many warnings stand between them an
running the EXE.  It's not an interesting model from a security point
of view.

Many browsers have similar warnings for running local HTML files
downloaded from the web as they do for running loaded EXEs.  For
example, compare the dialogs used for these purposes in Mac OS X.
They're identical for all intents and purposes.

My point is, either the attack you've outlined is already a problem
today or it's not a problem today, depending on which browser we
talking about on which operating system.  In either case, adding this
feature isn't really changing the security equation in any appreciable
way.

>>> One very simple remedy to this would be to require CORS opt-in for
>>> cross-site downloads. For same-site downloads no special opt-in would
>>> be required of course.
>>
>> I'm not convinced there's a problem to solve here. ?Wiring CORS into
>> the download system, by contrast, add a significant amount of
>> complexity to the implementation, which is costly.
>
> The fact that it's a bit more work for the browser implementation
> seems like a good tradeoff if it means less data stolen from users. So
> this isn't an argument that carries much weight for me.

There's also complexity for authors, who need to set the appropriate
headers and to worry about authenticated versus unauthenticated
requests.  Worse, in some deployment scenarios, requiring CORS to use
this feature actually exposes the sites to greater risk because they
might set ACLs on these resources that are broader than needed.
Here's an example:

1) A webmail service wants to offer attachments for download.
2) The webmail service is security conscious, so it renders email
messages in a sandboxed iframe in case it's email rendering contains
an XSS hole (which is quite possible, especially with rich-text, HTML
email).
3) The webmail service wants to include links to download email
attachments using this feature.

In order for the links to work (assuming the links appear in context
in the email, as they do in Outlook, for example), the webmail
provider needs to set CORS headers that grants the sandboxed iframe
access to the attachments.  Because the sandboxed iframe runs in a
unique origin (for maximum security), the only CORS ACL that works is
"Access-Control-Allow-Origin: *".  However, that ACL allows any other
web site to read the contents of the user's attachments!  Now, maybe
you could work around that issue using unguessable URLs for the
attachments, but you'd still be exposing the contents of the
attachments if there's an XSS in the mail rendering code, a
vulnerability that would not be present if the downloads feature
wasn't coupled to CORS.

In summary, using CORS for this purpose is costly (both to
implementors and to authors), and I don't think it solves a real
security problem.

Adam

From jkorpela at cs.tut.fi  Sun Jul 17 21:08:41 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Mon, 18 Jul 2011 07:08:41 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E235FA4.4040608@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>	<4E22ED32.5080807@cs.tut.fi>	<20110717170709.73ed9b15@desudesudesu>
	<4E232BB4.9020604@cs.tut.fi> <4E235FA4.4040608@gmail.com>
Message-ID: <4E23B1C9.8030402@cs.tut.fi>

18.07.2011 01:18, Bjartur Thorlacius wrote:

>> Titles of works are often more useful in the long run than URLs. URLs
>> change far too often when sites are revamped or for other reasons.
>>
> ISBNs are more useful in the long run than titles. Good titles get
> reused far too often.

ISBNs have their uses (otherwise they wouldn?t be used), but they are 
codes, not names?suitable for use as unique identifiers, not in 
marketing and discussions. A quality quotation has credits that mention 
author, book title, book ISBN, and location within book. All this can be 
done in printed publications without any links or markup. So the 
adequate question is: which markup (if any) should we use for and within 
the credits?

I haven?t seen many attempts to address this question. Maybe it?s not 
that crucial, as proper credits work without markup too?markup could 
just be very useful enhancement. But <blockquote> as a semantic element 
is wishful thinking then.

HTML5 is currently making this a bit worse by explicitly forbidding 
<blockquite> from containing anything that doesn?t come from the 
external source, such as credits?without even telling how to deal with 
credits then.

>> I think a good start would be to add an optional (but usually
>> recommended) <credits> or <source> element for use inside <blockquote>.
>>
> What about the common case of multiple quotations credited to the same
> source (interleaved with comments).

People solve such issues every day when writing books and articles, 
using references to previous mentions of sources. At the shortest, ?op. 
cit.? In hypertext, the reference can be made to a link.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From ian at hixie.ch  Sun Jul 17 22:46:14 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 05:46:14 +0000 (UTC)
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E236CA0.1080501@mit.edu>
References: <4E236CA0.1080501@mit.edu>
Message-ID: <Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>

On Mon, 18 Jul 2011, David Karger wrote:
> 
>   I wish to submit a comment regarding the (non) use of namespaces in 
> html5. But I hope you might help me track down the relevant issue off 
> which to hang that comment.  Some time ago I found a lengthy discussion 
> of whether html5 should use namespaces, with an over-simplified summary 
> being "we haven't seen any important use cases for them, so let's not 
> bother".  I would like to respond to that discussion by proposing a use 
> case, but I cannot find it. Searching the bugzilla database has failed.  
> Would you happen to recall participating in this discussion and know 
> where it is?

You can just post a new thread here.

I recommend describing the problem you wish to address separately from 
your preferred solution. Also I recommend using a word other than 
"namespaces" to describe your preferred solution, as that word is usually 
used in the Web context to refer to some specific designs with known 
problems, and it is likely that you actually want something different.

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

From narendra at narendrasisodiya.com  Mon Jul 18 03:41:37 2011
From: narendra at narendrasisodiya.com (Narendra Sisodiya)
Date: Mon, 18 Jul 2011 16:11:37 +0530
Subject: [whatwg] HTML5 based Eduvid Slidecasting Demo
In-Reply-To: <BANLkTi=YdPFQ419anpK2Rx6B_r5gYV4xGQ@mail.gmail.com>
References: <BANLkTimHTmiyDipLLDh9aRK=xQvMvZOPew@mail.gmail.com>
	<BANLkTi=YdPFQ419anpK2Rx6B_r5gYV4xGQ@mail.gmail.com>
Message-ID: <CAB80A68pHSv8k-SXRbojwWEt0653F7Thqyn_=f_zVAeHvfJeRA@mail.gmail.com>

On Sun, May 22, 2011 at 3:20 AM, Narendra Sisodiya <
narendra at narendrasisodiya.com> wrote:

> I hope this demo will help to who who want html5 version of slidecasting
> technique.
> There is big room or improvement in the codebase.
>
> http://code.narendrasisodiya.com/slidecast/demo-slidecasting.html
>


Another Demo - Video + Slides -
http://code.narendrasisodiya.com/video-slidecast/demo.html
I have support for reading time.xml this time. over the time this will grow
and parser for handling a general purpose time.xml will be developed.

Blog Entry ->
http://blog.narendrasisodiya.com/2011/07/html5-based-video-slidecasting-demo.html

From ben.schwarz at gmail.com  Mon Jul 18 03:54:29 2011
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Mon, 18 Jul 2011 20:54:29 +1000
Subject: [whatwg] Custom protocol handlers
In-Reply-To: <4E236BFF.5090401@gmail.com>
References: <EC88788A9BC540669510CB476C6B8753@gmail.com>
	<4E236BFF.5090401@gmail.com>
Message-ID: <54F753D531494D9E90D4F7D67B5D6801@gmail.com>

Good feedback?The important detail of these stories was ambiguous:  

If I were to re-write it, I'd say:

3)
As a web designer / developer
I want to be able to ascertain if a custom protocol handler has been "installed" to the users browser
So that I can knowingly design and implement an integration experience



On Monday, 18 July 2011 at 9:10 AM, Bjartur Thorlacius wrote:

> ?ann sun 17.j?l 2011 22:46, skrifa?i Ben Schwarz:
> >  
> > 3)
> > As a web designer / developer
> > I want to be able to ascertain if another website has registered a custom protocol handler in the user?s browser
> > So that I can knowingly design and implement an integration experience
> >  
> > 4)
> > As a web designer / developer
> > I want to be able to ascertain whether the user has "installed" a custom protocol handler within their operating system
> > So that I can knowingly design and implement an integration experience
> Your requirements seem reasonable at first glance, but it's hard to tell  
> if and how to give this information without a concrete example of how it  
> is going to be used. How is designing and implementing an "integration  
> experience" possible with the information that a competitor has  
> registered a protocol handler?


From philipj at opera.com  Mon Jul 18 04:20:11 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Mon, 18 Jul 2011 13:20:11 +0200
Subject: [whatwg] Microdata - Handling the case where a string is
 upgraded to an object
In-Reply-To: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
References: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
Message-ID: <op.vyta3xunsr6mfa@kirk>

On Thu, 14 Jul 2011 20:49:44 +0200, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> Some IRC discussion this morning concerned the scenario where an API
> starts by exposing a property as a string, but later wants to change
> it to be a complex object.
>
> This appears to be a reasonably common scenario.  For example, a
> vocabulary with a "name" property may start with it being a string,
> and then later change to an object exposing "firstname"/"lastname"/etc
> properties.  A vocabulary for a music library may start by having
> "track" as a string, then later expanding it to expose the track
> title, the individual artist, the running time, etc.
>
> In a very similar vein, the CSSOM is currently defined to always
> return property values as strings.  We want to instead return complex
> objects that expose useful information and interfaces specialized on
> the value's type, however.  For compat reasons, we have to use an
> entirely different accessor in order to expose this type of thing.
>
> It seems that this may be a useful problem to solve in Microdata.  We
> can expose either an attribute or a privileged property name for the
> object's "name"/"title"/"string representation".  Then, when using the
> .items accessor, objects can be returned with a custom .toString that
> returns that value, so they can be used as strings in legacy code.
>
> Thoughts?

There is no items IDL attribute, do you mean getItems() or .itemValue  
perhaps?

I take it the problem is with code like this:

<div itemscope itemtype="person"><span itemprop="name">Foo  
Barsson</span></div>
<script>
var p = document.getItems("person")[0];
alert(p.properties.namedItem("name")[0].itemValue);
</script>

If the HTML changes to

<div itemscope itemtype="person"><span itemprop="name" itemscope><span  
itemprop="givenName">Foo</span> <span  
itemprop="familyName">Barsson</span></span></div>

then the script would be alerting "[object HTMLElement]" instead of "Foo  
Barsson".

I'm not sure why this would be a problem. If someone changes the page,  
then can't they adjust the script to match? Is it extensions and libraries  
that you're worried about?

As for the solution, are you suggesting that .itemValue return a special  
object which is like HTMLElement in all regards except for how it  
toString()s?

-- 
Philip J?genstedt
Core Developer
Opera Software

From tommyw at google.com  Mon Jul 18 05:17:17 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Mon, 18 Jul 2011 14:17:17 +0200
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
Message-ID: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>

I am very confused regarding the below paragraph from the latest spec:

When a track in a
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 parent is disabled, any
MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
 objects corresponding to the tracks in any
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 objects that were created from parent are disassociated from any track, and
must not be reused for tracks again. If a disabled track in a
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 parent is re-enabled, from the perspective of any
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 objects that were created from parent it is a new track and thus new
MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
 objects must be created for the tracks that correspond to the re-enabled
track.



After cloning a LocalMediaStream it looks like this:

LocalMediaStream -> MediaStream1
Track1(E)           Track1(E)
Track2(E)           Track2(E)
Track3(E)           Track3(E)

and as I interpret the spec it looks like this if Track1 in the
LocalMediaStream is disabled:

LocalMediaStream -> MediaStream1
Track1(D)           Track2(E)
Track2(E)           Track3(E)
Track3(E)

So Track1 disappears from the MediaStream1 object and doesn't come back even
if Track1 in the LMS object is enabled:

LocalMediaStream -> MediaStream1
Track1(E)           Track2(E)
Track2(E)           Track3(E)
Track3(E)

And to get it back again has to create a new MediaStream object from the
LMS:

LocalMediaStream -> MediaStream2
Track1(E)           Track1(E)
Track2(E)           Track2(E)
Track3(E)           Track3(E)

Is this interpretation correct?


/Tommy

 --
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.

From tommyw at google.com  Mon Jul 18 05:20:39 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Mon, 18 Jul 2011 14:20:39 +0200
Subject: [whatwg] Muting MediaStreamTracks?
Message-ID: <CALLKCfMV=D-ojvdsu1jicDu-TXqLTeO_imqgo8_QLzRN+JDWwg@mail.gmail.com>

The latest version of the spec mentions muting in several places, for
example:

 (Merely muted tracks are not removed, so the tracks do not change when the
parent is finished.)


But there are no mute operators in the idl definitions... How is the mute
function supposed to work?

/Tommy

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.

From harald at alvestrand.no  Mon Jul 18 05:29:26 2011
From: harald at alvestrand.no (Harald Alvestrand)
Date: Mon, 18 Jul 2011 14:29:26 +0200
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>
References: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>
Message-ID: <4E242726.4010701@alvestrand.no>

Additional question:

What is the scenario in which this behavioiur is useful?

On 07/18/11 14:17, Tommy Widenflycht (?????) wrote:
> I am very confused regarding the below paragraph from the latest spec:
>
> When a track in a
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   parent is disabled, any
> MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
>   objects corresponding to the tracks in any
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   objects that were created from parent are disassociated from any track, and
> must not be reused for tracks again. If a disabled track in a
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   parent is re-enabled, from the perspective of any
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   objects that were created from parent it is a new track and thus new
> MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
>   objects must be created for the tracks that correspond to the re-enabled
> track.
>
>
>
> After cloning a LocalMediaStream it looks like this:
>
> LocalMediaStream ->  MediaStream1
> Track1(E)           Track1(E)
> Track2(E)           Track2(E)
> Track3(E)           Track3(E)
>
> and as I interpret the spec it looks like this if Track1 in the
> LocalMediaStream is disabled:
>
> LocalMediaStream ->  MediaStream1
> Track1(D)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)
>
> So Track1 disappears from the MediaStream1 object and doesn't come back even
> if Track1 in the LMS object is enabled:
>
> LocalMediaStream ->  MediaStream1
> Track1(E)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)
>
> And to get it back again has to create a new MediaStream object from the
> LMS:
>
> LocalMediaStream ->  MediaStream2
> Track1(E)           Track1(E)
> Track2(E)           Track2(E)
> Track3(E)           Track3(E)
>
> Is this interpretation correct?
>
>
> /Tommy
>
>   --
> Tommy Widenflycht, Senior Software Engineer
> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
> Org. nr. 556656-6880
> And yes, I have to include the above in every outgoing email according to EU
> law.
>



From aykut.sensoy at bild.de  Mon Jul 18 05:54:19 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Mon, 18 Jul 2011 12:54:19 +0000
Subject: [whatwg] date meta-tag invalid
Message-ID: <CA49FA02.10AEB%aykut.sensoy@bild.de>

According to the w3c Validator the  <metaname="date"content="#" /> tag is invalid. In the WHATWG MetaExtensions List there is no registered extension, no specification and no proposal for the date meta-tag.
The only alternative for "date" is a proposal called "created", which however doesn't meet the requirements for registration . For our SEO team the date meta-tag contains some of the most important information about a webpage.
What would be a w3c-valid way to implement a creation date meta-tag in html5?


Kind Regards
Aykut Sensoy

From mat at matcarey.co.uk  Mon Jul 18 06:06:02 2011
From: mat at matcarey.co.uk (Mat Carey)
Date: Mon, 18 Jul 2011 14:06:02 +0100
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA49FA02.10AEB%aykut.sensoy@bild.de>
References: <CA49FA02.10AEB%aykut.sensoy@bild.de>
Message-ID: <D06473CF-34AC-455C-914B-8AB51056CC59@matcarey.co.uk>

I'm not aware of the context, but is your problem the lack of spaces?

You said:

> <metaname="date"content="#" />

Did you mean:

<meta name="date" content="#" />

Mat Carey

On 18 Jul 2011, at 13:54, <aykut.sensoy at bild.de> wrote:

> According to the w3c Validator the  <metaname="date"content="#" /> tag is invalid. In the WHATWG MetaExtensions List there is no registered extension, no specification and no proposal for the date meta-tag.
> The only alternative for "date" is a proposal called "created", which however doesn't meet the requirements for registration . For our SEO team the date meta-tag contains some of the most important information about a webpage.
> What would be a w3c-valid way to implement a creation date meta-tag in html5?
> 
> 
> Kind Regards
> Aykut Sensoy


From julian.reschke at gmx.de  Mon Jul 18 06:27:37 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 18 Jul 2011 15:27:37 +0200
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA49FA02.10AEB%aykut.sensoy@bild.de>
References: <CA49FA02.10AEB%aykut.sensoy@bild.de>
Message-ID: <4E2434C9.6050502@gmx.de>

On 2011-07-18 14:54, aykut.sensoy at bild.de wrote:
> According to the w3c Validator the<metaname="date"content="#" />  tag is invalid. In the WHATWG MetaExtensions List there is no registered extension, no specification and no proposal for the date meta-tag.
> The only alternative for "date" is a proposal called "created", which however doesn't meet the requirements for registration . For our SEO team the date meta-tag contains some of the most important information about a webpage.
> What would be a w3c-valid way to implement a creation date meta-tag in html5?

Out of curiosity: who is processing the tag? And what does this have to 
do with SEO? Do search engines do anything with it?

 From HTML5's point of view the suggest replace is probably "<time 
pubdate>"... Did you look at that already?

Also: there seems to be overlap with Dublin Core's "dc:created"?

Best regards, Julian

From aykut.sensoy at bild.de  Mon Jul 18 06:49:50 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Mon, 18 Jul 2011 13:49:50 +0000
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <D06473CF-34AC-455C-914B-8AB51056CC59@matcarey.co.uk>
Message-ID: <CA4A0651.10AF6%aykut.sensoy@bild.de>

hi, this was only a mistake in the e-mail. you can see the meta-tag in the
source code live at www.stylebook.de

aykut



Am 18.07.11 15:06 schrieb "Mat Carey" unter <mat at matcarey.co.uk>:

>I'm not aware of the context, but is your problem the lack of spaces?
>
>You said:
>
>> <metaname="date"content="#" />
>
>Did you mean:
>
><meta name="date" content="#" />
>
>Mat Carey
>
>On 18 Jul 2011, at 13:54, <aykut.sensoy at bild.de> wrote:
>
>> According to the w3c Validator the  <metaname="date"content="#" /> tag
>>is invalid. In the WHATWG MetaExtensions List there is no registered
>>extension, no specification and no proposal for the date meta-tag.
>> The only alternative for "date" is a proposal called "created", which
>>however doesn't meet the requirements for registration . For our SEO
>>team the date meta-tag contains some of the most important information
>>about a webpage.
>> What would be a w3c-valid way to implement a creation date meta-tag in
>>html5?
>> 
>> 
>> Kind Regards
>> Aykut Sensoy
>


From aykut.sensoy at bild.de  Mon Jul 18 06:59:40 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Mon, 18 Jul 2011 13:59:40 +0000
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <4E2434C9.6050502@gmx.de>
Message-ID: <CA4A0848.10B0F%aykut.sensoy@bild.de>

hi julian,
i have asked one from the seo team and he says for example the "freshness
factor" is important for google.
is it possible to use the time-tag in the head instead (i mean invisible)?
dc:created is also not in the Meta Extensions List, see:
http://wiki.whatwg.org/wiki/MetaExtensions


Kind regards
Aykut



Am 18.07.11 15:27 schrieb "Julian Reschke" unter <julian.reschke at gmx.de>:

>On 2011-07-18 14:54, aykut.sensoy at bild.de wrote:
>> According to the w3c Validator the<metaname="date"content="#" />  tag
>>is invalid. In the WHATWG MetaExtensions List there is no registered
>>extension, no specification and no proposal for the date meta-tag.
>> The only alternative for "date" is a proposal called "created", which
>>however doesn't meet the requirements for registration . For our SEO
>>team the date meta-tag contains some of the most important information
>>about a webpage.
>> What would be a w3c-valid way to implement a creation date meta-tag in
>>html5?
>
>Out of curiosity: who is processing the tag? And what does this have to
>do with SEO? Do search engines do anything with it?
>
> From HTML5's point of view the suggest replace is probably "<time
>pubdate>"... Did you look at that already?
>
>Also: there seems to be overlap with Dublin Core's "dc:created"?
>
>Best regards, Julian


From julian.reschke at gmx.de  Mon Jul 18 07:11:56 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 18 Jul 2011 16:11:56 +0200
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA4A0848.10B0F%aykut.sensoy@bild.de>
References: <CA4A0848.10B0F%aykut.sensoy@bild.de>
Message-ID: <4E243F2C.2040605@gmx.de>

On 2011-07-18 15:59, aykut.sensoy at bild.de wrote:
> hi julian,
> i have asked one from the seo team and he says for example the "freshness
> factor" is important for google.
> is it possible to use the time-tag in the head instead (i mean invisible)?
> dc:created is also not in the Meta Extensions List, see:
> http://wiki.whatwg.org/wiki/MetaExtensions

I *believe* the SEO time is misguided when it thinks that 
meta/@name="date" affects Google. But only Google can tell us.

I mentioned dc:created not because it's valid, but because it's at least 
*specified* and in more wider use.

Best regards, Julian


From karger at mit.edu  Mon Jul 18 07:22:42 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 17:22:42 +0300
Subject: [whatwg] namespaces in html5
In-Reply-To: <Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
Message-ID: <4E2441B2.8040506@mit.edu>

OK, per Ian's suggestion I'm starting a new thread on a problem that I'd 
hoped html5 would solve for us.  As far as I know the problem still 
exists so I'm going to raise it here.  I'm coming late to the discussion 
so will surely retread old territory (for example, 
http://www.pacificspirit.com/blog/2008/03/13/namespaces_in_html_readings); 
my apologies for that.

I am one of the PIs on the SIMILE project (http://simile.mit.edu/) that 
developed the Exhibit data visualization framework 
(http://simile-widgets.org/exhibit).  The goal of Exhibit is to make it 
easy for non-programmers to embed interactive data visualizations in 
their web pages.  Our approach is to leverage the willingness of many 
non-programmers to author html (a key contributor to the early growth of 
the web).  To do so, Exhibit extends the html vocabulary with attributes 
that describe data, visualizations of that data, and interactions with 
that data.  For example, a tag of the form <div ex:role="view" 
ex:viewclass="timeline"> embeds a simile timeline in the html document, 
while <div ex:role="facet"> embeds a facet that can be used to filter 
the data being viewed in the timeline.  Exhibit offers a javascript 
library that interprets these tags and implements the requested widgets 
on the client side.

You will note that our special attributes use an "ex:" prefix.  This 
decision was taken in 2006, when it appeared that prefix-based 
namespaces were in HTML's future.  It addressed our concern that the new 
attributes we defined should not collide with those defined by other 
projects.  Now that namespaces apparently will not be part of html5, we 
are wondering how we can properly offer our extended html vocabulary.  
In particular, seems highly desirable for us to be able to write Exhibit 
pages using html that will validate.  Below I'll outline some of the 
characteristics of our desired solution, while emphasizing that we'd be 
happy to adopt _any_ solution with these characteristics, and are not 
wedded to namespaces.

I first justify our approach of html vocabulary extension.  A programmer 
can argue that a better approach is to offer our javascript library with 
a good api, and allow programmers to invoke our widgets programmatically 
in script tags.  This works fine for programmers, but excludes the large 
population of users who are afraid of programming but are willing to 
fiddle with html.  These users were a potent force in the early days of 
the web and we believe they continue to play an important role.  They 
may not even "know" html; the simplicity and regularity of the syntax 
allows them to copy, paste, and even modify page elements they like 
without fully understanding them.  Specifying data interactions in the 
more restricted html syntax instead of programmatic javascript also 
opens up the possibility for more effective semantics; for example, it 
is easier for a browser to offer an accessible version of a 
data-filtering facet if it is explicitly named as a facet rather than 
being arbitrary embedded javascript code.

If we accept the need for html language extensibility, there are several 
potential approaches.  One is html polyglot.  Permitting a blended 
html/xml representation, polyglot would allow us to extend the 
vocabulary via xml namespaces.  But polyglot fails to meet our need in 
fatal ways.  Polyglot restricts the html that can be used, for example 
excluding the use of <noscript> tags.  Such tags are essential when 
using Exhibit, since we want to offer some information presentation for 
the case when our visualization javascript is unable to execute.  More 
generally, polyglot appears to demand much more rigid fidelity to 
precise html/xml syntax, for example demanding tbody and colgroup tags 
where they are optional in html.  This is something that the novice 
"programmers" we are targeting are particularly bad at.  One of the real 
accomplishments of html has been the great efforts of the browser 
developers to robustly handle invalid html.  We want to continue to 
benefit from that effort instead of having pages fail because xml 
parsing is performed much more rigidly than html parsing.

Another approach would be to use the catchall html5 data- prefix for 
attributes.  We could certainly prefix all of our specialized attributes 
with the data- prefix, which would turn those attributes valid for 
html.  This solution is unsatisfactory for two reasons.  The first is 
that our attributes are not data attributes----we are not using 
microformat-oriented data attributes; rather, we are using attributes 
that describe visualizations.  data- seems a poor choice of prefix.  The 
second problem that concerns me is attribute collisions.  If we use an 
attribute like data-role="view", how long will it be before an exhibit 
author runs into a situation where a different javascript library is 
using the same data-role attribute for a different purpose, which would 
make the two libraries incompatible with one another?

In 2006, the predicted namespace prefixes seemed an obvious solution to 
our problem: we would define a namespace for our Exhibit framework, and 
our javascript would only pay attention to attributes from that 
namespace.  I have no specific loyalty to namespaces, but I am really 
hopeful that html5 will offer us a solution that reflects the issues I 
outlined above, namely:
* allow extension of them html5 vocabulary with attributes Exhibit will 
use to anchor visualizations,
* such that the resulting html will validate,
* without requiring rigid obedience to the challenging html polyglot 
syntax, which is beyond the capabilities of our target novice web authors
* and protecting us from a future in which collisions on choice of 
attribute names make our library/vocabulary incompatible with others'

On 7/18/2011 8:46 AM, Ian Hickson wrote:
> On Mon, 18 Jul 2011, David Karger wrote:
>>    I wish to submit a comment regarding the (non) use of namespaces in
>> html5. But I hope you might help me track down the relevant issue off
>> which to hang that comment.  Some time ago I found a lengthy discussion
>> of whether html5 should use namespaces, with an over-simplified summary
>> being "we haven't seen any important use cases for them, so let's not
>> bother".  I would like to respond to that discussion by proposing a use
>> case, but I cannot find it. Searching the bugzilla database has failed.
>> Would you happen to recall participating in this discussion and know
>> where it is?
> You can just post a new thread here.
>
> I recommend describing the problem you wish to address separately from
> your preferred solution. Also I recommend using a word other than
> "namespaces" to describe your preferred solution, as that word is usually
> used in the Web context to refer to some specific designs with known
> problems, and it is likely that you actually want something different.
>

From annevk at opera.com  Mon Jul 18 07:28:44 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 18 Jul 2011 16:28:44 +0200
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E2441B2.8040506@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu>
Message-ID: <op.vytjt6x264w2qv@annevk-macbookpro.local>

On Mon, 18 Jul 2011 16:22:42 +0200, David Karger <karger at mit.edu> wrote:
> Another approach would be to use the catchall html5 data- prefix for  
> attributes.  We could certainly prefix all of our specialized attributes  
> with the data- prefix, which would turn those attributes valid for  
> html.  This solution is unsatisfactory for two reasons.  The first is  
> that our attributes are not data attributes----we are not using  
> microformat-oriented data attributes; rather, we are using attributes  
> that describe visualizations.  data- seems a poor choice of prefix.  The  
> second problem that concerns me is attribute collisions.  If we use an  
> attribute like data-role="view", how long will it be before an exhibit  
> author runs into a situation where a different javascript library is  
> using the same data-role attribute for a different purpose, which would  
> make the two libraries incompatible with one another?

You could use data-exhibit-* as the specification suggests. Potentially  
including the ability for the web author to override the "exhibit"  
constant.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From hsivonen at iki.fi  Mon Jul 18 07:32:41 2011
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 18 Jul 2011 16:32:41 +0200
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA4A0848.10B0F%aykut.sensoy@bild.de>
References: <CA4A0848.10B0F%aykut.sensoy@bild.de>
Message-ID: <1310999561.2813.4.camel@shuttle>

On Mon, 2011-07-18 at 13:59 +0000, aykut.sensoy at bild.de wrote:
> i have asked one from the seo team and he says for example the "freshness
> factor" is important for google.

Is there evidence of <meta name="date" content="..."> being part of
Google's freshness factor? Is there public documentation explaining what
<meta name="date" content="..."> means, what date format expected in the
content attribute is and what software does something useful with it?

> is it possible to use the time-tag in the head instead (i mean invisible)?

No, it's not.

> dc:created is also not in the Meta Extensions List, see:
> http://wiki.whatwg.org/wiki/MetaExtensions

It simply hasn't been registered yet. Is there any evidence of consuming
software that does something useful with dc:created?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/


From karger at mit.edu  Mon Jul 18 07:33:47 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 17:33:47 +0300
Subject: [whatwg] namespaces in html5
In-Reply-To: <op.vytjt6x264w2qv@annevk-macbookpro.local>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu>
	<op.vytjt6x264w2qv@annevk-macbookpro.local>
Message-ID: <4E24444B.1040109@mit.edu>

Yes, we could,  but it doesn't address the two objections I raised to 
data- prefix:
1.  it isn't actually a data attribute, so prefixing with data seems 
odd (appearance; minor)
2.  there's no way to guarantee someone else won't use the same 
data-exhibit prefix, causing incompatibilities (functionality; major)

On Monday, July 18, 2011 5:28:44 PM, Anne van Kesteren wrote:
> On Mon, 18 Jul 2011 16:22:42 +0200, David Karger <karger at mit.edu> wrote:
>> Another approach would be to use the catchall html5 data- prefix for 
>> attributes. We could certainly prefix all of our specialized 
>> attributes with the data- prefix, which would turn those attributes 
>> valid for html. This solution is unsatisfactory for two reasons. The 
>> first is that our attributes are not data attributes----we are not 
>> using microformat-oriented data attributes; rather, we are using 
>> attributes that describe visualizations. data- seems a poor choice of 
>> prefix. The second problem that concer
ns me is attribute collisions. 
>> If we use an attribute like data-role="view", how long will it be 
>> before an exhibit author runs into a situation where a different 
>> javascript library is using the same data-role attribute for a 
>> different purpose, which would make the two libraries incompatible 
>> with one another?
> 
> You could use data-exhibit-* as the specification suggests. Potentially 
> including the ability for the web author to override the "exhibit" 
> constant.

From annevk at opera.com  Mon Jul 18 07:47:40 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 18 Jul 2011 16:47:40 +0200
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E24444B.1040109@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
Message-ID: <op.vytkpqc664w2qv@annevk-macbookpro.local>

On Mon, 18 Jul 2011 16:33:47 +0200, David Karger <karger at mit.edu> wrote:
> Yes, we could,  but it doesn't address the two objections I raised to  
> data- prefix:
> 1.  it isn't actually a data attribute, so prefixing with data seems odd  
> (appearance; minor)

It is custom data implemented by a JavaScript library. Seems like a  
perfect fit.


> 2.  there's no way to guarantee someone else won't use the same  
> data-exhibit prefix, causing incompatibilities (functionality; major)

"exhibit" plus the ability for authors to configure that word should be  
enough to prevent problems. But I doubt you will get prefix clashes in  
practice.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From ap at webkit.org  Mon Jul 18 08:58:35 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Mon, 18 Jul 2011 08:58:35 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
Message-ID: <0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>


17.07.2011, ? 21:05, Adam Barth ???????(?):

> In summary, using CORS for this purpose is costly (both to
> implementors and to authors), and I don't think it solves a real
> security problem.


Agreed. This feature basically gives authors two abilities: (1) force downloading of resources that would be displayed inline otherwise, and (2) rename them on the fly. Neither is what a site operator adding CORS headers e.g. for WebGL textures would think they're allowing.

A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.

Perhaps an author who has not been given permission to change server HTTP responses is not trusted enough to change them via HTML either. 

- WBR, Alexey Proskuryakov


From jonas at sicking.cc  Mon Jul 18 09:20:13 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 18 Jul 2011 09:20:13 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
Message-ID: <CA+c2ei-9TnVEQDgeJ2wvU4BfW0pSznad1-iOHSULbBUW0Nmaiw@mail.gmail.com>

On Mon, Jul 18, 2011 at 8:58 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> 17.07.2011, ? 21:05, Adam Barth ???????(?):
>
>> In summary, using CORS for this purpose is costly (both to
>> implementors and to authors), and I don't think it solves a real
>> security problem.
>
>
> Agreed. This feature basically gives authors two abilities: (1) force downloading of resources that would be displayed inline otherwise, and (2) rename them on the fly. Neither is what a site operator adding CORS headers e.g. for WebGL textures would think they're allowing.
>
> A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.
>
> Perhaps an author who has not been given permission to change server HTTP responses is not trusted enough to change them via HTML either.

Any site that want to allow downloads without risking sharing data can
simply add "content-disposition: attached" headers. So no risk of
leaking too much data required.

/ Jonas

From glenn at zewt.org  Mon Jul 18 09:35:51 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 18 Jul 2011 12:35:51 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
Message-ID: <CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>

On Mon, Jul 18, 2011 at 11:58 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> A different scenario which I don't think has been discussed in this thread
is bypassing a hosting service security settings. Consider a highly
reputable hosting that doesn't let you upload executable files (or maybe
just scans those for malware if uploaded). With @download, one could bypass
that, and make users download or even run an .EXE file by following an
innocuous link to a well known domain. This kind of download could be same
origin or cross origin.

The service hosting the file--the target of the link--shouldn't convey
trust.  The page containing the download link is where trust should come
from, not the link target.

For example, if I have a link on my site to download Chrome, I'm not going
to link directly to the installer on google.com; I'll link to Google's
"Download Chrome" site.  The actual download link the user follows is not
only pointing to google.com, but is linked from there as well.  I expect
that most users will trust the download not because of where the download
link goes, but where it comes from.

If I link directly to the file to download, users should trust the file as
much as they trust *my* site, rather than Google itself, since the download
is, from their perspective, coming from me and not them.  Similarly, if a
site uses a mysterious CDN or an Amazon S3 link, that shouldn't affect
trust; if www.google.com/chrome puts the file itself on
mysteriousgooglecdn.com, it should be no less trusted than if it was from a
google.com subdomain.  That difference should be transparent to users.

(This is why it's okay that Firefox's open/save dialog shows the link target
in a minor, easily-ignored bit of text--it's not important information for
most users.  Chrome doesn't even show that.)

So, if a hosting service doesn't want to allow executable files, it won't
show files as executable from their own download pages, which is what should
matter as far as that site's trust is concerned.  People using this
mechanism to serve executable files from external links may be annoying, but
it shouldn't cause trust issues.

-- 
Glenn Maynard

From anant at mozilla.com  Mon Jul 18 09:56:26 2011
From: anant at mozilla.com (Anant Narayanan)
Date: Mon, 18 Jul 2011 09:56:26 -0700
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <4E242726.4010701@alvestrand.no>
References: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>
	<4E242726.4010701@alvestrand.no>
Message-ID: <4E2465BA.4070801@mozilla.com>

On 7/18/11 5:29 AM, Harald Alvestrand wrote:
> Additional question:
>
> What is the scenario in which this behavioiur is useful?

One use case is to selectively disable the video track in an ongoing 
audio/video session without disrupting audio in reaction to a congested 
network.

-Anant

From jackalmage at gmail.com  Mon Jul 18 10:53:32 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 18 Jul 2011 10:53:32 -0700
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E24444B.1040109@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
Message-ID: <CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>

On Mon, Jul 18, 2011 at 7:33 AM, David Karger <karger at mit.edu> wrote:
> Yes, we could, ?but it doesn't address the two objections I raised to data-
> prefix:
> 1. ?it isn't actually a data attribute, so prefixing with data seems odd
> (appearance; minor)

You seem to have mentally associated the data-* attributes with
Microdata.  There is no connection between them.  In fact, it's
impossible for Microdata to use the data-* attributes at all.

data-* attributes are for private script data that is, for whatever
reason, more convenient to attach directly to a DOM node than to hold
in a JS structure.  Wanting the data's link to DOM nodes to survive
serialization is a good reason.


> 2. ?there's no way to guarantee someone else won't use the same data-exhibit
> prefix, causing incompatibilities (functionality; major)

In practice, the risk of prefix collisions has turned out to be
minimal in many real-world collections, such as jQuery plugins.  We
expect the same to apply here.  For maximum robustness, simply write
your library with the ability to accept a different prefix, so that if
a collision does occur the author can work around it.

~TJ

From karger at mit.edu  Mon Jul 18 11:23:52 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 21:23:52 +0300
Subject: [whatwg] namespaces in html5
In-Reply-To: <CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu>
	<op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
	<CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>
Message-ID: <4E247A38.4070304@mit.edu>

The html5 spec states that
>
> Custom data attributes 
> <http://dev.w3.org/html5/spec/elements.html#custom-data-attribute> are 
> intended to store custom data private to the page or application, for 
> which there are no more appropriate attributes or elements.
>
> These attributes are not intended for use by software that is 
> independent of the site that uses the attributes.
>
and further
>
> It would be inappropriate, however, for the user to use _generic 
> software not associated with_ that music site to search for tracks of 
> a certain length by looking at this data.
>
> This is because these attributes are intended for use by the site's 
> own scripts, and are not a generic extension mechanism for 
> publicly-usable metadata.
>

As I interpret these words, data- attributes are intended to be 
delivered by a server for use by the javascript code that server 
delivers with the page.

The exhibit attributes are not associated with any server, and are not 
associated with any particular data items being delivered by any 
server.  Rather, they are part of  "generic software not associated 
with" the server (see quote above)  and handle _presentation_ of the 
content on the page.

So, while it might be technically valid to use data- prefixes, it 
doesn't seem to fit the intention.


On 7/18/2011 8:53 PM, Tab Atkins Jr. wrote:
> On Mon, Jul 18, 2011 at 7:33 AM, David Karger<karger at mit.edu>  wrote:
>> Yes, we could,  but it doesn't address the two objections I raised to data-
>> prefix:
>> 1.  it isn't actually a data attribute, so prefixing with data seems odd
>> (appearance; minor)
> You seem to have mentally associated the data-* attributes with
> Microdata.  There is no connection between them.  In fact, it's
> impossible for Microdata to use the data-* attributes at all.
>
> data-* attributes are for private script data that is, for whatever
> reason, more convenient to attach directly to a DOM node than to hold
> in a JS structure.  Wanting the data's link to DOM nodes to survive
> serialization is a good reason.
>
>
>> 2.  there's no way to guarantee someone else won't use the same data-exhibit
>> prefix, causing incompatibilities (functionality; major)
> In practice, the risk of prefix collisions has turned out to be
> minimal in many real-world collections, such as jQuery plugins.  We
> expect the same to apply here.  For maximum robustness, simply write
> your library with the ability to accept a different prefix, so that if
> a collision does occur the author can work around it.
>
> ~TJ

From ian at hixie.ch  Mon Jul 18 11:33:28 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 18:33:28 +0000 (UTC)
Subject: [whatwg] Muting MediaStreamTracks?
In-Reply-To: <CALLKCfMV=D-ojvdsu1jicDu-TXqLTeO_imqgo8_QLzRN+JDWwg@mail.gmail.com>
References: <CALLKCfMV=D-ojvdsu1jicDu-TXqLTeO_imqgo8_QLzRN+JDWwg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107181831590.3775@ps20323.dreamhostps.com>

On Mon, 18 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
>
> The latest version of the spec mentions muting in several places, for 
> example:
> 
>  (Merely muted tracks are not removed, so the tracks do not change when 
> the parent is finished.)
> 
> But there are no mute operators in the idl definitions... How is the 
> mute function supposed to work?

A MediaStream object has an input and an output. The input depends on how 
the object was created: a LocalMediaStream object generated by a 
getUserMedia() call, for instance, might take its input from the user's 
local camera, while a MediaStream created by a PeerConnection object will 
take as input the data received from a remote peer. The output of the 
object controls how the object is used, e.g. what is saved if the object 
is written to a file, what is displayed if the object is used in a video 
element, or indeed what is transmitted to a remote peer if the object is 
used with a PeerConnection object.

Each track in a MediaStream object can be disabled, meaning that it is 
muted in the object's output. All tracks are initially enabled.

A MediaStream can be finished, indicating that its inputs have forever 
stopped providing data. When a MediaStream object is finished, all its 
tracks are muted regardless of whether they are enabled or disabled.

The MediaStreamTrack.enabled attribute, on getting, must return the last 
value to which it was set. On setting, it must be set to the new value, 
and then, if the MediaStreamTrack object is still associated with a track, 
must enable the track if the new value is true, and disable it otherwise.

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

From ian at hixie.ch  Mon Jul 18 11:38:52 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 18:38:52 +0000 (UTC)
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <4E242D26.3030401@alvestrand.no>
References: <4E242D26.3030401@alvestrand.no>
Message-ID: <Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>

On Mon, 18 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
>
> I am very confused regarding the below paragraph from the latest spec:
> 
> When a track in a MediaStream parent is disabled, any MediaStreamTrack 
> objects corresponding to the tracks in any MediaStream objects that were 
> created from parent are disassociated from any track, and must not be 
> reused for tracks again. If a disabled track in a MediaStream parent is 
> re-enabled, from the perspective of any MediaStream objects that were 
> created from parent it is a new track and thus new MediaStreamTrack 
> objects must be created for the tracks that correspond to the re-enabled 
> track.
> 
> After cloning a LocalMediaStream it looks like this:
> 
> LocalMediaStream -> MediaStream1
> Track1(E)           Track1(E)
> Track2(E)           Track2(E)
> Track3(E)           Track3(E)
> 
> and as I interpret the spec it looks like this if Track1 in the 
> LocalMediaStream is disabled:
> 
> LocalMediaStream -> MediaStream1
> Track1(D)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)

Correct so far (though I'd avoid the term "cloning" since it's not quite 
what's going on here -- the spec uses "forking", which may be closer 
though is still not ideal).


> So Track1 disappears from the MediaStream1 object and doesn't come back 
> even if Track1 in the LMS object is enabled:
>
> LocalMediaStream -> MediaStream1
> Track1(E)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)

No, it'll create a new track object:

 LocalMediaStream -> MediaStream1
 Track1(E)           Track4(E)
 Track2(E)           Track2(E)
 Track3(E)           Track3(E)

This is specified in the sentence that starts "If a disabled track in a 
MediaStream parent is re-enabled...".

If you could explain how you are interpreting the current text I would be 
happy to fix the problematic area to be clearer (it's not clear to me 
what's unclear at the moment).


On Mon, 18 Jul 2011, Harald Alvestrand wrote:
> 
> What is the scenario in which this behavioiur is useful?

The muting feature exists in order to allow authors to mute outgoing video 
while leaving outgoing audio and while still having a local video montior.

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

From Simetrical+w3c at gmail.com  Mon Jul 18 12:20:21 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 18 Jul 2011 15:20:21 -0400
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E24444B.1040109@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
Message-ID: <CAKA+Axk1KiQxGMPB-udnZxr9mTusHpkK1vFc5BmGXE3_EhcH2A@mail.gmail.com>

On Mon, Jul 18, 2011 at 10:33 AM, David Karger <karger at mit.edu> wrote:
> Yes, we could, ?but it doesn't address the two objections I raised to data-
> prefix:
> 1. ?it isn't actually a data attribute, so prefixing with data seems odd
> (appearance; minor)

It's "data" in the sense that it's being used to just store some info
in the DOM without asking the browser to do anything extra with it.

> 2. ?there's no way to guarantee someone else won't use the same data-exhibit
> prefix, causing incompatibilities (functionality; major)

There's also no way to guarantee someone else won't use the same URL
for their namespace.  But in either case, they almost certainly won't.
 If you're really paranoid, feel free to stick a GUID or domain name
or something inside the names of all your data attributes.  But the
probability data-exhibit-* will ever collide with anything is already
negligible.

On Mon, Jul 18, 2011 at 2:23 PM, David Karger <karger at mit.edu> wrote:
> As I interpret these words, data- attributes are intended to be delivered by
> a server for use by the javascript code that server delivers with the page.
>
> The exhibit attributes are not associated with any server, and are not
> associated with any particular data items being delivered by any server.
> ?Rather, they are part of ?"generic software not associated with" the server
> (see quote above) ?and handle _presentation_ of the content on the page.
>
> So, while it might be technically valid to use data- prefixes, it doesn't
> seem to fit the intention.

I don't get how you're using these attributes.  Do you expect
browsers, search engines, or other consumers of HTML to treat them
differently from any unrecognized attribute?  Or do you intend that
the attributes only be used by the scripts/stylesheets/etc. provided
by your own site?  If your use-case is the former, then you should
propose the attributes for standardization.  If the latter, it's
exactly what data-* was designed for.

From jackalmage at gmail.com  Mon Jul 18 12:29:07 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 18 Jul 2011 12:29:07 -0700
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E247A38.4070304@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
	<CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>
	<4E247A38.4070304@mit.edu>
Message-ID: <CAAWBYDA4xEK_C0rs6On=dZEuo97wOceJfEsf7UwX4UcpG=TkTw@mail.gmail.com>

On Mon, Jul 18, 2011 at 11:23 AM, David Karger <karger at mit.edu> wrote:
> The exhibit attributes are not associated with any server, and are not
> associated with any particular data items being delivered by any server.
> Rather, they are part of? "generic software not associated with" the server
> (see quote above)? and handle _presentation_ of the content on the page.
>
> So, while it might be technically valid to use data- prefixes, it doesn't
> seem to fit the intention.

As far as I can tell, the exhibit attributes are designed solely to be
read by the exhibit JS library which creates special views of the
data.  The site embeds that library, and so it's part of the site.

The restrictions there are meant to restrict things like, for example,
embedding Microformats data with data-* attributes, with the intention
that they'll be read by spiders and other things outside of the page
author's control.

~TJ

From jackalmage at gmail.com  Mon Jul 18 13:01:37 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 18 Jul 2011 13:01:37 -0700
Subject: [whatwg] Microdata - Handling the case where a string is
 upgraded to an object
In-Reply-To: <op.vyta3xunsr6mfa@kirk>
References: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
	<op.vyta3xunsr6mfa@kirk>
Message-ID: <CAAWBYDC1z2HFrjxk5bqwA80+9mj3Awkx9=BZWsoKHvPDudxP2w@mail.gmail.com>

On Mon, Jul 18, 2011 at 4:20 AM, Philip J?genstedt <philipj at opera.com> wrote:
> There is no items IDL attribute, do you mean getItems() or .itemValue
> perhaps?

Yes, sorry.


> I take it the problem is with code like this:
>
> <div itemscope itemtype="person"><span itemprop="name">Foo
> Barsson</span></div>
> <script>
> var p = document.getItems("person")[0];
> alert(p.properties.namedItem("name")[0].itemValue);
> </script>
>
> If the HTML changes to
>
> <div itemscope itemtype="person"><span itemprop="name" itemscope><span
> itemprop="givenName">Foo</span> <span
> itemprop="familyName">Barsson</span></span></div>
>
> then the script would be alerting "[object HTMLElement]" instead of "Foo
> Barsson".
>
> I'm not sure why this would be a problem. If someone changes the page, then
> can't they adjust the script to match?

That only works if the page is using its own Microdata, not if someone
else is consuming the Microdata.

> Is it extensions and libraries that
> you're worried about?

Yeah.  I suspect this kind of API change is relatively common, and
it's the sort of thing that would *always* be painful.

> As for the solution, are you suggesting that .itemValue return a special
> object which is like HTMLElement in all regards except for how it
> toString()s?

Yes.

~TJ

From ian at hixie.ch  Mon Jul 18 14:13:42 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 21:13:42 +0000 (UTC)
Subject: [whatwg] onForward and onBackward event and enable/disable
 Forward and Backward buttons.
In-Reply-To: <BANLkTikXzXygnh2PSaSe55fNOdCix_iJTw@mail.gmail.com>
References: <BANLkTi=mxPQnOZDtKDoc6ZeU2SwGXyDT4Q@mail.gmail.com>
	<1302966847.3322.12.camel@localhost.localdomain>
	<BANLkTikXzXygnh2PSaSe55fNOdCix_iJTw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107182112210.2079@ps20323.dreamhostps.com>

On Sat, 16 Apr 2011, Biju wrote:
> 
> So I want to suggest we should add onBackward and onForward events for
> a page which will be triggered when user click the Backward  or
> Forward button.

We essentially already have this ability using onpopstate and 
onhashchange. It lets authors hook into the session history and makes 
things work. Before we add more features along these lines, we should wait 
to see how authors are adopting the feature we already have.

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

From dglazkov at chromium.org  Mon Jul 18 19:55:20 2011
From: dglazkov at chromium.org (Dimitri Glazkov)
Date: Mon, 18 Jul 2011 19:55:20 -0700
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <op.vw8kp9oate2ec8@aimac.local>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
Message-ID: <CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>

I actually really like this proposal.

Let's do this. Roland, Dave, Boris -- what do y'all think?

:DG<

On Fri, Jun 17, 2011 at 1:04 PM, Kornel Lesi?ski <kornel at geekhood.net> wrote:
> On Thu, 16 Jun 2011 19:32:42 +0100, Dimitri Glazkov <dglazkov at chromium.org>
> wrote:
>
>> What if we do this:
>>
>> 1) By default, <style scoped> implies that all selectors in this
>> stylesheet are prefixed with ":scope".
>> 2) Unless the ":scope" is already in the selector.
>
> That feels magical and a bit backwards to me.
>
> Why not scope all selectors except ones starting with :root?
>
> .foo {scoped}
>
> :root .foo {matches outside scope}
>
> --
> regards, Kornel Lesi?ski
>

From bzbarsky at MIT.EDU  Mon Jul 18 20:40:44 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 18 Jul 2011 23:40:44 -0400
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>	<4DF9C8C9.3090805@lachy.id.au>	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
Message-ID: <4E24FCBC.6060402@mit.edu>

On 7/18/11 10:55 PM, Dimitri Glazkov wrote:
> I actually really like this proposal.
>
> Let's do this. Roland, Dave, Boris -- what do y'all think?

The proposal being that all selectors are scoped except the ones where 
:root is present in the first sequence of simple selectors (not quite 
what Kornel said, but I think that's what he meant)?

That seems ok to me, I think.  David, thoughts?

-Boris

From rolandsteiner at google.com  Mon Jul 18 21:10:16 2011
From: rolandsteiner at google.com (Roland Steiner)
Date: Tue, 19 Jul 2011 13:10:16 +0900
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E24FCBC.6060402@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
Message-ID: <CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>

On Tue, Jul 19, 2011 at 12:40 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/18/11 10:55 PM, Dimitri Glazkov wrote:
>
>> I actually really like this proposal.
>>
>> Let's do this. Roland, Dave, Boris -- what do y'all think?
>>
>
> The proposal being that all selectors are scoped except the ones where
> :root is present in the first sequence of simple selectors (not quite what
> Kornel said, but I think that's what he meant)?
>
> That seems ok to me, I think.  David, thoughts?
>

Just to nail this down:

foo .bar
    scoped, foo must be the scope element or a descendant

:root foo .bar
    NOT scoped, foo can be matched outside the scope

html foo .bar
    scoped, will not match, unless <html> element itself somehow becomes the
scoping element (can this happen?)

body foo .bar
    scoped, will potentially match only if <style scoped> is a direct child
of <body> (thus <body> becoming the scoping element)

html:root foo .bar
    NOT scoped due to the presence of :root in the first sequence (even
though not absolutely the first simple selector)

Seems reasonable, except there may be the question why it "works" with
:root, but not with 'html' or 'body', but I guess that can be explained.


Cheers,

- Roland

From bzbarsky at MIT.EDU  Mon Jul 18 21:14:55 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 19 Jul 2011 00:14:55 -0400
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
Message-ID: <4E2504BF.70504@mit.edu>

On 7/19/11 12:10 AM, Roland Steiner wrote:
> Just to nail this down:
>
> foo .bar
>      scoped, foo must be the scope element or a descendant

This is actually an interesting question.  Does this end up 
corresponding to:

   :scope foo .bar, foo:scope .bar

or to just

   :scope foo .bar

?  The latter would not match on 'foo' being the scope element, while 
the former would.

> html foo .bar
>      scoped, will not match, unless <html> element itself somehow
> becomes the scoping element (can this happen?)

I'd think so; you can always insertBefore a <style> element as a child 
of <html>.

> body foo .bar
>      scoped, will potentially match only if <style scoped> is a direct
> child of <body> (thus <body> becoming the scoping element)

Assuming there's no interesting DOM manipulation adding multiple 
HTMLBodyElement elements to the page, etc.

-Boris

From rolandsteiner at google.com  Mon Jul 18 21:30:02 2011
From: rolandsteiner at google.com (Roland Steiner)
Date: Tue, 19 Jul 2011 13:30:02 +0900
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E2504BF.70504@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
Message-ID: <CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>

On Tue, Jul 19, 2011 at 1:14 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/19/11 12:10 AM, Roland Steiner wrote:
>
>> Just to nail this down:
>>
>> foo .bar
>>     scoped, foo must be the scope element or a descendant
>>
>
> This is actually an interesting question.  Does this end up corresponding
> to:
>
>  :scope foo .bar, foo:scope .bar
>
> or to just
>
>  :scope foo .bar
>

I think one could argue for either case. Personally, I think it's
advantageous to include the scoping element (i.e., use ":scope foo .bar,
foo:scope .bar"), in order to be able to do style the scoping element itself
rather than its children individually, e.g.

:scope { background-color: mauve; }

This otherwise would be impossible in the given proposal, without resorting
to either a) add :root for no semantic reason or b) wrap the contents of the
scoping element within another element, just to be able to style it.


- Roland

From per-erik.brodin at ericsson.com  Tue Jul 19 01:17:55 2011
From: per-erik.brodin at ericsson.com (Per-Erik Brodin)
Date: Tue, 19 Jul 2011 10:17:55 +0200
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
Message-ID: <4E253DB3.6000602@ericsson.com>

On 2011-07-14 00:39, Ian Hickson wrote:
> In response to off-list feedback, I've renamed StreamTrack to
> MediaStreamTrack to be clearer about its relationship to the other
> interfaces.

Perhaps now that there is no longer any relation to tracks on the media 
elements we could also change Track to something else, maybe Component. 
I have had people complaining to me that Track is not really a good name 
here.

> On Wed, 8 Jun 2011, Per-Erik Brodin wrote:
>>
>> The TrackList feature seems to be a good way to control the different
>> components of a Stream. Although it is said that tracks provide a way to
>> temporarily disable a local camera, due to the nature of the
>> ExclusiveTrackList it is still not possible to disable video altogether,
>> i.e. to 'pull down the curtain' in a video conference. I noticed that
>> there is a bug filed on this issue but I do not think the proposed
>> solution there is quite right. There is a state in which no tracks are
>> selected in an ExclusiveTrackList, when the selected index returned is
>> -1. A quick fix would be to allow also setting the active track to -1 in
>> order to deselect all the other tracks.
>
> This is fixed now, hopefully. Let me know if the fix is not sufficient.
>
> (I replaces the videoTracks and audioTracks lists with a single tracks
> list in which you can enable and disable individual tracks.)

Good. Could we still keep audio and video in separate lists though? It 
makes it easier to check the number of audio or video components and you 
can avoid loops that have to check the kind for each iteration if you 
only want to operate on one media type. I also think that it would be 
easier to construct new MediaStream objects from individual components 
rather than temporarily disabling the ones you do not want to copy to 
the new MediaStream object and then re-enabling them again afterwards. 
It is also unclear to me what happens to a LocalMediaStream object that 
is currently being consumed in that case.

Why should the label the same as the parent on the newly constructed 
MediaStream object? If you send two MediaStream objects constructed from 
the same LocalMediaStream over a PeerConnection there needs to be a way 
to separate them on the receiving side. I also think it is a bit 
unfortunate that we now have a 'label' property on the track objects 
that means something else than the 'label' property on MediaStream, 
perhaps 'description' would be a more suitable name for the former.

>> We prefer having a StreamRecorder that you have to stop in order get the
>> recorded data (like the previous one, but with asynchronous Blob retrieval)
>> and we do not understand the use cases for the current proposal where
>> recording continues until the recorder is garbage collected (or the Stream
>> ends) and you always get the data from the beginning of the recording. This
>> also has to be tied to application quota in some way.
>
> The current design is just the result of needing to define what happens
> when you call getRecordedData() twice in a row. Could you elaborate on
> what API you think we should have?

What I am thinking of is something similar to what was proposed in
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030921.html
although that does not take quota into account. Preferably quota should 
be expressed in media time and that is heavily dependent on the format 
being used and, regardless of any codecs, I still think that the format 
has to be specified somehow. Perhaps it would be best to push recording 
to v2 since this does not seem to be the primary use case for people 
currently showing the most interest in this part of the spec.

>> Instead of blob: we would like to use stream: for the Stream URLs so
>> that we very early on in the media engine selection can use the protocol
>> scheme to determine how the URL will be handled. Blobs are typically
>> handled in the same way as other media playback. The definition of
>> stream: could be the same as for blob:.
>
> Why can't the UA know which blob: URLs point to streams and which point to
> blobs?

I was not saying that it would not be possible to keep track of which 
blob: URLs that point to blobs and which point to streams just that we 
want to avoid doing that in the early stage of the media engine 
selection. In my opinion a stream is quite the opposite of a blob 
(unknown, perhaps infinite length vs. fixed length) so when printing the 
URLs for debugging purposes it would also be much nicer to have two 
different protocol schemes. If I remember correctly the discussions 
leading up to the renaming of createBlobURL to createObjectURL assumed 
that there would be stream: URLs.

> Actually, the spec doesn't currently say anything happens when a stream
> that is being transmitted just ends, either. I guess I should spec that...
>
> ...ok, now the spec is clear that an ended stream transmits blackness and
> silence. Same with if some tracks are disabled. (Blackness only if there's
> a video track; silence only if there's an audio track.)

OK, I guess that could work. In that case you have to manually remove 
the stream from being sent over a PeerConnection if it unexpectedly 
ends. Should playing back an ended stream locally in a video element 
also produce silence and blackness then? We have been assuming network 
error which has the nice consequence that you can discard ended streams 
that are only reachable by their stream: URLs even if the URLs are not 
revoked since trying to play back such a stream: URL is 
indistinguishable from trying to play back an invalid stream: URL, in 
that case.

>> PeerConnection is an EventTarget but it still uses a callback for the
>> signaling messages and this mixture of events and callbacks is a bit
>> awkward in my opinion. If you would like to change the function that
>> handles signaling messages after calling the constructor you would have
>> to wrap a function call inside the callback to the actual signal
>> handling function, instead of just (re-)setting an onsignal (or
>> whatever) attribute listener (the event could reuse the MessageEvent
>> interface).
>
> When would you change the callback?

If you would like to send the signaling messages peer-to-peer over the 
data channel, once it is established.

>
> My concern with making the callback an event handler is that it leads to a
> set of poor failure modes and complications in the API:
>
>   - It's easy to not register a callback, which makes no sense. There's
>     literally never a use for create a PeerConnection without a signaling
>     channel, as far as I can tell, so making it easier to create one
>     without a callback than with seems like a bad design.

I think this is the case for many APIs. For example, creating an 
EventSource without registering any listener for incoming events equally 
does not make sense. With the same reasoning we should force such a 
handler to be passed to the EventSource constructor. I think the author 
will figure out and learn rather quickly which events that need to be 
handled.

>   - It's easy to register multiple callbacks. This equally makes no sense,
>     and would likely only ever be the source of bugs.

Yes it would be possible but I am not sure that it would be any easier 
to make such a mistake than to make any other mistake that would cause 
the application to malfunction. I was under the impression that most 
people use attribute event listeners anyway.

>   - It makes getting the data more complicated. Instead of passing the
>     callback the string to send, we end up passing an object which has on
>     it one attribute that contains the string.

Yeah, if getting 'event.data' is more complicated than just getting 
'data'. To get the incoming stream from a StreamEvent (should probably 
be renamed to MediaStreamEvent for consistency) the author would have to 
know how to do this anyway.

>> There is a potential problem in the exchange of SDPs in that glare
>> conditions can occur if both peers add streams simultaneously, in which
>> case there will be two different outstanding offers that none of the
>> peers are allowed to respond to according to the SDP offer-answer model.
>> Instead of using one SDP session for all media as the specification
>> suggests, we are handling the offer-answer for each stream separately to
>> avoid such conditions.
>
> Why isn't this handled by the ICE role conflict processing rules? It seems
> like simultaneous ICE restarts would be trivially resolvable by just
> following the rules in the ICE spec. Am I missing something?

This problem is not related to ICE but rather to the SDP offer-answer 
model which is separate from the ICE processing. The problem is that SDP 
offer-answer does not allow you to respond to an offer when you have an 
outstanding offer for the same set of streams. The way we are avoiding 
this is by sending SDP fragments (only the SDP lines related to the 
affected stream) rather than the full SDP each time.

//Per-Erik


From mercator+whatwg at gmail.com  Tue Jul 19 01:54:49 2011
From: mercator+whatwg at gmail.com (Jorrit Vermeiren)
Date: Tue, 19 Jul 2011 10:54:49 +0200
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
	<9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
	<CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
Message-ID: <CAOV4gmpZgq=Ybu9WqRmQM19Y_vtQK2ZWvVJ+dHALkKCRr-pLQQ@mail.gmail.com>

On Thu, Jul 14, 2011 at 22:48, Tantek ?elik <tantek at cs.stanford.edu> wrote:
> On Thu, Jul 14, 2011 at 12:35, Karl Dubost <karld at opera.com> wrote:
>> I like the pattern id/for pattern of forms. We could imagine
>>
>> <p>
>> <span for="quoteA" class="author">Sir John Typo</span>
>> has written plenty of a wonderful thing
>> in <cite for="quoteA">Amazing title</cite> very similar to those in
>> <span for="quoteB" class="author">Susan Spellchecker</span>'s writings
>
> I really like this pattern.
>
> <label for="input-id"> is a known working and in use pattern.

It is a known working pattern because it actually has a direct effect
on the UI, not because for+id is somehow more intuitive than its
inverse, id+cite, which is currently not being used. It makes the
label act as a click target for its associated input element, which is
especially useful for radio buttons and checkboxes. That's the reason
why I've used it, in any case, not because I wanted to be semantic in
any way.

Jorrit

From tkent at chromium.org  Tue Jul 19 03:40:06 2011
From: tkent at chromium.org (TAMURA, Kent)
Date: Tue, 19 Jul 2011 19:40:06 +0900
Subject: [whatwg] Placeholder visibility on focus
Message-ID: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>


http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute
> ?User agents should present this hint to the user, after having?stripped
> line breaks?from it,
> when the element's?value?is the empty string and the control is not
> focused (e.g. by
> displaying it inside a blank unfocused control).

I'd like to propose to change this part so that we allow UAs to show
placeholder text even if the control is focused.

* This behavior might depend on platforms.
    The password field of Windows 7 logon screen shows placeholder text when
the field is focused.

* autofocus + placeholder is useless in the current specification.

--
TAMURA Kent
Software Engineer, Google




From thomas at webtypes.com  Tue Jul 19 03:55:38 2011
From: thomas at webtypes.com (Thomas Maas)
Date: Tue, 19 Jul 2011 12:55:38 +0200
Subject: [whatwg] Placeholder visibility on focus
In-Reply-To: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
References: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
Message-ID: <CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>

Agreed,

instead of checking for an empty string *and* focus the user agent should just check for an empty string.

current spec:
when the element's value is the empty string and the control is not focused (e.g. by displaying it inside a blank unfocused control)

proposed spec:
when the element's value is the empty string (e.g. by displaying it inside a blank control)

Motivations:

1) autofocus + placeholder is useless in current spec
2) a placeholder is supposed to give a hint. It's not logical to hide the hint before you actually add content. As the act of adding content probably means you understood the hint, not the act of focussing.


- Thomas Maas

-- 
Webtypes
Thomas Maas
email: thomas at webtypes.com
twitter: @thomasmaas
skype: thomasmaas

On Jul 19, 2011, at 12:40 , TAMURA, Kent wrote:

> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute
>>  User agents should present this hint to the user, after having stripped
>> line breaks from it,
>> when the element's value is the empty string and the control is not
>> focused (e.g. by
>> displaying it inside a blank unfocused control).
> 
> I'd like to propose to change this part so that we allow UAs to show
> placeholder text even if the control is focused.
> 
> * This behavior might depend on platforms.
>   The password field of Windows 7 logon screen shows placeholder text when
> the field is focused.
> 
> * autofocus + placeholder is useless in the current specification.
> 
> --
> TAMURA Kent
> Software Engineer, Google
> 
> 
> 







From tyoshino at google.com  Tue Jul 19 04:16:27 2011
From: tyoshino at google.com (Takeshi Yoshino)
Date: Tue, 19 Jul 2011 20:16:27 +0900
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
Message-ID: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>

Hi,

Use of deflate-stream is now mandatory in API spec. I think this kind of
requirement is useless. How about leave it up to implementors' decision?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

Adrian first brought this up on bugzilla for discussion. I'd like to ask
opinions from whatwg.

----

First, what effect specifying /extensions/ has is not yet clear for
client-side. Is this process intended to completely specify the set of
extensions wire-protocol uses? It's strange since we're going to introduce
multiplexing which is by nature not fully under control of JavaScript.

/extensions/ like this can be a hint, suggestion or request for
wire-protocol layer. According to Hixie's post (
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917#c5) here it's used as
mandatory extension request i.e. prohibiting WebSocket w/o deflate-stream
for browsers (but some other extensions can be added in wire-protocol
level).

----

I think this requirement doesn't really help us enforce endpoints
initiate/accept WebSocket with the same configuration. Because

- non-browser UAs are free to be implemented without deflate-stream
- server developers would see/care only the wire protocol spec

So, server developers would simply make their implementation accept both
requests with and without deflate-stream, I think. It's not likely that
server implementors are influenced by "the WebSocket API" and have their
server check if a UA is browser or not and reject requests w/o
deflate-stream. The only people who benefit from this requirement is those
who implement a server only for their own use and are not interested in
serving non-browser clients.

Even for such people, I think it's easier to debug and straightforward that
they implement one without deflate-stream and then with deflate-stream, and
then just leave both available. I can't imagine servers that has solid
implementation for deflate-stream but not for w/o deflate-stream. So,

- as most of servers support WebSocket w/o deflate-stream, no one would face
any difficulties to get their client implementation live
without deflate-stream
- usually both API and wire-protocol are implemented together by the same
person/vendor

Because of these two points, as a result, even clients can be easily ignore
this requirement.

Let keep wire-protocol level stuff handled by IETF.

Regards,
Takeshi

From bzbarsky at MIT.EDU  Tue Jul 19 06:11:34 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 19 Jul 2011 09:11:34 -0400
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
	<CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
Message-ID: <4E258286.7020602@mit.edu>

On 7/19/11 12:30 AM, Roland Steiner wrote:
> I think one could argue for either case. Personally, I think it's
> advantageous to include the scoping element (i.e., use ":scope foo .bar,
> foo:scope .bar"), in order to be able to do style the scoping element
> itself rather than its children individually, e.g.
>
> :scope { background-color: mauve; }

Hmm.  I agree this is a useful thing to do, but perhaps it's better 
accomplished by not prepending ":scope " to selectors which have a 
:scope in the first sequence of simple selectors in addition to ones 
that have :root there?

This would still not make "foo .bar" match if the scope is a foo, but 
would we actually want to match?

-Boris

From jackalmage at gmail.com  Tue Jul 19 08:47:47 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 19 Jul 2011 08:47:47 -0700
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E258286.7020602@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
	<CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
	<4E258286.7020602@mit.edu>
Message-ID: <CAAWBYDCO0DtyQ0S3oF=F8pS=0zEUCRpRV3Ou8eNcQu3Y-FVBrw@mail.gmail.com>

On Tue, Jul 19, 2011 at 6:11 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/19/11 12:30 AM, Roland Steiner wrote:
>>
>> I think one could argue for either case. Personally, I think it's
>> advantageous to include the scoping element (i.e., use ":scope foo .bar,
>> foo:scope .bar"), in order to be able to do style the scoping element
>> itself rather than its children individually, e.g.
>>
>> :scope { background-color: mauve; }
>
> Hmm. ?I agree this is a useful thing to do, but perhaps it's better
> accomplished by not prepending ":scope " to selectors which have a :scope in
> the first sequence of simple selectors in addition to ones that have :root
> there?
>
> This would still not make "foo .bar" match if the scope is a foo, but would
> we actually want to match?

I think it's best for that case to *not* match.  Otherwise, you have
to explicitly remember to add a :not(:scope) to every rule that might
match the scoping element.

It's very easy to style the scoping element by using :scope explicitly.

~TJ

From philipj at opera.com  Tue Jul 19 09:00:07 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Tue, 19 Jul 2011 18:00:07 +0200
Subject: [whatwg] Microdata - Handling the case where a string is
 upgraded to an object
In-Reply-To: <CAAWBYDC1z2HFrjxk5bqwA80+9mj3Awkx9=BZWsoKHvPDudxP2w@mail.gmail.com>
References: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
	<op.vyta3xunsr6mfa@kirk>
	<CAAWBYDC1z2HFrjxk5bqwA80+9mj3Awkx9=BZWsoKHvPDudxP2w@mail.gmail.com>
Message-ID: <op.vyviqhu7sr6mfa@kirk>

On Mon, 18 Jul 2011 22:01:37 +0200, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Mon, Jul 18, 2011 at 4:20 AM, Philip J?genstedt <philipj at opera.com>

>> As for the solution, are you suggesting that .itemValue return a special
>> object which is like HTMLElement in all regards except for how it
>> toString()s?
>
> Yes.

Currently, it's spec'd as returning the element itself. This isn't  
terribly useful, at least I've just checked e.itemScope and then accessed  
e.properties directly rather than going through e.itemValue.properties.  
Given this, a simpler fix would be to let .itemValue act like .textContent  
when an itemscope attribute is present.

Still, I'm not sure if it's a good idea. It makes the Microdata model kind  
of odd if a property is both an item and has a fallback text  
representation. It will also mask the fact that a text property has been  
upgraded to an item, somewhat decreasing the chance that the consuming  
code will be updated.

-- 
Philip J?genstedt
Core Developer
Opera Software

From darin at apple.com  Tue Jul 19 10:12:47 2011
From: darin at apple.com (Darin Adler)
Date: Tue, 19 Jul 2011 10:12:47 -0700
Subject: [whatwg] Placeholder visibility on focus
In-Reply-To: <CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>
References: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
	<CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>
Message-ID: <2D70BBA5-0742-4B0E-9521-D1D3D6CDC0CE@apple.com>

On Jul 19, 2011, at 3:55 AM, Thomas Maas wrote:

> instead of checking for an empty string *and* focus the user agent should just check for an empty string.

I think that for some user agents, whether the placeholder text is shown when the field is focused should depend on platform behavior.

For example, Safari has one behavior on Snow Leopard and a different behavior on Lion and I think that is a good thing.

    -- Darin


From ap at webkit.org  Tue Jul 19 10:42:07 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Tue, 19 Jul 2011 10:42:07 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
Message-ID: <D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>


18.07.2011, ? 9:35, Glenn Maynard ???????(?):

> > A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.
> 
> The service hosting the file--the target of the link--shouldn't convey trust.  The page containing the download link is where trust should come from, not the link target.


There are many views on what conveys trust. If we don't go to the extremes (like users who click on anything and agree to any confirmation dialogs without reading them), there is certainly a group of people who look where a link points to before clicking it.

The fact that hosting implies a certain degree of trust is also built into client software. For example, if you download an executable file on Mac OS X, then the system warns you about it on first launch, and tells you where it was downloaded from, not where a link to the download was.

Hosting services do have their policies on what can be hosted. As we discuss a way to subvert those policies, we shouldn't start with an assumption that it's inconsequential.

- WBR, Alexey Proskuryakov


From ian at hixie.ch  Tue Jul 19 12:42:45 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Jul 2011 19:42:45 +0000 (UTC)
Subject: [whatwg] Specification of window.find()
In-Reply-To: <BANLkTinMC95+_orq-qrwQ6tdB3NVdj5Pfw@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<4D2715D8.2020102@nokia.com>
	<Pine.LNX.4.64.1105022340110.19153@ps20323.dreamhostps.com>
	<4DBFC066.4030206@nokia.com>
	<BANLkTinMC95+_orq-qrwQ6tdB3NVdj5Pfw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107182154220.2079@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Benjamin Poulain wrote:
> On 05/03/2011 01:42 AM, ext Ian Hickson wrote:
> > > I do not know the original use case but I can think of a few: -on 
> > > mobile devices which have a find dialog but no user interface to 
> > > access it, make the find dialog appear
> > 
> > Are there pages that do this today? Or indeed any UAs that have a find 
> > dialog but no UI to access it? [...]
> 
> I don't really have an interest in defending the feature.
> 
> I was just hoping to get a specification for the API to get a bit more 
> consistency between engines.
> 
> Since you do not seem interested in the feature, I guess we can keep it 
> as a WebKit/Gecko extension.

What would be even better is if WebKit and Gecko could just drop support 
for the feature altogether, if there are no compelling use cases for it, 
no compat need, and nobody is interested in defending the feature.

But if there is a need, that's a different matter:

On Thu, 5 May 2011, Hallvord R M Steen wrote:
> 
> Opera is regularly nagged by rich text editor authors who would like us 
> to support window.find(). Since it seems to be a requested feature, it 
> would be nice to have a proper spec ;-)
>
> I guess that one of the main use cases indeed is to be able to highlight 
> search hits inside a single frame (using the browser's built-in search 
> might highlight hits both in a rich text editor's UI and the document 
> you're editing, which would be confusing)..
>
> Yes, it is a counter-argument that authors could write their own 
> implementation. However, it's non-trivial to write a good text find 
> implementation in JS - it needs to handle text wrapping, text that is 
> split across different text nodes or tags, HTML entities, soft hyphens, 
> BiDi and probably a lot of issues I'm not aware of. It's a lot simpler 
> to let the JS author hook into the UA's presumably superior and better 
> tested algorithm.

In investigating this further, I've found that window.find() is not 
especially interoperably implemented. I've filed bugs on the two browsers 
that implement it to investigate what we can do about it:

   https://bugzilla.mozilla.org/show_bug.cgi?id=672395
   https://bugs.webkit.org/show_bug.cgi?id=64761

I've also added a placeholder to the spec for this feature.

Depending on how these bugs go, I'll either fill in the spec to one extent 
or another, or remove the section altogether.

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

From thomas at webtypes.com  Tue Jul 19 12:43:41 2011
From: thomas at webtypes.com (Thomas Maas)
Date: Tue, 19 Jul 2011 21:43:41 +0200
Subject: [whatwg] Placeholder visibility on focus
In-Reply-To: <2D70BBA5-0742-4B0E-9521-D1D3D6CDC0CE@apple.com>
References: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
	<CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>
	<2D70BBA5-0742-4B0E-9521-D1D3D6CDC0CE@apple.com>
Message-ID: <5A5BC940-1B49-496D-A377-93116630C72B@webtypes.com>

On Jul 19, 2011, at 19:12 , Darin Adler wrote:

> On Jul 19, 2011, at 3:55 AM, Thomas Maas wrote:
> 
>> instead of checking for an empty string *and* focus the user agent should just check for an empty string.
> 
> I think that for some user agents, whether the placeholder text is shown when the field is focused should depend on platform behavior.
> 
> For example, Safari has one behavior on Snow Leopard and a different behavior on Lion and I think that is a good thing.
> 
>    -- Darin
> 

Well, the spec is pretty clear on the expected behavior of a user agent. If two user agents behave differently it just means of them isn't following the spec. I'm not sure I see how that's a good thing, but that's a different discussion altogether.

What Kent was suggesting is changing the spec to state that placeholder strings should bel visible on focus. I think that makes a lot of sense.

The only reason I can think of to hide the placeholder on focus is to make it clear to the user that there is no content yet. But that could be solved by styling the placeholder differently on focus or even bring back the current behavior by setting. :focus input-placeholder to display: none.

-Thomas.





From ian at hixie.ch  Tue Jul 19 14:35:53 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Jul 2011 21:35:53 +0000 (UTC)
Subject: [whatwg] Document's base URI should use the document's
 *current* address
In-Reply-To: <BANLkTikQ0P7WTZ3O6dRMs9LC4Ffkr-mzow@mail.gmail.com>
References: <BANLkTi=3DDK6pW4FXywKj8C6DRvNjFpYrQ@mail.gmail.com>
	<BANLkTikQ0P7WTZ3O6dRMs9LC4Ffkr-mzow@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107192115280.2079@ps20323.dreamhostps.com>

On Wed, 27 Apr 2011, Justin Lebar wrote:
>
> The document base URL is used when fetching resources.
> 
> Right now, if a page doesn't have a <base> element, the document base 
> URL is set to the document's address. ?(I'm going to call this the 
> "document's original address".) ?The document's original address does 
> not change when you call pushState; only the document's current address 
> does.
> 
> I think the base URI should use the document's current address, not the 
> original address.
> 
> To see why this makes sense, consider the following scenario:
> 
> * User loads page.html
> * Page calls pushState and changes its url to page2.html
> * User clicks on a link with href "#foo".
> 
> As currently specified, we'll resolve #foo relative to the document's 
> original URL; that is, clicking the link will take the user to 
> page.html#foo, not page2.html#foo. ?But the intent of a link with href 
> #foo is clearly to navigate within the current page, not to go somewhere 
> else.
> 
> Firefox 4 already implements pushState as I'm suggesting here.

The spec as written decides whether a link is a same-resource reference or 
not based on comparing the URLs to what you're calling the original 
address, not comparing it to the current address. See the navigation 
algorithm, step 7 /Fragment identifiers/.

Note that there are problems with what you describe: what if the new URL 
has a different path, and there are <img> elements whose URLs are 
relative, and after pushState() you clone one? Or what about relative 
links in the original markup? I don't think we can change the base URL on 
the fly, all kinds of problems could result.

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

From jonas at sicking.cc  Tue Jul 19 16:06:56 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 19 Jul 2011 16:06:56 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
Message-ID: <CA+c2ei_WiLbLLu3-EzKzU5oBztz7C6R9WFV1kJ08+h8PoTwg7A@mail.gmail.com>

> I think this requirement doesn't really help us enforce endpoints
> initiate/accept WebSocket with the same configuration. Because
>
> - non-browser UAs are free to be implemented without deflate-stream
> - server developers would see/care only the wire protocol spec

Given the number of browser installations in the world (a couple of
billion or so), and that a significant portion of these will implement
the WebSockets API spec, it would seem downright irresponsible of
server developers to not look at it.

> So, server developers would simply make their implementation accept both
> requests with and without deflate-stream, I think.

I'd like to see a bit more meat on this assertion.

> It's not likely that
> server implementors are influenced by "the WebSocket API" and have their
> server check if a UA is browser or not and reject requests w/o
> deflate-stream.

Agreed. But it's not really servers job to ensure that browsers follow
the websocket spec here. Test suites and being able to claim that you
follow the spec should enforce that.

> The only people who benefit from this requirement is those
> who implement a server only for their own use and are not interested in
> serving non-browser clients.

First off, I suspect that the by far most common use case for servers
implementing websocket is to talk to browsers. So I would expect the
group you are talking about to be the majority of websocket
implementations. How many http servers do you think are out there
written primarily to talk to browsers?

Second, we're not really talking about browsers vs. non-browsers,
right. But rather clients that support deflate-stream vs. ones that
don't. So if a server expects to only talk to clients that support
deflate-stream, they might choose not require that. Even if some of
those clients aren't browsers.

Compare to the situation for http servers out there. I would expect
that a large number of them (as measured by codebases, not by
deployments) to have been primarily developed by testing what works
against browsers. I would further expect that non-browser clients,
such as web search spiders, end up having had to replicate some
browser behavior in order to be compatible with a larger set of http
servers.

> Even for such people, I think it's easier to debug and straightforward that
> they implement one without deflate-stream and then with deflate-stream, and
> then just leave both available. I can't imagine servers that has solid
> implementation for deflate-stream but not for w/o deflate-stream.

Untested generally ends up being non-working code. So while you might
end up writing without deflate-stream in the beginning, once you
implement deflate-stream, and have almost exclusively clients that
support deflate-stream, it's likely that your non-deflate-stream code
path ends up with bugs.

/ Jonas

From wwg at millie.uk.to  Tue Jul 19 17:06:03 2011
From: wwg at millie.uk.to (Marc 'Tafouk')
Date: Wed, 20 Jul 2011 02:06:03 +0200
Subject: [whatwg]  WebVTT feedback (was Re: Video feedback)
Message-ID: <jbm.20110720020603.62552adf@AZIMUTH>

On Mon, 27 Jun 2011 at 09:32 AM, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:
> I wanted to mention that Ronny's page at
> http://leanbackplayer.com/other/webvtt.html has had some updates
> recently and has now settled, with demos at
> http://leanbackplayer.com/test/webvtt.html .
>
> Note that where his implementation differs from the spec, he has made
> a note. There are only two such notes. I'd like to see these
> addressed, too.
>
> Cheers,
> Silvia.
>

Hello folks,

I've been following the latest developments on the WebVTT specification and 
am making an attempt to write an out-of-browser parser, using Anna 
Cavender's proposed patches to WebKit.

First, I filed a request on the bugtracker 
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=13292> regarding the "end-
of-file marker" that's mentioned in the current draft 
<http://www.whatwg.org/specs/web-apps/current-work/#webvtt-cue-text-
parsing-rules>


I have another question about self-closing tags in cue text. It seems 
they're not supported at all.
The U+002F SOLIDUS character (/) is only handled in the WebVTT tag state.

Test case 1-a):
   WEBVTT

   00:00.000 --> 00:02.000
   Initial <b/> test

U+0062 (b) triggers "WebVTT start tag state"; U+002F is then handled as 
"Anything else" and is appended to result (tagname = "b/").


Test case 1-b):
   WEBVTT

   00:00.000 --> 00:02.000
   Initial <b /> test


U+0062 (b) triggers "WebVTT start tag state"; U+0020 (space) triggers  
"WebVTT start tag annotation state"; U+002F is handled as "Anything else" 
and is appended to buffer (annotation = "/").


I am aware those may be moot atm because there is no void element AFAIK, 
and the current tags make no sense when immediately closed.


I also found a slight issue when following the parser specs : there is no 
validation of the class attribute.

Test case 2):
   WEBVTT

   00:00.000 --> 00:02.000
   Second <c.......... [my annotation]> test

classes is a list of 10 empty strings.

Regards, Marc.



From ian at hixie.ch  Tue Jul 19 17:34:42 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 20 Jul 2011 00:34:42 +0000 (UTC)
Subject: [whatwg] <comment> element in HTML5 Spec?
In-Reply-To: <BANLkTim_4yVi3ms+NqW+t9VBJCRJQUkgMA@mail.gmail.com>
References: <C92C1B1D.28D9%Richard.Summers@bbc.co.uk>
	<AANLkTikiNFD+-5tUvVD6eqsyojwbXqKpAB9MO7b3HuNk@mail.gmail.com>
	<2d71c095a3c6bd8bab706420b97d1581.squirrel@htmlfiver.com>
	<Pine.LNX.4.64.1104282130170.19153@ps20323.dreamhostps.com>
	<BANLkTikgHa8PdBVqo2cS7xKSMSHhQiYNfg@mail.gmail.com>
	<BANLkTim_4yVi3ms+NqW+t9VBJCRJQUkgMA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107192343470.2079@ps20323.dreamhostps.com>

On Thu, 28 Apr 2011, Jonas Sicking wrote:
> On Thu, Apr 28, 2011 at 2:41 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 13 Dec 2010, Richard Summers wrote:
> >>
> >> I was wondering, is there any plan to implement a <comment> element 
> >> within the HTML5 spec? I?m suggesting this as a complimentary element 
> >> to the <article> element.
> >
> > There already is one: <article>! We defined it such that if you nest 
> > them, the nested ones are defined to be comments. There are some 
> > examples of this in the spec.
> >
> >
> > On Mon, 13 Dec 2010, Tab Atkins Jr. wrote:
> >>
> >> 1. Differentiating between the main article and user-generated 
> >> content in response (you bring this up). ?Would this be useful for 
> >> search engines? ?I'm not sure. ?Would it be useful to weight comment 
> >> content differently from article content? ?Perhaps weight links in 
> >> comments less than links in the rest of the page?
> >
> > This is already possible: a nested <article> has this semantic.
> 
> This seems like a very unintuitive solution. If this really is a use 
> case that is worth addressing, I think it would be worth coming up with 
> a dedicated element. In general, elements that have different meaning 
> depending on in which context they appear usually doesn't feel very 
> intuitive and thus likely something that people will miss or get wrong.

<article> has just one meaning: content that it would make sense to 
syndicate; or to put it another way, content for which a CMS could 
reasonably have a dedicated permalink page. When it's nested in another, 
it just means that the inner article is a response to the outer one, in 
the same way that a <section> in another <section> is a subsection of the 
first, or that an <h1> in a particular <section> is a heading for that 
section. I don't think this is a different meaning.


On Thu, 28 Apr 2011, Tab Atkins Jr. wrote:
> 
> I agree.  In particular, I want to sometimes nest articles without one 
> article being a comment on the outer one.

Could you describe such a case? I'm finding it hard to imagine a situation 
where an article literally nests another, without <aside> being more 
appropriate.


> The <body> element is supposed to be the "default article" for the page, 
> too - it would be odd if <article>-in-<body> acted differently from 
> <article>-in-<article>.

I don't think it's accurate to consider <body> to be equivalent to 
<article>. You wouldn't syndicate much of what is in a <body>, only the 
article itself (e.g. you wouldn't syndicate the footer, site nav, etc).

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

From ian at hixie.ch  Tue Jul 19 18:12:19 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 20 Jul 2011 01:12:19 +0000 (UTC)
Subject: [whatwg] <base> in <body>
Message-ID: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>


IE7 and up, in both quirks and non-quirks modes, ignores <base href> in 
the <body> of a page. This is intended to protect against a situation 
where a whitelist-based content filter disallows all scripts but does not 
disallow <base>, and the page contains a relative URL in a <script> after 
an area of the page under attacker control.

Would other browser vendors be willing to change to only look at <base 
href> in <head>?

The change to the spec would just be changing this step in the "document 
base URL" definition:

4. If there is no base element that has an href attribute, then the 
   document base URL is fallback base url; abort these steps. Otherwise, 
   let url be the value of the href attribute of the first such element.

...to limit the search just to children of the <head> element.

Note that there is a compatibility risk, in that IE7-9 parse certain 
elements into the <head> where the HTML parser spec does not. For example:

   <!DOCTYPE HTML>
   <html>
    <head>
     <title>Demo</title>
    </head>
    <!-- implied <body> -->
     <form>
      <input type=hidden>
      <base href="">

...will end up with the <head> element containing a <form> element that 
itself contains the <base> element.

IE10 parses this like other browsers, so it would be affected by the same 
compatibility concern.

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

From bzbarsky at MIT.EDU  Tue Jul 19 20:07:05 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 19 Jul 2011 23:07:05 -0400
Subject: [whatwg] <base> in <body>
In-Reply-To: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
Message-ID: <4E264659.3040004@mit.edu>

On 7/19/11 9:12 PM, Ian Hickson wrote:
> Would other browser vendors be willing to change to only look at<base
> href>  in<head>?

Gecko used to implement that back when the spec said it.

This caused site compat issues.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=593807 (United checkin 
outside the US being broken) and 
https://bugzilla.mozilla.org/show_bug.cgi?id=592880 (hyperlatex output 
being broken) for example.

The latter explicitly mentions that hyperlatex output is broken in 
recent IE versions.

The former depends on the parsing behavior of IE you describe so is not 
a problem in IE9-.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=593807#c7

On the other hand, this change would fix CA Unicenter 
(https://bugzilla.mozilla.org/show_bug.cgi?id=627361 and its two 
duplicates), I think.

So I guess it comes down to what set of sites we want to break here.... 
  Do other UA vendors have any data on the matter?

That said, I'm not sure I understand the security concern.  What kind of 
whitelist-based filter would let through <script>s whose URIs it does 
not control, exactly?  Can the security concern be mitigated by only 
allowing <base> outside <head> if the base URI it sets is same-origin 
with the document?

-Boris

From silviapfeiffer1 at gmail.com  Tue Jul 19 20:14:23 2011
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 20 Jul 2011 13:14:23 +1000
Subject: [whatwg] WebVTT feedback (was Re: Video feedback)
In-Reply-To: <jbm.20110720020603.62552adf@AZIMUTH>
References: <jbm.20110720020603.62552adf@AZIMUTH>
Message-ID: <CAHp8n2nJCdZTSJUR4keUXN17T12qKwwriR6XuiUk4w=Dxt369Q@mail.gmail.com>

Hi Marc,

On Wed, Jul 20, 2011 at 10:06 AM, Marc 'Tafouk' <wwg at millie.uk.to> wrote:
>
> Hello folks,
>
> I've been following the latest developments on the WebVTT specification and
> am making an attempt to write an out-of-browser parser, using Anna
> Cavender's proposed patches to WebKit.

Cool! Is this a new video player app or going into, say, VLC or
something similar?


> First, I filed a request on the bugtracker
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13292> regarding the "end-
> of-file marker" that's mentioned in the current draft
> <http://www.whatwg.org/specs/web-apps/current-work/#webvtt-cue-text-
> parsing-rules>

I replied. IIUC, it's just the EOF state that is meant, not an actual character.


> I have another question about self-closing tags in cue text. It seems
> they're not supported at all.

None of the tags that we have mean anything if they self-close (and
the <timestamp> is implicitly closing).


> The U+002F SOLIDUS character (/) is only handled in the WebVTT tag state.
>
> Test case 1-a):
> ? WEBVTT
>
> ? 00:00.000 --> 00:02.000
> ? Initial <b/> test
>
> U+0062 (b) triggers "WebVTT start tag state"; U+002F is then handled as
> "Anything else" and is appended to result (tagname = "b/").

Yes. The next character is then a ">" and causes in the next loop to
return an end tag. Then, end tags are parsed and it's not in the list
that we expect, so this happens: Otherwise, ignore the token. Thus,
<b/> is ignored.


> Test case 1-b):
> ? WEBVTT
>
> ? 00:00.000 --> 00:02.000
> ? Initial <b /> test
>
>
> U+0062 (b) triggers "WebVTT start tag state"; U+0020 (space) triggers
> "WebVTT start tag annotation state"; U+002F is handled as "Anything else"
> and is appended to buffer (annotation = "/").

Once ">" is reached, this leads to a start tag <b> with an annotation
of "/". From how I read it, the annotation string gets ignored.


> I am aware those may be moot atm because there is no void element AFAIK,
> and the current tags make no sense when immediately closed.

They still have to parse correctly. But I think from analysing the
spec they actually do.


> I also found a slight issue when following the parser specs : there is no
> validation of the class attribute.

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#attach-a-webvtt-internal-node-object
says to attach the list of classes to the element. Right now, all
characters are allowed for class names bar space, tab, "." and ">". It
might indeed be an idea to restrict these character to those allowed
for class names in HTML.


> Test case 2):
> ? WEBVTT
>
> ? 00:00.000 --> 00:02.000
> ? Second <c.......... [my annotation]> test
>
> classes is a list of 10 empty strings.

While possibly a bit or unneeded overhead, in
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#webvtt-cue-text-dom-construction-rules
when mapping to HTML happens, they just create an additional space in
the class attribute, so are not harmful.


Cheers,
Silvia.

From rolandsteiner at google.com  Tue Jul 19 20:52:55 2011
From: rolandsteiner at google.com (Roland Steiner)
Date: Wed, 20 Jul 2011 12:52:55 +0900
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CAAWBYDCO0DtyQ0S3oF=F8pS=0zEUCRpRV3Ou8eNcQu3Y-FVBrw@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
	<CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
	<4E258286.7020602@mit.edu>
	<CAAWBYDCO0DtyQ0S3oF=F8pS=0zEUCRpRV3Ou8eNcQu3Y-FVBrw@mail.gmail.com>
Message-ID: <CACFPSpiHXZ2KsUWo6KiSXCt0RVdhSAEpP_QPcKpNmodCbKn0fQ@mail.gmail.com>

On Wed, Jul 20, 2011 at 12:47 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Tue, Jul 19, 2011 at 6:11 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > On 7/19/11 12:30 AM, Roland Steiner wrote:
> >>
> >> I think one could argue for either case. Personally, I think it's
> >> advantageous to include the scoping element (i.e., use ":scope foo .bar,
> >> foo:scope .bar"), in order to be able to do style the scoping element
> >> itself rather than its children individually, e.g.
> >>
> >> :scope { background-color: mauve; }
> >
> > Hmm.  I agree this is a useful thing to do, but perhaps it's better
> > accomplished by not prepending ":scope " to selectors which have a :scope
> in
> > the first sequence of simple selectors in addition to ones that have
> :root
> > there?
> >
> > This would still not make "foo .bar" match if the scope is a foo, but
> would
> > we actually want to match?
>
> I think it's best for that case to *not* match.  Otherwise, you have
> to explicitly remember to add a :not(:scope) to every rule that might
> match the scoping element.
>

You could just prefix ":scope " instead, i.e., write ":scope foo" if you're
worried that foo might match the scoping element.


> It's very easy to style the scoping element by using :scope explicitly.


I kinda agree with the assessment, but from a puritanical point of view,
given that :scope is a pseudo-class it feels strange that with <foo> as
scoping element the more specific "foo:scope" would match, but the more
generic "foo" wouldn't (even though it still is the scoping element). Also,
the same "foo" matches again if there is a ":root" further to the left.

But adding :scope into the discussion raises the question whether matching
should continue even in the absence of :root - e.g.,

baz :scope .bar

It would seem natural that with this rule, matching would go past the
scoping element, given that it's explicitly identified. That means, the
matching algorithm would go along the lines of:

.) match up to a child of the scoping element
.) match the scoping element and upwards ONLY IF the current selector
sequence contains :scope or the first selector sequence contains :root

if the scoping element is not per default included, or

.) match up to the scoping element
.) match upwards ONLY IF the scoping element was explicitly matched with
:scope, or if the first selector sequence contains :root

if it is.


- Roland

From annevk at opera.com  Wed Jul 20 01:54:55 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 20 Jul 2011 10:54:55 +0200
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E264659.3040004@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu>
Message-ID: <op.vywtptlc64w2qv@annevk-macbookpro.local>

On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> That said, I'm not sure I understand the security concern.  What kind of  
> whitelist-based filter would let through <script>s whose URIs it does  
> not control, exactly?  Can the security concern be mitigated by only  
> allowing <base> outside <head> if the base URI it sets is same-origin  
> with the document?

The <script> is from the page itself and uses a relative URL. The <base>  
is inserted by the attacker and causes the script to be requested from a  
server under the attacker's control.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From tyoshino at google.com  Wed Jul 20 01:57:04 2011
From: tyoshino at google.com (Takeshi Yoshino)
Date: Wed, 20 Jul 2011 17:57:04 +0900
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CA+c2ei_WiLbLLu3-EzKzU5oBztz7C6R9WFV1kJ08+h8PoTwg7A@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<CA+c2ei_WiLbLLu3-EzKzU5oBztz7C6R9WFV1kJ08+h8PoTwg7A@mail.gmail.com>
Message-ID: <CAH9hSJZCe-GFabqBO_3XjYVdGgyWBZhPyW5O2DF2kwqEY=-bQQ@mail.gmail.com>

Hi,

On Wed, Jul 20, 2011 at 08:06, Jonas Sicking <jonas at sicking.cc> wrote:

> > I think this requirement doesn't really help us enforce endpoints
> > initiate/accept WebSocket with the same configuration. Because
> >
> > - non-browser UAs are free to be implemented without deflate-stream
> > - server developers would see/care only the wire protocol spec
>
> Given the number of browser installations in the world (a couple of
> billion or so), and that a significant portion of these will implement
> the WebSockets API spec, it would seem downright irresponsible of
> server developers to not look at it.


Sorry, I said too far about this. My main point is the assertion "they
wouldn't try to reject clients w/o deflate-stream".


> > It's not likely that
> > server implementors are influenced by "the WebSocket API" and have their
> > server check if a UA is browser or not and reject requests w/o
> > deflate-stream.
>
> Agreed. But it's not really servers job to ensure that browsers follow
> the websocket spec here. Test suites and being able to claim that you
> follow the spec should enforce that.
>

It really tries to enforce browsers to use deflate-stream. I agree that
point. But even with this requirement I don't think we can avoid the bad
situation for servers that Hixie described in the bug entry. It just pull up
the ratio of clients in the world which never initiates WebSocket w/o
deflate-stream. Even without this requirement, server developers would
implement compression to make their server widely-used. Even with this
requirement, they would still leave their server accept un-compressed
connection for debugging and interoperability with non-browser clients. Just
IMHO.

But for service providers, yes, as you say the requirement may support them
in recommending clients with compression-by-default, or moreover in stopping
support of un-compressed connections, to reduce bandwidth and complexity in
load balancing, etc. So, I'll stop arguing this point.


> > The only people who benefit from this requirement is those
> > who implement a server only for their own use and are not interested in
> > serving non-browser clients.
>
> First off, I suspect that the by far most common use case for servers
> implementing websocket is to talk to browsers. So I would expect the
> group you are talking about to be the majority of websocket
> implementations. How many http servers do you think are out there
> written primarily to talk to browsers?
>

Yes. For most case, their "primary" clients will be browsers, I agree. But
it's also true that IETF keeps it available for possible non-browser
clients.

According to your and Hixie's opinion, the API spec is indirectly attempting
to override the decision made by IETF and eliminate WebSocket w/o
deflate-stream support from both client and server from the world while "the
WebSocket protocol" still allows plain connection. Here we are introducing
inconsistency between the goal of "the WebSocket protocol" and one of "the
WebSocket API".  We are separating the world of "the WebSocket protocol for
the WebSocket API" and "the WebSocket protocol". It's rather really
interoperability problem. Please don't take indirect and majority power
based way silently but feedback to HyBi. We should respect/coordinate each
other's decision/philosophy. It's last resort that we instantiate a
dedicated "the WebSocket protocol for the WebSocket API".

In particular about enforcing or recommending regular use of compression,
once we've specified compression method good enough to recommend, I think
that's fine. But that still should be first discussed in the HyBi WG (with
coordination with the whatwg). deflate-stream is left optional because it's
just an example interim solution and getting objection in the HyBi WG. It's
waiting for better compression extension. We shouldn't extend this
un-stability to the API spec.


> Second, we're not really talking about browsers vs. non-browsers,
> right. But rather clients that support deflate-stream vs. ones that
> don't. So if a server expects to only talk to clients that support
> deflate-stream, they might choose not require that. Even if some of
> those clients aren't browsers.
>

s/not require/require/?

Yes. Accepting deflate-stream or not can be decided by each server developer
and service provider on their responsibility.


> > Even for such people, I think it's easier to debug and straightforward
> that
> > they implement one without deflate-stream and then with deflate-stream,
> and
> > then just leave both available. I can't imagine servers that has solid
> > implementation for deflate-stream but not for w/o deflate-stream.
>
> Untested generally ends up being non-working code. So while you might
> end up writing without deflate-stream in the beginning, once you
> implement deflate-stream, and have almost exclusively clients that
> support deflate-stream, it's likely that your non-deflate-stream code
> path ends up with bugs.


Generally I agree. But IMO connections w/ deflate-stream would be usually
implemented by composing deflater/inflater code with the code that handles
plain (w/o deflate-stream) connections. The situation is different from
supporting some feature A and B where A and B are really independent. There
would be little code that may get rotten. Rather, as I noted above the
complicated matter I'd worry about is
- to handle two kinds of connection with different characteristics mixed
- to handle inefficient clients for all time
from production perspective (load balancing, etc.).

Takeshi

From timdown at gmail.com  Wed Jul 20 03:14:18 2011
From: timdown at gmail.com (Tim Down)
Date: Wed, 20 Jul 2011 11:14:18 +0100
Subject: [whatwg] Specification of window.find()
In-Reply-To: <Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
Message-ID: <CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>

On 6 January 2011 21:53, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 27 Oct 2010, benjamin.poulain at nokia.com wrote:
>>
>> I would like to suggest a change for the main HTML 5 specification:
>> http://www.whatwg.org/specs/web-apps/current-work/
>>
>> The problem I have is with the Window object specification
>> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
>> It does not mention the method find() which can be found on most engines
>> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).
>
> It looks like IE doesn't implement this, so it's probably not strictly
> required for compat with the Web.
>
> What are the use cases for this feature?

It's useful for custom search features. I've recommended it a few
times on Stack Overflow for people wanting to highlight or somehow
style all occurrences of a piece of text that may span nodes (it's
this part that is the compelling feature). You can achieve the same
using TextRange in IE. For example:

http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags

I think this is a valid use case. On a related note, I would like to
see equivalents of some of the text-based methods in IE's TextRange
make their way into Range, but that's a separate issue.

Tim

From chris at bentzel.net  Wed Jul 20 04:33:51 2011
From: chris at bentzel.net (Chris Bentzel)
Date: Wed, 20 Jul 2011 07:33:51 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
Message-ID: <CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>

Who should be trusted for filename if the one specified by <a> on the
referring page differs from the one specified by Content-Disposition
on the to-be-downloaded resource?

On Tue, Jul 19, 2011 at 1:42 PM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> 18.07.2011, ? 9:35, Glenn Maynard ???????(?):
>
>> > A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.
>>
>> The service hosting the file--the target of the link--shouldn't convey trust. ?The page containing the download link is where trust should come from, not the link target.
>
>
> There are many views on what conveys trust. If we don't go to the extremes (like users who click on anything and agree to any confirmation dialogs without reading them), there is certainly a group of people who look where a link points to before clicking it.
>
> The fact that hosting implies a certain degree of trust is also built into client software. For example, if you download an executable file on Mac OS X, then the system warns you about it on first launch, and tells you where it was downloaded from, not where a link to the download was.
>
> Hosting services do have their policies on what can be hosted. As we discuss a way to subvert those policies, we shouldn't start with an assumption that it's inconsequential.
>
> - WBR, Alexey Proskuryakov
>
>

From tommyw at google.com  Wed Jul 20 05:28:46 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Wed, 20 Jul 2011 14:28:46 +0200
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
References: <4E242D26.3030401@alvestrand.no>
	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
Message-ID: <CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>

Thanks for the explanation. To me this sounds overly complicated, why not
just make it so that an disable of a track will override the track settings
for forked MediaStreams? This will definitely simplify implementation, and
confuse web developers less imho. MSTracks coming and going doesn't feel
right. Especially since there are no callbacks/events that a MS changes.

Also some follow-up questions regarding the new TrackLists:

What should happen when a track fails? Should the entire stream fail, the
MSTrack silently be removed or the MSTrack disassociated with the track (and
thus becoming a do-nothing object)?

What should happen when a stream with two or more video tracks is associated
to a <video> tag? Just render the first enabled one?

/Tommy

On Mon, Jul 18, 2011 at 20:38, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 18 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> >
> > I am very confused regarding the below paragraph from the latest spec:
> >
> > When a track in a MediaStream parent is disabled, any MediaStreamTrack
> > objects corresponding to the tracks in any MediaStream objects that were
> > created from parent are disassociated from any track, and must not be
> > reused for tracks again. If a disabled track in a MediaStream parent is
> > re-enabled, from the perspective of any MediaStream objects that were
> > created from parent it is a new track and thus new MediaStreamTrack
> > objects must be created for the tracks that correspond to the re-enabled
> > track.
> >
> > After cloning a LocalMediaStream it looks like this:
> >
> > LocalMediaStream -> MediaStream1
> > Track1(E)           Track1(E)
> > Track2(E)           Track2(E)
> > Track3(E)           Track3(E)
> >
> > and as I interpret the spec it looks like this if Track1 in the
> > LocalMediaStream is disabled:
> >
> > LocalMediaStream -> MediaStream1
> > Track1(D)           Track2(E)
> > Track2(E)           Track3(E)
> > Track3(E)
>
> Correct so far (though I'd avoid the term "cloning" since it's not quite
> what's going on here -- the spec uses "forking", which may be closer
> though is still not ideal).
>
>
> > So Track1 disappears from the MediaStream1 object and doesn't come back
> > even if Track1 in the LMS object is enabled:
> >
> > LocalMediaStream -> MediaStream1
> > Track1(E)           Track2(E)
> > Track2(E)           Track3(E)
> > Track3(E)
>
> No, it'll create a new track object:
>
>  LocalMediaStream -> MediaStream1
>  Track1(E)           Track4(E)
>  Track2(E)           Track2(E)
>  Track3(E)           Track3(E)
>
> This is specified in the sentence that starts "If a disabled track in a
> MediaStream parent is re-enabled...".
>
> If you could explain how you are interpreting the current text I would be
> happy to fix the problematic area to be clearer (it's not clear to me
> what's unclear at the moment).
>
>
> On Mon, 18 Jul 2011, Harald Alvestrand wrote:
> >
> > What is the scenario in which this behavioiur is useful?
>
> The muting feature exists in order to allow authors to mute outgoing video
> while leaving outgoing audio and while still having a local video montior.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'




-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.

From bzbarsky at MIT.EDU  Wed Jul 20 07:54:25 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 20 Jul 2011 10:54:25 -0400
Subject: [whatwg] <base> in <body>
In-Reply-To: <op.vywtptlc64w2qv@annevk-macbookpro.local>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu>
	<op.vywtptlc64w2qv@annevk-macbookpro.local>
Message-ID: <4E26EC21.3050005@mit.edu>

On 7/20/11 4:54 AM, Anne van Kesteren wrote:
> On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> That said, I'm not sure I understand the security concern. What kind
>> of whitelist-based filter would let through <script>s whose URIs it
>> does not control, exactly? Can the security concern be mitigated by
>> only allowing <base> outside <head> if the base URI it sets is
>> same-origin with the document?
>
> The <script> is from the page itself and uses a relative URL. The <base>
> is inserted by the attacker and causes the script to be requested from a
> server under the attacker's control.

OK, thanks.  That was about the only threat model I could think of here...

It sounds like my proposal above would mitigate this threat, yes?

-Boris


From annevk at opera.com  Wed Jul 20 07:59:31 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 20 Jul 2011 16:59:31 +0200
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E26EC21.3050005@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu> <op.vywtptlc64w2qv@annevk-macbookpro.local>
	<4E26EC21.3050005@mit.edu>
Message-ID: <op.vyxalhbw64w2qv@annevk-macbookpro.local>

On Wed, 20 Jul 2011 16:54:25 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/20/11 4:54 AM, Anne van Kesteren wrote:
>> On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu>  
>> wrote:
>>> That said, I'm not sure I understand the security concern. What kind
>>> of whitelist-based filter would let through <script>s whose URIs it
>>> does not control, exactly? Can the security concern be mitigated by
>>> only allowing <base> outside <head> if the base URI it sets is
>>> same-origin with the document?
>>
>> The <script> is from the page itself and uses a relative URL. The <base>
>> is inserted by the attacker and causes the script to be requested from a
>> server under the attacker's control.
>
> OK, thanks.  That was about the only threat model I could think of  
> here...
>
> It sounds like my proposal above would mitigate this threat, yes?

Yes.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From julian.reschke at gmx.de  Wed Jul 20 08:28:19 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 20 Jul 2011 17:28:19 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
Message-ID: <4E26F413.5090302@gmx.de>

On 2011-07-20 13:33, Chris Bentzel wrote:
> Who should be trusted for filename if the one specified by<a>  on the
> referring page differs from the one specified by Content-Disposition
> on the to-be-downloaded resource?
> ...

I think the header field needs to be authoritative.

That being said, if you want to go down the road, make it clear how the 
file name actually is extracted from the header field in an 
interoperable way.

Best regards, Julian

From justin.lebar at gmail.com  Wed Jul 20 08:54:22 2011
From: justin.lebar at gmail.com (Justin Lebar)
Date: Wed, 20 Jul 2011 11:54:22 -0400
Subject: [whatwg] Document's base URI should use the document's
	*current* address
In-Reply-To: <Pine.LNX.4.64.1107192115280.2079@ps20323.dreamhostps.com>
References: <BANLkTi=3DDK6pW4FXywKj8C6DRvNjFpYrQ@mail.gmail.com>
	<BANLkTikQ0P7WTZ3O6dRMs9LC4Ffkr-mzow@mail.gmail.com>
	<Pine.LNX.4.64.1107192115280.2079@ps20323.dreamhostps.com>
Message-ID: <CAFWcpZ49CvLObKVHAFm5s3qBnxSAVYR1Ft1JfV1Sra43zGcaHA@mail.gmail.com>

> The spec as written decides whether a link is a same-resource reference or
> not based on comparing the URLs to what you're calling the original
> address, not comparing it to the current address. See the navigation
> algorithm, step 7 /Fragment identifiers/.

Maybe I'm misunderstanding, but this might not be the case in the
history traversal algorithm.

> Step 6: If the specified entry has a URL whose fragment identifier differs from that of the current entry's when compared in
> a case-sensitive manner, and the two share the same Document object, then let hash changed be true.

It's not clear to me what the current/specified entry's URL is, or
where this is properly defined, but earlier, we say:

> The current entry is usually an entry for the location of the Document.

and the document's location changes when we call push/replaceState.

In any case, the navigation algorithm is clear as written.

>> As currently specified, we'll resolve #foo relative to the document's
>> original URL; that is, clicking the link will take the user to
>> page.html#foo, not page2.html#foo.  But the intent of a link with href
>> #foo is clearly to navigate within the current page, not to go somewhere
>> else.

Were you saying that this isn't the right interpretation of the spec?
Because #foo is resolved relative to the document's base URI, which is
the same as the document's original URI, so we decide that #foo is a
same-document link?  That's comforting, if it's true.  :)

> Note that there are problems with what you describe: what if the new URL
> has a different path, and there are <img> elements whose URLs are
> relative, and after pushState() you clone one? Or what about relative
> links in the original markup? I don't think we can change the base URL on
> the fly, all kinds of problems could result.

I agree there are problems with changing the base URI.  But it seems
much less intuitive for common use-cases not to change it.  We can
change my example above to use ?foo instead of #foo, and I think the
same argument applies.  Should a link with href ?foo always resolve
relative to the document's original URI (unless the base is explicitly
changed)?  Similarly, if for some bizarre reason the page pushState's
to a new directory, shouldn't all the links point relative to that new
directory?

I kind of think this ship has sailed wrt implementations.  Chrome and
Firefox both have the same behavior in this respect.  See
http://people.mozilla.org/~jlebar/whatwg/test_pushstate_resolve.html
(source included below, since I have a bad habit of deleting these
test files right before someone else wants to look at them).

Ian, how hard do you think it would be to spec changing the base and
resolve the issues with that?

-Justin

<html>
<body>
<a href='#foo'>#foo</a><br>
<a href='?foo'>?foo</a><br>
<a href='foo'>foo</a><br>
 <button onclick='history.pushState("", "", Math.random())'>pushState
to new file</button><br>
<button onclick='history.pushState("", "", Math.random() +
"/file")'>pushState to new directory</button>
</body>
</html>

On Tue, Jul 19, 2011 at 5:35 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 27 Apr 2011, Justin Lebar wrote:
>>
>> The document base URL is used when fetching resources.
>>
>> Right now, if a page doesn't have a <base> element, the document base
>> URL is set to the document's address. ?(I'm going to call this the
>> "document's original address".) ?The document's original address does
>> not change when you call pushState; only the document's current address
>> does.
>>
>> I think the base URI should use the document's current address, not the
>> original address.
>>
>> To see why this makes sense, consider the following scenario:
>>
>> * User loads page.html
>> * Page calls pushState and changes its url to page2.html
>> * User clicks on a link with href "#foo".
>>
>> As currently specified, we'll resolve #foo relative to the document's
>> original URL; that is, clicking the link will take the user to
>> page.html#foo, not page2.html#foo. ?But the intent of a link with href
>> #foo is clearly to navigate within the current page, not to go somewhere
>> else.
>>
>> Firefox 4 already implements pushState as I'm suggesting here.
>
> The spec as written decides whether a link is a same-resource reference or
> not based on comparing the URLs to what you're calling the original
> address, not comparing it to the current address. See the navigation
> algorithm, step 7 /Fragment identifiers/.
>
> Note that there are problems with what you describe: what if the new URL
> has a different path, and there are <img> elements whose URLs are
> relative, and after pushState() you clone one? Or what about relative
> links in the original markup? I don't think we can change the base URL on
> the fly, all kinds of problems could result.
>
> --
> Ian Hickson ? ? ? ? ? ? ? U+1047E ? ? ? ? ? ? ? ?)\._.,--....,'``. ? ?fL
> http://ln.hixie.ch/ ? ? ? U+263A ? ? ? ? ? ? ? ?/, ? _.. \ ? _\ ?;`._ ,.
> Things that are impossible just take longer. ? `._.-(,_..'--(,_..'`-.;.'

From Simetrical+w3c at gmail.com  Wed Jul 20 09:58:47 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 20 Jul 2011 12:58:47 -0400
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
Message-ID: <CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>

On Wed, Jul 20, 2011 at 6:14 AM, Tim Down <timdown at gmail.com> wrote:
> It's useful for custom search features. I've recommended it a few
> times on Stack Overflow for people wanting to highlight or somehow
> style all occurrences of a piece of text that may span nodes (it's
> this part that is the compelling feature). You can achieve the same
> using TextRange in IE. For example:
>
> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>
> I think this is a valid use case.

However, the implementation here doesn't do what you'd want: it
selects the text, destroying any existing selection.  You can work
around it by preserving and then restoring the selection somehow, but
it's not ideal at all.  It would make much more sense to have a
function that returned a Range or list of Ranges.

Of course, for the use-case you posted, execCommand() would also have
to work on Ranges instead of just the selection, but that should
probably be feature #1 to add to it anyway . . .

From jonas at sicking.cc  Wed Jul 20 10:02:51 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 20 Jul 2011 10:02:51 -0700
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E264659.3040004@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu>
Message-ID: <CA+c2ei8J8eCZ-kv7n=Fa3AJ2xu6vYwnrLibCnLQQTmQt5anpoA@mail.gmail.com>

On Tue, Jul 19, 2011 at 8:07 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/19/11 9:12 PM, Ian Hickson wrote:
>>
>> Would other browser vendors be willing to change to only look at<base
>> href> ?in<head>?
>
> Gecko used to implement that back when the spec said it.
>
> This caused site compat issues. ?See
> https://bugzilla.mozilla.org/show_bug.cgi?id=593807 (United checkin outside
> the US being broken) and https://bugzilla.mozilla.org/show_bug.cgi?id=592880
> (hyperlatex output being broken) for example.
>
> The latter explicitly mentions that hyperlatex output is broken in recent IE
> versions.
>
> The former depends on the parsing behavior of IE you describe so is not a
> problem in IE9-. ?See https://bugzilla.mozilla.org/show_bug.cgi?id=593807#c7
>
> On the other hand, this change would fix CA Unicenter
> (https://bugzilla.mozilla.org/show_bug.cgi?id=627361 and its two
> duplicates), I think.
>
> So I guess it comes down to what set of sites we want to break here.... ?Do
> other UA vendors have any data on the matter?
>
> That said, I'm not sure I understand the security concern. ?What kind of
> whitelist-based filter would let through <script>s whose URIs it does not
> control, exactly? ?Can the security concern be mitigated by only allowing
> <base> outside <head> if the base URI it sets is same-origin with the
> document?

Ugh, I'd really hate to introduce such inconsistencies though.

/ Jonas

From derhoermi at gmx.net  Wed Jul 20 11:49:52 2011
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed, 20 Jul 2011 20:49:52 +0200
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
In-Reply-To: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
Message-ID: <o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>

* Takeshi Yoshino wrote:
>Use of deflate-stream is now mandatory in API spec. I think this kind of
>requirement is useless. How about leave it up to implementors' decision?
>http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

The deflate-stream extension, when used for browser to server messages
allows an attacker to put whatever bytes he likes on the wire, after a
bit of unpredictable junk. Browser vendors were pretty opposed to that
for the normal protocol without extensions, and they were opposed to
having some way to make browsers send messages "unmasked"; so it would
be very odd for browser vendors to implement the extension. And by the
looks of it, the hybi Working Group may well drop deflate-stream now.
See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From kornel at geekhood.net  Wed Jul 20 12:36:59 2011
From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=)
Date: Wed, 20 Jul 2011 20:36:59 +0100
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E2504BF.70504@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
Message-ID: <op.vyxnfxdgte2ec8@aimac.local>

On Tue, 19 Jul 2011 05:14:55 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> This is actually an interesting question.  Does this end up  
> corresponding to:
>
>    :scope foo .bar, foo:scope .bar
>
> or to just
>
>    :scope foo .bar
>
> ?  The latter would not match on 'foo' being the scope element, while  
> the former would.

I think it should match the scoping element, as I expect this pattern to  
be common until <style scoped> is widely supported:

<div id=widget>
   <style scoped>
     #widget foo {}
   </style>
</div>

-- 
regards, Kornel Lesi?ski

From ash at ashleysheridan.co.uk  Wed Jul 20 12:55:51 2011
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Wed, 20 Jul 2011 20:55:51 +0100
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <op.vyxnfxdgte2ec8@aimac.local>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>  <op.vyxnfxdgte2ec8@aimac.local>
Message-ID: <1311191751.577.5.camel@localhost.localdomain>

On Wed, 2011-07-20 at 20:36 +0100, Kornel Lesi?ski wrote:

> On Tue, 19 Jul 2011 05:14:55 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 
> > This is actually an interesting question.  Does this end up  
> > corresponding to:
> >
> >    :scope foo .bar, foo:scope .bar
> >
> > or to just
> >
> >    :scope foo .bar
> >
> > ?  The latter would not match on 'foo' being the scope element, while  
> > the former would.
> 
> I think it should match the scoping element, as I expect this pattern to  
> be common until <style scoped> is widely supported:
> 
> <div id=widget>
>    <style scoped>
>      #widget foo {}
>    </style>
> </div>
> 


While I agree that that might be a common pattern, I disagree that it's
actually a good one. Consider an ad service which wraps everything in a
custom <div> tag. If the scope allowed the immediate parent to be
included as part of the scope, then it could allow the advert to be
altered in a way that could negatively affect the users of the site the
ad appeared on.

The purpose of scope in the style seems to be to protect elements
outside of the included content and to 'contain' the included content
that has the <style scoped> element in it, presumably because it's
coming from an external source. If you allowed the immediate parent as
your example, then it could allow the 3rd parties who created the advert
to take over the element beyond what the advert service would prefer to
be allowed.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk



From kornel at geekhood.net  Wed Jul 20 13:37:33 2011
From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=)
Date: Wed, 20 Jul 2011 21:37:33 +0100
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <1311191751.577.5.camel@localhost.localdomain>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu> <op.vyxnfxdgte2ec8@aimac.local>
	<1311191751.577.5.camel@localhost.localdomain>
Message-ID: <op.vyxp8vhute2ec8@aimac.local>

On Wed, 20 Jul 2011 20:55:51 +0100, Ashley Sheridan  
<ash at ashleysheridan.co.uk> wrote:

>> <div id=widget>
>>    <style scoped>
>>      #widget foo {}
>>    </style>
>> </div>
>
> While I agree that that might be a common pattern, I disagree that it's
> actually a good one. Consider an ad service which wraps everything in a
> custom <div> tag. If the scope allowed the immediate parent to be
> included as part of the scope, then it could allow the advert to be
> altered in a way that could negatively affect the users of the site the
> ad appeared on.

The site could wrap the ad in another div to prevent that (and this is  
typical when the site wants to create fixed-size ad slot).

> The purpose of scope in the style seems to be to protect elements
> outside of the included content and to 'contain' the included content
> that has the <style scoped> element in it, presumably because it's
> coming from an external source. If you allowed the immediate parent as
> your example, then it could allow the 3rd parties who created the advert
> to take over the element beyond what the advert service would prefer to
> be allowed.

For rogue 3rd parties there's <iframe> in seamless and sandboxed flavors.

If author is allowing untrusted and misbehaving code in the DOM, then it's  
already game over ? the ad can do anything, including creating <style>  
without scope and modifying other stylesheets.

Even scoped style could use position:absolute or fixed to modify looks of  
something outside the element.

-- 
regards, Kornel Lesi?ski

From timdown at gmail.com  Wed Jul 20 15:23:24 2011
From: timdown at gmail.com (Tim Down)
Date: Wed, 20 Jul 2011 23:23:24 +0100
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
Message-ID: <CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>

On 20 July 2011 17:58, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Wed, Jul 20, 2011 at 6:14 AM, Tim Down <timdown at gmail.com> wrote:
>> It's useful for custom search features. I've recommended it a few
>> times on Stack Overflow for people wanting to highlight or somehow
>> style all occurrences of a piece of text that may span nodes (it's
>> this part that is the compelling feature). You can achieve the same
>> using TextRange in IE. For example:
>>
>> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>>
>> I think this is a valid use case.
>
> However, the implementation here doesn't do what you'd want: it
> selects the text, destroying any existing selection. ?You can work
> around it by preserving and then restoring the selection somehow, but
> it's not ideal at all.

Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.

> It would make much more sense to have a
> function that returned a Range or list of Ranges.

Absolutely.

> Of course, for the use-case you posted, execCommand() would also have
> to work on Ranges instead of just the selection, but that should
> probably be feature #1 to add to it anyway . . .

Agreed. My number two feature (well, it would make the top 5, at
least) would be removing the restriction on execCommand() only working
on editable content. This very use case shows that its usefulness
extends beyond editable content. The temporarily-switch-designMode-on
workaround is ugly, and destroys the selection in some browsers.

Tim

From w3c at adambarth.com  Wed Jul 20 15:54:30 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 20 Jul 2011 15:54:30 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
Message-ID: <CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>

On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Takeshi Yoshino wrote:
>>Use of deflate-stream is now mandatory in API spec. I think this kind of
>>requirement is useless. How about leave it up to implementors' decision?
>>http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
>
> The deflate-stream extension, when used for browser to server messages
> allows an attacker to put whatever bytes he likes on the wire, after a
> bit of unpredictable junk. Browser vendors were pretty opposed to that
> for the normal protocol without extensions, and they were opposed to
> having some way to make browsers send messages "unmasked"; so it would
> be very odd for browser vendors to implement the extension. And by the
> looks of it, the hybi Working Group may well drop deflate-stream now.
> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.

Isn't the obvious solution to both problems to apply compression before masking?

Adam

From derhoermi at gmx.net  Wed Jul 20 16:56:25 2011
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu, 21 Jul 2011 01:56:25 +0200
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
In-Reply-To: <CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
Message-ID: <lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>

* Adam Barth wrote:
>On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>> The deflate-stream extension, when used for browser to server messages
>> allows an attacker to put whatever bytes he likes on the wire, after a
>> bit of unpredictable junk. Browser vendors were pretty opposed to that
>> for the normal protocol without extensions, and they were opposed to
>> having some way to make browsers send messages "unmasked"; so it would
>> be very odd for browser vendors to implement the extension. And by the
>> looks of it, the hybi Working Group may well drop deflate-stream now.
>> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
>> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.
>
>Isn't the obvious solution to both problems to apply compression before masking?

There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
not a solution to the problem Takeshi Yoshino raised though, which is
about whether Websocket API conformance should impose restrictions on
which Websocket extensions must and must not be supported, as far as I
understand it anyway.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From w3c at adambarth.com  Wed Jul 20 17:13:56 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 20 Jul 2011 17:13:56 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
Message-ID: <CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>

On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>>> The deflate-stream extension, when used for browser to server messages
>>> allows an attacker to put whatever bytes he likes on the wire, after a
>>> bit of unpredictable junk. Browser vendors were pretty opposed to that
>>> for the normal protocol without extensions, and they were opposed to
>>> having some way to make browsers send messages "unmasked"; so it would
>>> be very odd for browser vendors to implement the extension. And by the
>>> looks of it, the hybi Working Group may well drop deflate-stream now.
>>> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
>>> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.
>>
>>Isn't the obvious solution to both problems to apply compression before masking?
>
> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
> not a solution to the problem Takeshi Yoshino raised though, which is
> about whether Websocket API conformance should impose restrictions on
> which Websocket extensions must and must not be supported, as far as I
> understand it anyway.

It seems pretty clear that the API specify whatever profile of the
protocol we choose.  We do the same thing with HTTP (e.g., with the
XMLHttpRequest API).

Adam

From derhoermi at gmx.net  Wed Jul 20 17:38:57 2011
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu, 21 Jul 2011 02:38:57 +0200
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
In-Reply-To: <CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
	<CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>
Message-ID: <nqse27djdsv8hi3qjv9nj4egh27eurc3eh@hive.bjoern.hoehrmann.de>

* Adam Barth wrote:
>On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
>> not a solution to the problem Takeshi Yoshino raised though, which is
>> about whether Websocket API conformance should impose restrictions on
>> which Websocket extensions must and must not be supported, as far as I
>> understand it anyway.
>
>It seems pretty clear that the API specify whatever profile of the
>protocol we choose.  We do the same thing with HTTP (e.g., with the
>XMLHttpRequest API).

HTTP allows you to send messages with `Transfer-Encoding: gzip,chunked`.
Opera supports that in responses, most other browsers do not. The XML-
HttpRequest specification takes no position on that, you can conform to
it whether the XMLHttpRequest implementation supports that or not. The
browsers do agree on supporting `Content-Encoding: gzip`, but again the
XMLHttpRequest specification does not require or prohibit supporting it.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From w3c at adambarth.com  Wed Jul 20 17:43:22 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 20 Jul 2011 17:43:22 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <nqse27djdsv8hi3qjv9nj4egh27eurc3eh@hive.bjoern.hoehrmann.de>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
	<CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>
	<nqse27djdsv8hi3qjv9nj4egh27eurc3eh@hive.bjoern.hoehrmann.de>
Message-ID: <CAJE5ia915E7TobEo0CUTjE9=G7QWwJ1_tZNzwzTvSmsu4i6hdw@mail.gmail.com>

On Wed, Jul 20, 2011 at 5:38 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>>> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
>>> not a solution to the problem Takeshi Yoshino raised though, which is
>>> about whether Websocket API conformance should impose restrictions on
>>> which Websocket extensions must and must not be supported, as far as I
>>> understand it anyway.
>>
>>It seems pretty clear that the API specify whatever profile of the
>>protocol we choose. ?We do the same thing with HTTP (e.g., with the
>>XMLHttpRequest API).
>
> HTTP allows you to send messages with `Transfer-Encoding: gzip,chunked`.
> Opera supports that in responses, most other browsers do not. The XML-
> HttpRequest specification takes no position on that, you can conform to
> it whether the XMLHttpRequest implementation supports that or not. The
> browsers do agree on supporting `Content-Encoding: gzip`, but again the
> XMLHttpRequest specification does not require or prohibit supporting it.

XMLHttpRequest imposes restrictions on the HTTP transport that are not
imposed by HTTP itself.  I don't see any reason why an API can't
restrict the protocol elements generated through the use of the API.
You can argue whether we should impose those restrictions, but we
certainly can.

Adam

From jat at google.com  Wed Jul 20 18:12:56 2011
From: jat at google.com (John Tamplin)
Date: Wed, 20 Jul 2011 21:12:56 -0400
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
Message-ID: <CABLsOLA0z-+Z4McW8LH2ziZm-o-x8CcPe=_95msWFGyVyiuvGA@mail.gmail.com>

On Wed, Jul 20, 2011 at 6:54 PM, Adam Barth <w3c at adambarth.com> wrote:

> Isn't the obvious solution to both problems to apply compression before
> masking?
>

Yes.  However, that is not what deflate-stream does.  There has been a
proposal for deflate-frame which would do exactly that, but it has not been
accepted as of yet and there seems to be some resistance to including it in
the base spec at the expense of further delaying it.

deflate-stream was created as a "better than nothing" compression nobody
objected to that served as an example in the spec of an extension.  Since
then, largely due to your work, masking client->server traffic was added
which reduced the value of deflate-stream in that direction and also
requiring the extension be handled outside the normal framing.

The fact that the WS API would mandate deflate-stream and not allowing
browser to support other extensions would in fact prevent the deployment of
deflate-frame later, or for that matter any other improvements.  I could
hope that browsers would ignore that requirement and support other
extensions, but then the spec isn't reflecting reality.

As a further example, if multiplexing is added later, it may well need to
have compression at a different level (otherwise mux/demux operations have
to decompress and recompress) -- mandating deflate-stream would again
complicate that scenario.

-- 
John A. Tamplin
Software Engineer (GWT), Google

From shawn at mozilla.com  Thu Jul 21 12:31:22 2011
From: shawn at mozilla.com (Shawn Gong)
Date: Thu, 21 Jul 2011 12:31:22 -0700 (PDT)
Subject: [whatwg] About the HTML spec inconsistency in URL APIs' Collect URL
 Parameters definition
In-Reply-To: <2061317895.598589.1311274186203.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <1834458172.599023.1311276682070.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

Hello,

When collecting URL Parameters, if we have "a&&b", since the parameter between "&&" is empty, we ignore it, and get the parameterNames ["a", "b"]; however, if we have "a&=&b" then we'll get a parameter with empty name and empty value, and have the parameterNames ["a", "", "b"]. The two behaviors are inconsistent. Should we modify the spec to keep the consistency?

Best,
Shawn Gong

(Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en)

From Simetrical+w3c at gmail.com  Thu Jul 21 12:59:53 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 21 Jul 2011 15:59:53 -0400
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
	<CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
Message-ID: <CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>

On Wed, Jul 20, 2011 at 6:23 PM, Tim Down <timdown at gmail.com> wrote:
> Yes, but it's significantly better than the alternative, which is to
> write your own code to search for text that spans nodes.

It shouldn't be *too* hard to write that code.  First do the search in
textContent and get a list of the offsets of all the results.  Then
get a list of Text nodes, and iterate through them.  Record the sum of
their lengths as you go, and when you get to the right place, store
the result.  I'd guess it would be 20 lines or so.  Something like
this (untested):

function findStrings(root, search) {
    var offsets = [];
    for (var i = root.textContent.indexOf(search); i != -1; i =
root.textContent.indexOf(search, i + 1)) {
        offsets.push(i);
    }
    var results = [];
    var treeWalker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT);
    var currentOffset = 0;
    while (treeWalker.nextNode()) {
        while (offsets.length
        && currentOffset <= offsets[offsets.length - 1]
        && offsets[offsets.length - 1] < currentOffset +
treeWalker.currentNode.length) {
            results.push([treeWalker.currentNode,
offsets[offsets.length - 1] - currentOffset]);
            offsets.pop();
        }
        currentOffset += treeWalker.currentNode.length;
    }
    return results;
}

Probably buggy, but something like that should work.  (And hey, it's
19 lines, good guesswork.)  Granted, if you wanted to do any kind of
normalization it would be more complicated to author, but also more
complicated to spec.  So I don't see really a use-case here that's
strong enough to justify this, if we can get rid of it.

> Agreed. My number two feature (well, it would make the top 5, at
> least) would be removing the restriction on execCommand() only working
> on editable content. This very use case shows that its usefulness
> extends beyond editable content. The temporarily-switch-designMode-on
> workaround is ugly, and destroys the selection in some browsers.

As I said elsewhere, I disagree.  Wanting to only modify editable
content is an important use-case.  It's easy to emulate the behavior
you want if that restriction is in place (temporarily turn on
designMode), but nearly impossible to emulate the opposite behavior if
it's not built in to start with.  If execCommand() worked on any
content at all, then text editors would be permanently forced to use
iframes with designMode instead of being able to use contenteditable,
just to avoid the user randomly bolding or deleting interface text.
Also, it would mean that (for instance) execCommand("delete") works
differently from the backspace key.

If turning designMode on destroys the selection in some browsers,
that's a bug that can easily be fixed, and doesn't justify a change to
the spec.  Changing specs to work around easily-fixed browser bugs
makes much less sense than just fixing the bugs.  The only
disadvantage I see to requiring this is that it's error-prone: the
obvious way to do it is to turn designMode on and then turn it off,
which will have an unexpected side effect if it had already been on.
But that's a minor issue, and I don't see a good way to avoid it.

Why exactly do you not want to turn designMode on and off, other than
easily-fixed browser bugs?  What do you think is "ugly" about it?

From hbono at google.com  Thu Jul 21 20:03:06 2011
From: hbono at google.com (=?ISO-2022-JP?B?SGlyb25vcmkgQm9ubyAoGyRCSzdMbhsoQiAbJEJHbkU1GyhCKQ==?=)
Date: Fri, 22 Jul 2011 12:03:06 +0900
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
Message-ID: <CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>

Greetings all,

This is just out of curiosity.
Would it be possible to give me the encoding used for this "download"
attribute? I think we have several options when we use non-ASCII
characters (this example uses Cyrillic characters) as the value of
this attribute as listed below.

1. Use the same encoding as the one used for the HTML content.
  <a href="..."  download="????.png">????????? ????</a>
(If we allow using '&#x...' format of HTML, it becomes:
  <a href="..."  download="&#x444;&#x430;&#x439;&#x43B;.png">????????? ????</a>

2. Use the URL encoding (same as the "href" attribute).
  <a href="..."  download="%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>

3. Use RFC 2231 (same as the "content-disposition" header)
  <a href="..."
download="UTF-8''%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>

Thank you for your help in advance.

Regards,

Hironori Bono
E-mail: hbono at google.com

On Sat, Jul 16, 2011 at 10:59 AM, Ian Fette (????????)
<ifette at google.com> wrote:
> On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>>
>>> It definitely is an interesting usecase that Glenn brought up about
>>> being able to specify a save-as name without otherwise modifying the
>>> behavior of a reference. However that seems like a much more rare
>>> usecase and so not the one we should optimize for.
>>>
>>
>> Bear in mind that "optimize for" doesn't mean "support at all"; if
>> download=filename is used, it seems unlikely that there will ever be *any*
>> client-side way to supply the filename without implying attachment, which is
>> a very different thing than "not optimizing for it".
>>
>> I don't feel strongly enough about this to press it further, but <a
>> href=ugly download filename=pretty> also seems fairly clean, and avoids
>> combining parameters that really are orthogonal to one another.
>>
>
> I really don't see the importance of the "name the thing that isn't going to
> be downloaded" usecase; there are countless edge cases that we could concern
> ourselves with in HTML but that few users will ever hit, this is one. (I
> also suspect a user sophisticated enough to actually save something, e.g.
> right click save as, is sophisticated enough to be able to type their own
> filename.)I think it's better overall to keep the semantics as clean and
> simple as possible. I suggest we move forward with <a href=blah
> download=filename> with the origin considerations mentioned in the previous
> email and move on.
>
>
>
>
>>
>> --
>> Glenn Maynard
>>
>>
>

From callow_mark at hicorp.co.jp  Thu Jul 21 20:51:46 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Fri, 22 Jul 2011 12:51:46 +0900
Subject: [whatwg] <base> in <body>
In-Reply-To: <op.vywtptlc64w2qv@annevk-macbookpro.local>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>	<4E264659.3040004@mit.edu>
	<op.vywtptlc64w2qv@annevk-macbookpro.local>
Message-ID: <4E28F3D2.2090207@hicorp.co.jp>

> On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu>
> wrote:
>> That said, I'm not sure I understand the security concern.  What kind
>> of whitelist-based filter would let through <script>s whose URIs it
>> does not control, exactly?  Can the security concern be mitigated by
>> only allowing <base> outside <head> if the base URI it sets is
>> same-origin with the document?
>
> The <script> is from the page itself and uses a relative URL. The
> <base> is inserted by the attacker and causes the script to be
> requested from a server under the attacker's control.
>
>
Seems like a bug in the whitelist filter to me. Shouldn't the filter be
checking requests using the full URL just before they are dispatched?

Regards

    -Mark

From bzbarsky at MIT.EDU  Thu Jul 21 20:58:11 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 21 Jul 2011 23:58:11 -0400
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E28F3D2.2090207@hicorp.co.jp>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>	<4E264659.3040004@mit.edu>	<op.vywtptlc64w2qv@annevk-macbookpro.local>
	<4E28F3D2.2090207@hicorp.co.jp>
Message-ID: <4E28F553.6050708@mit.edu>

On 7/21/11 11:51 PM, Mark Callow wrote:
> Seems like a bug in the whitelist filter to me. Shouldn't the filter be
> checking requests using the full URL just before they are dispatched?

We're talking a filter on the HTML generation, not in the browser.

-Boris

From callow_mark at hicorp.co.jp  Thu Jul 21 23:49:49 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Fri, 22 Jul 2011 15:49:49 +0900
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E28F553.6050708@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>	<4E264659.3040004@mit.edu>	<op.vywtptlc64w2qv@annevk-macbookpro.local>	<4E28F3D2.2090207@hicorp.co.jp>
	<4E28F553.6050708@mit.edu>
Message-ID: <4E291D8D.5020607@hicorp.co.jp>

> On 7/21/11 11:51 PM, Mark Callow wrote:
>> Seems like a bug in the whitelist filter to me. Shouldn't the filter be
>> checking requests using the full URL just before they are dispatched?
>
> We're talking a filter on the HTML generation, not in the browser.
>
> -Boris
Ahh! Got it. Thanks.

    -Mark

From ian at hixie.ch  Thu Jul 21 23:58:44 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 06:58:44 +0000 (UTC)
Subject: [whatwg] Forcing a download
In-Reply-To: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>

On Sat, 9 Apr 2011, Glenn Maynard wrote:
> >
> > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
> 
> A big +1 to the proposal in this thread, to allow specifying 
> Content-Disposition behavior in anchors.

I believe I last responded to feedback on this topic in August last year:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028148.html

...with a minor addition in December:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029350.html

However, feedback since has introduced a new wrinkle that I do not believe 
was thoroughly examined in previous threads on the topic: the issue of how 
to specify an explicit filename, which is especially relevant for a number 
of use cases mentioned below.


> <a download=filename.txt> would have the effect of adding (or 
> overriding) the header "Content-Disposition: attachment; 
> filename=filename.txt".
> 
> It would mean I'd no longer need to use server-side hacks to cause 
> Content-Disposition to be sent for download links, eg. where 
> "?download=1" adds the C-D header.
> 
> I also just now had to implement a server-side script that receives 
> base64 file data and a filename in parameters, and responds by echoing 
> it back. That's an ugly hack to allow client-side data to be saved to 
> disk, and doesn't work with serverless web apps.  This would be fixed, 
> allowing both data: URLs and File API object URLs as download links.

This download="" attribute seems like a reasonable idea.


On Sun, 10 Apr 2011, Bjartur Thorlacius wrote:
>
> Right. As an end-user I ask: Does a web developer publishing links to 
> resources have a say as to whether I render aforementioned resource 
> immediately, write it to disk or both?

It should always be up to the user to have the final say, but the use 
cases presented here suggest that it makes sense to at least give authors 
the opportunity to provide a hint as to what the default behaviour should 
be for links.


> Better yet, File API could have an API for writing blobs to files.

That would help for some of these cases, but not most. It would also mean 
that what could be expressible purely declaratively requires script, which 
is something we generally try to avoid. Declarative semantics are easier 
to process using static analysis tools, for instance.


On Sun, 10 Apr 2011, Glenn Maynard wrote:
>
> (Browsers generally don't have a "show this file in the browser, even 
> though it's C-D: attachment" option on that dialog--they should, but 
> that's a separate issue.)

Indeed, that should probably be addressed as well.


On Thu, 26 May 2011, Dennis Joachimsthaler wrote:
> 
> The filename is only necessary when you feed the file from a dynamic 
> page, like directly from the PHP processor. And in this case you can 
> directly use the contend-disposition HTTP header.

That prevents a single resource from being offered either for view or 
download, unfortunately (users should be able to use context menus, but in 
practice few users do).


> You have files in a folder that are numbered in one continous numbering 
> scheme. The files are heavily downloaded so server side scripting falls 
> out of the question because sending files through this is, to say the 
> least, slow, unless you use some special tricks.
> 
> Instead of giving the user a link to the file called "A342378437.pdf" 
> you can use the disposition attribute to
> 
> a) Let him directly download it. He doesn't have to go the long way 
> around by right clicking this way.
> 
> b) Give it a meaningful name that the user will appreciate

Indeed.


On Fri, 3 Jun 2011, Bjartur Thorlacius wrote:
>
> Use the last non-empty path component for a short name prone to 
> accidental clashes, or the title for a verbose, unportable and 
> descriptive name. It's purely a hint for user convenience (so they don't 
> have to invent their own names or retype the title). What a file is 
> named on a client's machine is purely the client's matter.

Using the title="" doesn't really work because what is appropriate for a 
tooltip and what is appropriate for a filename might not match.


On Thu, 14 Jul 2011, Ian Fette wrote:
>
> Many websites wish to offer a file for download, even though it could 
> potentially be viewed inline (take images, PDFs, or word documents as an 
> example). Traditionally the only way to achieve this is to set a 
> content-disposition header. *However, sometimes it is not possible for 
> the page author to have control over the response headers sent by the 
> server.* (A related example is offline apps, which may wish to provide 
> the user with a way to "download" a file stored locally using the 
> filesystem API but again can't set any headers.) It would be nice to 
> provide the page author with a client side mechanism to trigger a 
> download.
> 
> After mulling this over with some application developers who are trying 
> to use this functionality, it seems like adding a "rel" attribute to the 
> <a> tag would be a straightforward, minimally invasive way to address 
> this use case. <a rel=attachment href=blah.pdf> would indicate that the 
> browser should treat this link as if the response came with a 
> content-disposition: attachment header, and offer to download/save the 
> file for the user.

On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
> 
> rel="enclosure" is sufficient for today's use cases because authors 
> simply name the file accordingly on their server and then 
> implementations simply use the last segment of the URL as the filename - 
> presto 80/20 case solved (and solved 6 years ago with no modification 
> needed to HTML for it to be valid).
>
> Having to specify a "download" attribute that reflects a filename 
> different from the last segment of the URL is the minority case, but 
> still sufficient to justify addition of the attribute.

We can just say that if the attribute has no value it is indicating that 
the author recommends downloading the file. No need for redundancy.


On Fri, 15 Jul 2011, Alexey Proskuryakov wrote:
> 
> What meaning will this attribute have on a platform that simply doesn't 
> expose the notion of a file?

None, presumably the same as "Content-Disposition: attachment" in the same 
case.


> I think that this attribute could be quite confusing, and it will likely 
> become more confusing with time, as more platforms arise that have 
> creative ways of presenting data to users.

Could you elaborate on what confusion you are expecting here?


> It also doesn't naturally help understanding that it's just poor man's 
> Content-Disposition:attachment. From this point of view, I like Ian's 
> original proposal (rel=attachment) more.

Unfortunately, not being able to provide a file name makes it inadequate 
for a number of use cases people have raised.


On Thu, 14 Jul 2011, Glenn Maynard wrote:
> 
> That reminds me of something download=filename can't do: assign a 
> filename while leaving it inline, so "save as" and other operations can 
> have a specified filename.  That would require two separate properties.  
> One case I've come across is <img>, where I want to display an image, 
> but provide a different filename for save-as.  Separating the filename 
> would allow this to be applied generically both links and inline 
> resources: <img src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg 
> filename=picture.jpg>.

I haven't addressed this use case here, but it's definitely something we 
can investigate in the future if download="" proves successful.

(Note that for same-origin cases, you can use Content-Disposition for this 
already. This would only really help with embedding images from other 
sites that don't support giving a filename, e.g. Flickr.)


On Fri, 15 Jul 2011, Glenn Maynard wrote:
> 
> Bear in mind that "optimize for" doesn't mean "support at all"; if 
> download=filename is used, it seems unlikely that there will ever be 
> *any* client-side way to supply the filename without implying 
> attachment, which is a very different thing than "not optimizing for 
> it".
> 
> I don't feel strongly enough about this to press it further, but <a 
> href=ugly download filename=pretty> also seems fairly clean, and avoids 
> combining parameters that really are orthogonal to one another.

On Sat, 16 Jul 2011, Tantek ?~Gelik wrote:
>
> Agreed with Glenn, narrowing the semantic solves this problem neatly:
> 
> * filename="" attribute - what to name the file if saved by the user (by whatever means)
> * existing rel="enclosure" spec - download the link when clicked/activated.
> 
> So the author can choose to do one, or the other, or both. Clean, 
> simple, orthogonal.

On Fri, 15 Jul 2011, Ian Fette wrote:
> 
> I really don't see the importance of the "name the thing that isn't 
> going to be downloaded" usecase; there are countless edge cases that we 
> could concern ourselves with in HTML but that few users will ever hit, 
> this is one. (I also suspect a user sophisticated enough to actually 
> save something, e.g. right click save as, is sophisticated enough to be 
> able to type their own filename.)I think it's better overall to keep the 
> semantics as clean and simple as possible. I suggest we move forward 
> with <a href=blah download=filename> with the origin considerations 
> mentioned in the previous email and move on.

On Sun, 17 Jul 2011, Glenn Maynard wrote:
> 
> A common case is generated PDFs, which are regularly both saved to disk 
> and viewed in-browser (eg. tax forms which are viewed to print and then 
> saved for records).

This is easily solved by providing two links, or an iframe and a link. 
This is probably more usable than one link and expecting the user to 
right-click, too. As Ian says above, if the user is savvy enough to 
right-click, the user is likely not going to find it difficult to give the 
file a name either.


On Thu, 14 Jul 2011, Karl Dubost wrote:
> 
> A random thought just occured to me (maybe dumb)
> But is it a relation qualifier or in fact a target?
>
> [...] what about adding 
> 
> <a href="foo.pdf" target="_download">Save a Tree, Eat a beaver</a>

On Thu, 14 Jul 2011, Bjartur Thorlacius wrote:
>
> This seems like the best solution to me. A filename hint has two use 
> cases: a suggestion for a local identifier, and providing a filename 
> extension for systems that use them to identify file types with 
> incomplete or nonexistent /etc/mime.type media type mappings. I'll only 
> name so many pictures "pic.jpg", so I suggest using the descriptive (and 
> thus verbose) value of the title attribute. The worst problem will be 
> encoding the name on filesystems such as FAT.
> 
> <a href="//samplecdn.example/pix/2011/7/14/party/cake" 
> title="S??kkula??ikaka me?? ??s" target="_download">Afm??liskaka 
> m??n</a>

On Fri, 15 Jul 2011, Jonas Sicking wrote:
> 3)  The target=_download idea is interesting, but I'm not sure we can 
> safely introduce new target values, and this also suffers from not 
> providing a way to specify the downloaded filename.

Indeed.


On Sat, 30 Apr 2011, Michal Zalewski wrote:
>
> Downloading files in general is a very problematic area, because there's 
> a very fragile transition between HTTP MIME type and filesystem 
> extension or other OS-level content determination mechanism. Many 
> browsers either don't try to do anything useful to prevent weird 
> "promotions" from safe to unsafe document types; or enforce decidedly 
> imperfect logic. Allowing attackers to further control this process has 
> some risks.
> 
> [ This is further compounded by the fact that in many cases, it is safer 
> for users to open certain document types, HTML included, from http: URLs 
> than from file:. ]

On Sat, 30 Apr 2011, Michal Zalewski wrote:
> 
> My concern is a bit more straightforward. To use a practical example: 
> just because a social networking site allows nearly arbitrary JPEG files 
> to be uploaded and served as profile pictures (Content-Type: image/jpeg) 
> does not mean that the applications wants users to be offered that 
> content as a download named Security_Update.exe, supposedly coming from 
> that trusted site.

Well again, making sure you don't put an extension on a file that does
not correspond to the type of the resource as reported by the third-party 
site seems like an elementary precaution.


On Thu, 26 May 2011, Boris Zbarsky wrote:
> > 
> > So what does Firefox do in this case?
> 
> I believe it forces the extension to match the MIME type; if the type 
> text/plain the saved filename will be "Important_Security_Update.exe.txt".

That seems like a rather desireable property.


On Thu, 26 May 2011, Boris Zbarsky wrote:
> On 5/26/11 3:12 PM, Dennis Joachimsthaler wrote:
> > Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python 
> > #!/bin/bash could very well result in the text file being executed in 
> > one of those interpreters, right?
> 
> Yes, but even worse on some systems a .pl file will just handed over to 
> the registered handler for those (often a Perl interpreter) if you try 
> to "open" it (which is a different operation from "execute" and can be 
> done even on files that are not executable; think double-clicking the 
> file in a file manager).

The disparity of behaviours amongst file managers on Unix systems is 
indeed problematic. I'm not sure what to suggest there.


On Fri, 3 Jun 2011, Eduard Pascual wrote:
> 
> My post was entirely about the precedence between the two sources of the 
> header, when they conflict. I think is obvious enough that the provider 
> of a resource should be given more weight than a third party referencing 
> to it. Either of the sides can still leave things to whatever default 
> could apply to each case if they don't care; but if both care, and they 
> conflict, the provider of the resource should have the final say over 
> whatever the third party may be requesting.

I don't think it's obvious. In particular, there is a big difference 
between how a link with a download="" attribute could be processed 
compared to how a regular hyperlink could be processed: in the latter 
case, the UA only knows it's going to be a download some way into 
processing the navigation request (and after some irreversible steps like 
aborting other downloads); in the former case, we can bypass all that and 
just do a direct download without navigating to the resource.


A number of people raised issues relating to download="" confusing the 
issue of which origin to trust:

On Sat, 30 Apr 2011, Michal Zalewski wrote:
>
> Note that somewhat counterintuitively, there would be some security 
> concerns with markup-level content disposition controls (or any JS 
> equivalent). For example, consider evil.com doing this:
> 
> <a href='http://example.com/user_content/harmless_text_file.txt' 
> disposition='attachment; filename="Important_Security_Update.exe"'>

On Sat, 30 Apr 2011, Glenn Maynard wrote:
> 
> To do some contriving, in trying to follow the example: if example.com 
> is a site trusted by the user or administrator, it may be flagged in the 
> browser as "always allow saving sensitive file types from this site".  
> If you can override the C-D header remotely, and if there exists (for 
> example) a text file whose contents happen to alias to a dangerous 
> executable, then you could cause a dangerous executable to be saved to 
> disk.  Browsers might need a mechanism to remember whether the effective 
> Content-Disposition header is "trusted" (received from the response, or 
> overridden from the same origin) or not, which is sort of annoying.

On Thu, 2 Jun 2011, Glenn Maynard wrote:
>
> I don't think the issue raised was about getting people to save files, 
> though.  If you can get someone to click a link, you can already point 
> them at something that sets the HTTP C-D header.
> 
> As I recall, the concern was about getting people to do this on files 
> that appear to be from a trusted domain.  That is, evil.com linking to a 
> perl script on trusted.com (or, say, a dual-mode image/ELF file), 
> setting C-D in the link to get it to save-as, perhaps hoping that people 
> will see "from: http://trusted.com" in the save-as dialog.  (I doubt 
> that most users look at that at all; Chrome doesn't even seem to bother 
> displaying it.)
> 
> At worst, it just seems like a minor UI design issue.

On Thu, 2 Jun 2011, Michal Zalewski wrote:
>
> The origin of a download is one of the best / most important indicators 
> people have right now (which, by itself, is a bit of a shame). I just 
> think it would be a substantial regression to make it possible for 
> microsoft.com or google.com to unwittingly serve .exe / .jar / .zip / 
> .rar files based on third-party markup.
> 
> Firefox and MSIE display the origin fairly prominently, IIRC; Chrome 
> displays it in some views. But deficiencies of current UIs are probably 
> a separate problem.

On Thu, 2 Jun 2011, Glenn Maynard wrote:
> 
> Firefox displays it in a small, unimportant-looking piece of text inside 
> a busy dialog; I never even consciously noticed it until I looked for 
> it.  For me, Chrome doesn't say anything; when I click an .EXE it saves 
> it to disk without asking (maybe I changed a preference somewhere--that 
> seems like an unlikely default).
> 
> When I download a file, I decide whether to trust "dangerous" file types 
> based on who's telling me to download it--that is, based on the site 
> linking the file, not the site hosting it.  I'd strongly suspect that 
> more people look at who's linking the file (eg. where they were when 
> they clicked the link), and that very few people examine the "from:" 
> text in the save-as dialog.
> 
> Either way, again this is something that can be dealt with in UI, for 
> example by displaying the source URL as the source of the download 
> rather than or in addition to the domain hosting the file when this 
> attribute is used.  It's a weak argument against this feature.

On Fri, 15 Jul 2011, Jonas Sicking wrote:
>
> One concern which was brought up was the ability to cause the user to 
> download a file from a third party site. I.e. this would allow evil.com 
> to trick the user into downloading an email from the users webmail, or 
> download a page from their bank which contains all their banking 
> information. It might be easier to then trick the user into re-uploading 
> the saved file to evil.com since from a user's perspective, it looked 
> like the file came from evil.com
> 
> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file
> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com
> 
> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.
> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.
> 
> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.
> 
> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.
> 
> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.

On Sun, 17 Jul 2011, Adam Barth wrote:
> 2011/7/15 Jonas Sicking <jonas at sicking.cc>:
> >
> > One concern which was brought up was the ability to cause the user to 
> > download a file from a third party site. I.e. this would allow 
> > evil.com to trick the user into downloading an email from the users 
> > webmail, or download a page from their bank which contains all their 
> > banking information. It might be easier to then trick the user into 
> > re-uploading the saved file to evil.com since from a user's 
> > perspective, it looked like the file came from evil.com
> 
> It seems like the solution to that problem is to be clear about where 
> the download is coming from.  Being clear about where downloads come 
> from is important in many scenarios, beyond just this setting.
> 
> > Another possible attack goes something like:
> > 1. evil.com tricks the user into downloading sensitive data from bank.com
> > 2. evil.com then asks the user to download a html from evil.com and
> > open the newly downloaded file
> 
> Most browsers treat downloaded HTML files as "dangerous downloads," 
> which means they get similar UI treatment to executable downloads. For 
> example, on Mac OS X, HTML downloads get the same "you're about to open 
> a dangerous file" warning from the operating system as executable 
> downloads.  If the attacker can convince the the user to click past 
> these dialogs, the attacker can convince the user to run arbitrary code 
> anyway, so there's nothing we can do to provide security in this 
> setting.
> 
> > 3. the html file contains script which reads the contents from the 
> > file downloaded from bank.com and sends it back to evil.com
> 
> This sounds like a security vulnerability in the browser.  A better 
> security posture is to not allow downloaded content from one web site 
> read downloaded content from another web site, regardless of how the 
> content was downloaded.  For example, that's the current behavior of 
> Chrome and Internet Explorer.  Safari takes a different approach and 
> allows downloaded HTML content to access any file and any web site, 
> which means the attacker doesn't need to go through the elaborate 
> process you've outlined.  Merely performing step (3) is sufficient to 
> steal all the user's banking details today, which tells me that either 
> Safari is already vulnerable to this attack without this new feature or 
> that this threat isn't actually much of a risk.
> 
> (I know that Firefox has a policy that's somewhere in between the strong 
> local-file security policy used by Chrome and the weak policy used by 
> Safari, but Firefox's policy is too complex for me to understand.  I 
> know that protection of downloaded files was one of the considerations 
> that fed into the design of Firefox's policy, but I'll leave it to 
> others to common on whether it provided effective protection in this 
> scenario.)
> 
> > Step 1 and 2 require the user to answer "yes" to a dialog displayed by 
> > the browser. However it's well known that users very often hit 
> > whichever button they suspect will make the dialog go away, rather 
> > than actually read the contents of the dialog.
> 
> In that model, the attacker can just run arbitrary code.  It's not 
> possible to provide security in that model, regardless of this feature.
> 
> > Step 3 again requires the user to answer "yes" to a dialog displayed 
> > by the browser in at least some browsers. Same caveat applies though.
> 
> In this case, the caveats are important.  As described above, Chrome is 
> not vulnerable to this attack and Safari is vulnerable to this attack 
> even without this feature.
> 
> > One very simple remedy to this would be to require CORS opt-in for 
> > cross-site downloads. For same-site downloads no special opt-in would 
> > be required of course.
> 
> I'm not convinced there's a problem to solve here.  Wiring CORS into the 
> download system, by contrast, add a significant amount of complexity to 
> the implementation, which is costly.
> 
> > It's also possible that it would be ok to do this without any opt-ins 
> > since there are a good number of actions that the user has to take in 
> > all these scenarios. Definitely something that I'd be ok with 
> > discussing with our security team.
> 
> I'm happy to talk it over with your security folks if they disagree with 
> the contents of this email.

(Jonas questioned some of the premises above, but not Adam's basic points 
which IMHO make the presented risk somewhat irrelevant as the same 
assumptions would lead to far bigger problems already.)


> > Tentatively I would feel safer with the CORS option though. And again, 
> > for same-site downloads this isn't a problem at all, but I suspect 
> > that in many cases the file to be downloaded is hosted on a separate 
> > server.
> 
> It's important to think these scenarios through carefully, but in this 
> case I think we're fine without CORS.

In fact, using CORS here seems like it would _add_ a vulnerability: it 
would mean that any site that wants to allow another site to let the user 
download a file from that site can in addition simply read the file! Given 
the huge amount of concern we have shown over the possibility that authors 
will accidentally set CORS headers on too many pages, this sounds like a 
very dangerous thing to be encouraging.


Adam Barth also wrote:
> 
> There's also complexity for authors, who need to set the appropriate 
> headers and to worry about authenticated versus unauthenticated 
> requests.  Worse, in some deployment scenarios, requiring CORS to use 
> this feature actually exposes the sites to greater risk because they 
> might set ACLs on these resources that are broader than needed. Here's 
> an example:
> 
> 1) A webmail service wants to offer attachments for download.
> 2) The webmail service is security conscious, so it renders email
> messages in a sandboxed iframe in case it's email rendering contains
> an XSS hole (which is quite possible, especially with rich-text, HTML
> email).
> 3) The webmail service wants to include links to download email
> attachments using this feature.
> 
> In order for the links to work (assuming the links appear in context in 
> the email, as they do in Outlook, for example), the webmail provider 
> needs to set CORS headers that grants the sandboxed iframe access to the 
> attachments.  Because the sandboxed iframe runs in a unique origin (for 
> maximum security), the only CORS ACL that works is 
> "Access-Control-Allow-Origin: *".  However, that ACL allows any other 
> web site to read the contents of the user's attachments!  Now, maybe you 
> could work around that issue using unguessable URLs for the attachments, 
> but you'd still be exposing the contents of the attachments if there's 
> an XSS in the mail rendering code, a vulnerability that would not be 
> present if the downloads feature wasn't coupled to CORS.
> 
> In summary, using CORS for this purpose is costly (both to implementors 
> and to authors), and I don't think it solves a real security problem.

Indeed.


On Fri, 15 Jul 2011, Ian Fette wrote:
> 
> So, in the interest of making progress, what if we tried...
> 
> download=filename
> 
> for same origin it's always downloaded (includes filesystem api from 
> that origin) for cross-origin it's downloaded if we get a positive CORS 
> response and/or we get a content-disposition attachment for cross-origin 
> if we don't get positive CORS response OR content-disposition:attachment 
> we don't download
> 
> We can always start conservative and broaden out.

On Fri, 15 Jul 2011, Jonas Sicking wrote:
> 
> I know that I would personally feel a lot more comfortable if the site 
> opted in to allowing downloads of the resource in question. But it's 
> quite possible that I'm overly paranoid.
> 
> Though one thing to keep in mind is sites that explicitly state that a 
> resource should *not* reach the users disk. This is today often done 
> using "Cache-Control: no-store". Seems scary to allow such content to be 
> saved based on a cross-site request.

On Mon, 18 Jul 2011, Jonas Sicking wrote:
> 
> Any site that want to allow downloads without risking sharing data can 
> simply add "content-disposition: attached" headers. So no risk of 
> leaking too much data required.

Is there any reason to use CORS here at all? It seems like the simpler 
solution would be the following:

 - If download="" is set, then by default trigger a download rather than a 
   navigation action. (User can override via context menu.)
 - Pick a filename for the download as follows:
   - if the received resource has a Content-Disposition: attachment header 
     that specifies a filename, use that.
   - otherwise, if the received resource has a Content-Disposition header 
     that specifies a filename, and the resource is same-origin, use that
     filename.
   - otherwise, if the received resource is same-origin and the 
     download="" attribute specifies a filename, use that.
   - otherwise, if the received resource has a Content-Disposition: 
     attachment header and the download="" attribute specifies a filename, 
     use the filename from the attribute.
   - otherwise, if the received resource is same-origin then derive a 
     filename from the resource.
   - otherwise, either abort or alert the user that a file is being 
     downloaded from a different origin and prompt for a filename.
 - If a mapping from the MIME type to an extension is known, but the 
   filename doesn't have that extension, add it.

This is what I've used for now (modulo some allowances for user 
interfaces), but I welcome suggests for changing this.

One thing this doesn't handle is the case of a resource on the server not 
having a known type, and the download="" filename (or indeed the URL 
itself) having a potentially dangerous extension (like .exe). I figure 
this is no more dangerous than the server having the right type in this 
case, if the right type is a dangerous type.


On Mon, 18 Jul 2011, Glenn Maynard wrote:
> 
> If I link directly to the file to download, users should trust the file 
> as much as they trust *my* site, rather than Google itself, since the 
> download is, from their perspective, coming from me and not them.

It's not quite that simple. If your site is an HTTPS site, and you link to 
an HTTP site, then the downloaded resource musn't be trusted as much as 
your site, since it could have been tampered with in-flight.


> So, if a hosting service doesn't want to allow executable files, it 
> won't show files as executable from their own download pages, which is 
> what should matter as far as that site's trust is concerned.  People 
> using this mechanism to serve executable files from external links may 
> be annoying, but it shouldn't cause trust issues.

This implies the hosting service has to prevent pages from including 
download="" attributes pointing to itself, of course.


On Tue, 19 Jul 2011, Alexey Proskuryakov wrote:
>
> The fact that hosting implies a certain degree of trust is also built 
> into client software. For example, if you download an executable file on 
> Mac OS X, then the system warns you about it on first launch, and tells 
> you where it was downloaded from, not where a link to the download was.

Which URL is given there of course depends on what URL the browser decides 
to put there. It could be the page's URL.

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

From ian at hixie.ch  Fri Jul 22 00:00:33 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 07:00:33 +0000 (UTC)
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E26F413.5090302@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
Message-ID: <Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>


(These e-mails were sent after I started working on the previous one.)

On Wed, 20 Jul 2011, Chris Bentzel wrote:
>
> Who should be trusted for filename if the one specified by <a> on the 
> referring page differs from the one specified by Content-Disposition on 
> the to-be-downloaded resource?

I've specified that the header wins.


On Wed, 20 Jul 2011, Julian Reschke wrote:
> 
> That being said, if you want to go down the road, make it clear how the 
> file name actually is extracted from the header field in an 
> interoperable way.

That isn't really in scope for the HTML spec, it's something either for 
the HTTP spec or the Content-Disposition spec (if HTTP doesn't define th 
header itself) to define.

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

From ian at hixie.ch  Fri Jul 22 00:06:49 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 07:06:49 +0000 (UTC)
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
	<CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107220706160.2079@ps20323.dreamhostps.com>

On Fri, 22 Jul 2011, Hironori Bono (???? ????) wrote:
> 
> This is just out of curiosity. Would it be possible to give me the 
> encoding used for this "download" attribute? I think we have several 
> options when we use non-ASCII characters (this example uses Cyrillic 
> characters) as the value of this attribute as listed below.

It's whatever encoding is used for the page. Attributes are just Unicode, 
parsed by the same parser as the rest of the page.

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

From julian.reschke at gmx.de  Fri Jul 22 00:10:21 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 22 Jul 2011 09:10:21 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
Message-ID: <4E29225D.2020908@gmx.de>

On 2011-07-22 09:00, Ian Hickson wrote:
>
> (These e-mails were sent after I started working on the previous one.)
>
> On Wed, 20 Jul 2011, Chris Bentzel wrote:
>>
>> Who should be trusted for filename if the one specified by<a>  on the
>> referring page differs from the one specified by Content-Disposition on
>> the to-be-downloaded resource?
>
> I've specified that the header wins.
>
>
> On Wed, 20 Jul 2011, Julian Reschke wrote:
>>
>> That being said, if you want to go down the road, make it clear how the
>> file name actually is extracted from the header field in an
>> interoperable way.
>
> That isn't really in scope for the HTML spec, it's something either for
> the HTTP spec or the Content-Disposition spec (if HTTP doesn't define th
> header itself) to define.

Is there a specific reason why the new text doesn't mention 
Content-Disposition anymore?

Best regards, Julian


From julian.reschke at gmx.de  Fri Jul 22 00:22:56 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 22 Jul 2011 09:22:56 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
	<CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
Message-ID: <4E292550.4050309@gmx.de>

On 2011-07-22 05:03, Hironori Bono (?? ??) wrote:
> Greetings all,
> 
> This is just out of curiosity.
> Would it be possible to give me the encoding used for this "download"
> attribute? I think we have several options when we use non-ASCII
> characters (this example uses Cyrillic characters) as the value of
> this attribute as listed below.
> 
> 1. Use the same encoding as the one used for the HTML content.
>    <a href="..."  download="????.png">????????? ????</a>
> (If we allow using '&#x...' format of HTML, it becomes:
>    <a href="..."  download="&#x444;&#x430;&#x439;&#x43B;.png">????????? ????</a>
> 
> 2. Use the URL encoding (same as the "href" attribute).
>    <a href="..."  download="%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>
> 
> 3. Use RFC 2231 (same as the "content-disposition" header)
>    <a href="..."
> download="UTF-8''%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>
> 
> Thank you for your help in advance.

It's the same as with any other HTML attribute.

The thing you mention in 3) is a special mechanism only needed in HTTP
header fields (btw updated by RFC 5987), and doesn't apply here.

Best regards, Julian

From ian at hixie.ch  Fri Jul 22 00:24:45 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 07:24:45 +0000 (UTC)
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E29225D.2020908@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
	<4E29225D.2020908@gmx.de>
Message-ID: <Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>

On Fri, 22 Jul 2011, Julian Reschke wrote:
> > 
> > That isn't really in scope for the HTML spec, it's something either 
> > for the HTTP spec or the Content-Disposition spec (if HTTP doesn't 
> > define th header itself) to define.
> 
> Is there a specific reason why the new text doesn't mention 
> Content-Disposition anymore?

Not only does the new text mention Content-Disposition, it actually refers 
to its specification multiple times. Are you looking at the right diff?

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

From simon.madine at nokia.com  Fri Jul 22 00:30:39 2011
From: simon.madine at nokia.com (simon.madine at nokia.com)
Date: Fri, 22 Jul 2011 07:30:39 +0000
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <op.vyxp8vhute2ec8@aimac.local>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu> <op.vyxnfxdgte2ec8@aimac.local>
	<1311191751.577.5.camel@localhost.localdomain>,
	<op.vyxp8vhute2ec8@aimac.local>
Message-ID: <82630CFC810DB14BB43301B96536D485010F4FDF@008-AM1MPN1-004.mgdnok.nokia.com>

I've been working with a JS polyfill to enable scoped styles optionally including or excluding the direct parent element and, from a CSS writing point-of-view, it feels more natural to be able to affect the parent. The scoped block essentially has influence over the elements it can directly 'see' - parent and siblings.

Either way, there's going to be a neutral container element so it comes down to whether that would be better provided by the author of the page or the author of the included block. 

Simon



________________________________________
From: whatwg-bounces at lists.whatwg.org [whatwg-bounces at lists.whatwg.org] on behalf of ext Kornel Lesi?ski [kornel at geekhood.net]
Sent: 20 July 2011 22:37
To: ash at ashleysheridan.co.uk
Cc: whatwg
Subject: Re: [whatwg] Selectors within <style scoped>

On Wed, 20 Jul 2011 20:55:51 +0100, Ashley Sheridan
<ash at ashleysheridan.co.uk> wrote:

>> <div id=widget>
>>    <style scoped>
>>      #widget foo {}
>>    </style>
>> </div>
>
> While I agree that that might be a common pattern, I disagree that it's
> actually a good one. Consider an ad service which wraps everything in a
> custom <div> tag. If the scope allowed the immediate parent to be
> included as part of the scope, then it could allow the advert to be
> altered in a way that could negatively affect the users of the site the
> ad appeared on.

The site could wrap the ad in another div to prevent that (and this is
typical when the site wants to create fixed-size ad slot).

> The purpose of scope in the style seems to be to protect elements
> outside of the included content and to 'contain' the included content
> that has the <style scoped> element in it, presumably because it's
> coming from an external source. If you allowed the immediate parent as
> your example, then it could allow the 3rd parties who created the advert
> to take over the element beyond what the advert service would prefer to
> be allowed.

For rogue 3rd parties there's <iframe> in seamless and sandboxed flavors.

If author is allowing untrusted and misbehaving code in the DOM, then it's
already game over ? the ad can do anything, including creating <style>
without scope and modifying other stylesheets.

Even scoped style could use position:absolute or fixed to modify looks of
something outside the element.

--
regards, Kornel Lesi?ski

From julian.reschke at gmx.de  Fri Jul 22 03:37:10 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 22 Jul 2011 12:37:10 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
	<4E29225D.2020908@gmx.de>
	<Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>
Message-ID: <4E2952D6.6050201@gmx.de>

On 2011-07-22 09:24, Ian Hickson wrote:
> On Fri, 22 Jul 2011, Julian Reschke wrote:
>>>
>>> That isn't really in scope for the HTML spec, it's something either
>>> for the HTTP spec or the Content-Disposition spec (if HTTP doesn't
>>> define th header itself) to define.
>>
>> Is there a specific reason why the new text doesn't mention
>> Content-Disposition anymore?
>
> Not only does the new text mention Content-Disposition, it actually refers
> to its specification multiple times. Are you looking at the right diff?

I was looking at the diff r6318. Maybe there were more changes?

Best regards, Julian


From annevk at opera.com  Fri Jul 22 03:41:55 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 22 Jul 2011 12:41:55 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E2952D6.6050201@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
	<4E29225D.2020908@gmx.de>
	<Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>
	<4E2952D6.6050201@gmx.de>
Message-ID: <op.vy0nz5st64w2qv@annevk-macbookpro.local>

On Fri, 22 Jul 2011 12:37:10 +0200, Julian Reschke <julian.reschke at gmx.de>  
wrote:
> I was looking at the diff r6318. Maybe there were more changes?

Searching for content-disposition in http://html5.org/r/6318 gives plenty  
of results.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From glenn at zewt.org  Fri Jul 22 09:22:53 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 22 Jul 2011 12:22:53 -0400
Subject: [whatwg] Forcing a download
In-Reply-To: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
	<Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
Message-ID: <CABirCh9pD0ec0BzVyKjMA_O0f1L8HbBdhD5zBpx8nFmOArzgBg@mail.gmail.com>

On Fri, Jul 22, 2011 at 2:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> As Ian says above, if the user is savvy enough to
> right-click, the user is likely not going to find it difficult to give the
> file a name either.

(But again, just because I'm able to do something by hand doesn't mean that
I should be required to.)

> Is there any reason to use CORS here at all? It seems like the simpler
> solution would be the following:
>   - if the received resource has a Content-Disposition: attachment header
>     that specifies a filename, use that.
>   - otherwise, if the received resource has a Content-Disposition header
>     that specifies a filename, and the resource is same-origin, use that
>     filename.
>   - otherwise, if the received resource is same-origin and the
>     download="" attribute specifies a filename, use that.
>   - otherwise, if the received resource has a Content-Disposition:
>     attachment header and the download="" attribute specifies a filename,
>     use the filename from the attribute.
>   - otherwise, if the received resource is same-origin then derive a
>     filename from the resource.
>   - otherwise, either abort or alert the user that a file is being
>     downloaded from a different origin and prompt for a filename.

This doesn't allow cross-origin files to be linked to as both attachment and
inline resources.  Your suggested workaround for the PDF case is to have two
links, but in order to do that cross-origin you'd need to add
"Content-Disposition: attachment" on the file, so that wouldn't work: they'd
both become download links.

Similarly, sites show an image inline and have a separate link to download
it.  For that link to use @download, C-D: attachment would have to be
applied to the images, which is clearly unwanted.

This breaks every case where I've wanted this functionality in the past.  It
doesn't make sense for @download to only work on files which are already
marked as such by Content-Disposition.

If you really want cross-origin @download to be opt-in, then use a separate
header for it ("Allow-Forced-Downloads: *"); don't repurpose C-D like this.

>> So, if a hosting service doesn't want to allow executable files, it
>> won't show files as executable from their own download pages, which is
>> what should matter as far as that site's trust is concerned.  People
>> using this mechanism to serve executable files from external links may
>> be annoying, but it shouldn't cause trust issues.
>
> This implies the hosting service has to prevent pages from including
> download="" attributes pointing to itself, of course.

My point was the opposite; they don't need to do that.  They're not
providing the trojan-as-JPG from their own download pages, and if an
external site links to a file and changes the extension to .EXE, then it's
the external site that users should blame, not the download site.

(That's what I believe will happen, anyhow, since that's the site in the
address bar when the user clicks the link, which I expect is what users
examine, not eg. the small "from:" text in Firefox's save-or-open dialog.  I
think that's sensible, because I don't think it's reasonable to expect users
to make security decisions involving multiple sites; it's hard enough to get
them to look at the address bar before entering a password.)

-- 
Glenn Maynard

From ap at webkit.org  Fri Jul 22 13:27:36 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 22 Jul 2011 13:27:36 -0700
Subject: [whatwg] Forcing a download
In-Reply-To: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
	<Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
Message-ID: <CDE2722E-C7DC-4A7F-8BC5-251BFA27F68A@webkit.org>

> On Tue, 19 Jul 2011, Alexey Proskuryakov wrote:
>> 
>> What meaning will this attribute have on a platform that simply doesn't 
>> expose the notion of a file?
> 
> None, presumably the same as "Content-Disposition: attachment" in the same 
> case.
> 
> 
>> I think that this attribute could be quite confusing, and it will likely 
>> become more confusing with time, as more platforms arise that have 
>> creative ways of presenting data to users.
> 
> Could you elaborate on what confusion you are expecting here?

Having rel=attachment and download be named so differently implies that the functionality is different. For example, I'm sure that many people will waste time trying to see what they can do with @download on an iPhone that they couldn't do before with Content-Disposition.

> On Tue, 19 Jul 2011, Alexey Proskuryakov wrote:
>> 
>> The fact that hosting implies a certain degree of trust is also built 
>> into client software. For example, if you download an executable file on 
>> Mac OS X, then the system warns you about it on first launch, and tells 
>> you where it was downloaded from, not where a link to the download was.
> 
> Which URL is given there of course depends on what URL the browser decides 
> to put there. It could be the page's URL.


For reference, this is how the warning looks: <http://nypop.com/~ap/webkit/quarantine.png>.

A browser can certainly find a way to put an arbitrary original URL here, but the behavior is not limited to browsers. Any application can use the download API, and non-browser applications will not necessarily have the notion of referencing page. Having different data depending on whether you download directly from a browser or using a download manager is of course no good.

That said, as long as we don't need to honor a file extension provided in @download when it doesn't match Content-Type, it may not matter very much if a page gets the chance to modify the base part of the name.

- WBR, Alexey Proskuryakov


From jonas at sicking.cc  Fri Jul 22 14:03:12 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 22 Jul 2011 14:03:12 -0700
Subject: [whatwg] Forcing a download
In-Reply-To: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
	<Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei9Q9zWpc1eqx5UMV+W6Qji9-1mFWCjJRB19uvpL18XTdA@mail.gmail.com>

On Thu, Jul 21, 2011 at 11:58 PM, Ian Hickson <ian at hixie.ch> wrote:
> Is there any reason to use CORS here at all? It seems like the simpler
> solution would be the following:
>
> ?- If download="" is set, then by default trigger a download rather than a
> ? navigation action. (User can override via context menu.)
> ?- Pick a filename for the download as follows:
> ? - if the received resource has a Content-Disposition: attachment header
> ? ? that specifies a filename, use that.
> ? - otherwise, if the received resource has a Content-Disposition header
> ? ? that specifies a filename, and the resource is same-origin, use that
> ? ? filename.
> ? - otherwise, if the received resource is same-origin and the
> ? ? download="" attribute specifies a filename, use that.
> ? - otherwise, if the received resource has a Content-Disposition:
> ? ? attachment header and the download="" attribute specifies a filename,
> ? ? use the filename from the attribute.
> ? - otherwise, if the received resource is same-origin then derive a
> ? ? filename from the resource.
> ? - otherwise, either abort or alert the user that a file is being
> ? ? downloaded from a different origin and prompt for a filename.
> ?- If a mapping from the MIME type to an extension is known, but the
> ? filename doesn't have that extension, add it.
>
> This is what I've used for now (modulo some allowances for user
> interfaces), but I welcome suggests for changing this.

The "otherwise, either abort or alert the user that a file is being
downloaded from a different origin and prompt for a filename" step
seems to allow to *very* different browser behaviors, resulting in a
site working in one browser, but not in another.

I'm still trying to find a date when we can do a security review about
this in mozilla though. It still does seem very strange to me that a
bank site which sends "cache-control: no-store" for a resource in
order to prevent it from being temporarily stored on the users hard
drive, can still end up being *permanently* stored on a users hard
drive. All that's needed is for the user to click a 'yes' button on a
download dialog while watching a seemingly harmless site.

/ Jonas

From ian at hixie.ch  Fri Jul 22 15:33:15 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 22:33:15 +0000 (UTC)
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>

On Thu, 21 Apr 2011, James Kozianski wrote:
> 
> I'd like to propose the following changes to the registerProtocolHandler 
> spec. [...]

Before I study the proposals in detail, is there a description of the 
kind of experience we're trying to enable here?

What are the UIs we expect to see page use wih registerProtocolHandler()?

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

From kornel at geekhood.net  Fri Jul 22 16:09:54 2011
From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=)
Date: Sat, 23 Jul 2011 00:09:54 +0100
Subject: [whatwg] Page displayed during/after download (<meta refresh>
	downloads)
Message-ID: <op.vy1mmspjte2ec8@aimac.local>


There is a design (anti)pattern related to file downloads: instead of  
linking to a file directly, websites use "Download" links pointing to a  
page with <meta refresh="5; url=actual URL to download"> (or equivalent  
javascript) and "Thank you!" text or further instructions how to use  
downloaded file (e.g. install an application).

Examples:

http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_10.3_for_Mac_OS_X_10.4_-_10.6_(Intel)
http://sourceforge.net/projects/vlc/files/1.1.11/macosx/vlc-1.1.11.dmg/download
http://www.opera.com/download/get.pl?id=33846&thanks=true&sub=true
http://www.google.com/chrome/thankyou.html?hl=en-GB&platform=mac

This is problematic, because:

* it's hard or impossible to see or copy URL of the file (to download with  
another application, share URL, check if file type is correct by looking  
at the filename)

* Right-click and "Save As" on "Download now" links is unreliable and  
sometimes results in HTML downloaded

* "Thank you!" pages saved in browsing sessions cause files to be  
re-downloaded every time browser is restarted

* Extra pages and <meta refresh> cause unnecessary delays. "Your download  
will start in 5 seconds" is very annoying when download itself takes  
couple of seconds.


I wish this could be replaced with something that doesn't break download  
links.


I think in terms of use-cases it can be expressed as:

1. Show users immediate and very clear feedback that the download is  
starting, even if browser's standard download UI is very subtle or appears  
only after the download server responds.

2. Allow website to show additional information about the download, while  
the download is taking place.

e.g. Instructions what to do with the file after it is downloaded. List of  
mirrors to use in case download is slow or fails. List of related products  
to upsell.

<a download> and UI improvements in browsers might partially cover use  
case #1, but I don't see an easy solution to #2, and partial improvement  
might not be enough to replace <meta refresh> download pages.

And I'm afraid that <meta refresh> also fulfils another case:

3. Make it harder for others to link directly to the file, force them to  
link to a branded landing page.


I think cases #1 and #2 could be satisfied with something like:

<a post-download-href="url of page to navigate to when download starts">

And to satisfy all three cases (without breaking links), it needs to be  
done at HTTP level, by adding HTTP header (or multipart response? or  
attribute to Content-Disposition?) that causes both file download to start  
and a page to be displayed at the same time.

-- 
regards, Kornel Lesi?ski

From svartman95 at gmail.com  Sun Jul 24 20:30:02 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 25 Jul 2011 03:30:02 +0000
Subject: [whatwg] window.status and window.defaultStatus
Message-ID: <4E2CE33A.6010402@gmail.com>

Are JavaScript implementors willing to reimplement window.status? There 
are obvious security problems with drawing an author-provided string 
where a certain URI is expected, but could window.defaultStatus not set 
the name (_NET_WM_NAME or equivalent) of the script's window and 
window.status either override window.defaultStatus temporarily, or sent 
to the user, e.g. through Growl or as a Windows toast.
The window name is already accessible to scripts (by modifying the text 
child of <title> through the DOM) so no new security concerns are 
introduced. The Growl binding might well be better by a new function, 
though.

From jgraham at opera.com  Mon Jul 25 01:48:25 2011
From: jgraham at opera.com (James Graham)
Date: Mon, 25 Jul 2011 10:48:25 +0200
Subject: [whatwg] window.status and window.defaultStatus
In-Reply-To: <4E2CE33A.6010402@gmail.com>
References: <4E2CE33A.6010402@gmail.com>
Message-ID: <4E2D2DD9.3090104@opera.com>

On 07/25/2011 05:30 AM, Bjartur Thorlacius wrote:
> Are JavaScript implementors willing to reimplement window.status? There
> are obvious security problems with drawing an author-provided string
> where a certain URI is expected, but could window.defaultStatus not set
> the name (_NET_WM_NAME or equivalent) of the script's window and
> window.status either override window.defaultStatus temporarily, or sent
> to the user, e.g. through Growl or as a Windows toast.
> The window name is already accessible to scripts (by modifying the text
> child of <title> through the DOM) so no new security concerns are
> introduced. The Growl binding might well be better by a new function,
> though.

If you want OS-level notifications you might be interested in [1]

[1] http://dev.w3.org/2006/webapi/WebNotifications/

From ian at hixie.ch  Mon Jul 25 12:02:15 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Jul 2011 19:02:15 +0000 (UTC)
Subject: [whatwg] Physical quantities: <var> or <i>?
In-Reply-To: <172D93ED6EC74255ADA2D5262080E98A@JukanPC>
References: <1DDAC71F28644CD99F84542A4EFAFBEB@JukanPC>
	<BANLkTimQLe75LnjQC2HgyaKrRKu=7fFD=w@mail.gmail.com>
	<172D93ED6EC74255ADA2D5262080E98A@JukanPC>
Message-ID: <Pine.LNX.4.64.1107222252350.2079@ps20323.dreamhostps.com>

On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
>
> Looking at the nice summary (with examples) of text-level markup at 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#usage-summary 
> I started wondering why there is no example of markup for symbols of 
> physical quantities. The descriptions of individual elements or their 
> examples don't seem to say anything about this either.

The main reason is that most of these symbols have Unicode characters and 
don't need special markup.


> So what markup should we use for E = mc?, given that by the applicable
> standards, E, M, and c should appear in italics and the other characters as
> normal (upright)?

It sounds like you want to use these characters:

   U+1D438 MATHEMATICAL ITALIC CAPITAL E
   U+1D45A MATHEMATICAL ITALIC SMALL M
   U+1D450 MATHEMATICAL ITALIC SMALL C

Alternatively, you can use MathML to mark up the equation.


> Physical quantities surely satisfy the requirement that "typical 
> typographic presentation is italicized" in the following, and they are 
> to be offset from the normal prose, but why aren't they mentioned in the 
> fairly long list of examples then:
> 
> "The i element represents a span of text in an alternate voice or mood, 
> or otherwise offset from the normal prose, such as a taxonomic 
> designation, a technical term, an idiomatic phrase from another 
> language, a thought, a ship name in Western texts, or some other prose 
> whose typical typographic presentation is italicized." 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element
> 
> (As an aside, the wording "a taxonomic designation" is too broad, as by 
> biological nomenclature rules, genus and species names are to be 
> italiced but higher taxons, e.g. family names, like Canidae, must not. 
> Besides, e.g. an English name of a species is taxonomic too... So 
> "scientific names of organisms" would be a better formulation.)

Whether you want something in italics or not is more a matter for CSS than 
a matter for HTML.


> Should we consider the var element as covering physical quantities too? 
> After all, they can be regarded as variables in a broad sense, as 
> symbols that denote different values in different situations. However, 
> <var>c</var> would be odd, wouldn't it, since the symbol denotes a 
> universal constant of nature.

You can look at it as being a variable whose value is a constant of 
nature. I've clarified the spec to indicate that this is fine.


On Thu, 14 Apr 2011, Bjartur Thorlacius wrote:
>
> Well, a constant isn't really variable any more, is it? I thought <var> 
> was meant to mark up text that couldn't simply be 'copypasted' without 
> filling in the unknowns (free variables). Defined variables (whether in 
> source code or formulae) do not conform to that definition.
> 
> So, <code>rm -r <var>$path</var></code> would conform (as a reply to the 
> question "how does one remove a (potentially non-empty) directory on 
> *nix?") as $path is undefined, but <code><var>i</var>++</code> would 
> not, as i isn't ment to be substituted.

What do you base this interpretation on?


On Sat, 16 Apr 2011, Jukka K. Korpela wrote:
> 
> Besides, there is no implied uniform rendering for variables in the 
> current broad meaning for <var>. In mathematics, variables are 
> conventionally written in italics. But the HTML(5) notion of variable is 
> wider: "The var element represents a variable. This could be an actual 
> variable in a mathematical expression or programming context, or it 
> could just be a term used as a placeholder in prose." A programming 
> language variable is something that is _not_ conventionally rendered in 
> italics. Rather, they are usually (though for no really good reason) 
> rendered in a monospace font, like any other expressions in computer 
> languages.

Indeed. And vectors are usually bold. This is the kind of thing I would 
expect to see handled using classes, e.g.:

   <var class=vector>a</var> &#x2A2F; <var class=vector>b</var> =
   <var>a</var> <var>b</var> sin <var>&theta;</var> <var class=vector>n</var>


> Too bad there's no example of <var> used in programming context. The 
> current wording suggests that it would be normal, when discussing 
> programming, to write, say, "Then we define the variable 
> <var>myFoo</var> of type <code>fooType</code> with initial value 
> <code>"Foo"</code> - -", which really makes no sense, even if we use 
> both <var> and <code> for myFoo.

Why does it make no sense?

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

From svartman95 at gmail.com  Mon Jul 25 15:45:15 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 25 Jul 2011 22:45:15 +0000
Subject: [whatwg] Page displayed during/after download (<meta refresh>
 downloads)
In-Reply-To: <op.vy1mmspjte2ec8@aimac.local>
References: <op.vy1mmspjte2ec8@aimac.local>
Message-ID: <4E2DF1FB.4090006@gmail.com>

?ann f?s 22.j?l 2011 23:09, skrifa?i Kornel Lesi?ski:
> 2. Allow website to show additional information about the download,
> while the download is taking place.
>
> And to satisfy all three cases (without breaking links), it needs to be
> done at HTTP level, by adding HTTP header (or multipart response? or
> attribute to Content-Disposition?) that causes both file download to
> start and a page to be displayed at the same time.
>
Sending multiple responses in reply to a single request is generally 
useful, but seems hard to implement in a fashion compatible with HTTP 
pipelining clients.
How about a JavaScript opening a new browsing context and navigating it 
to the additional metainformation when the user follows the link?

From shawn at mozilla.com  Mon Jul 25 16:00:12 2011
From: shawn at mozilla.com (Shawn Gong)
Date: Mon, 25 Jul 2011 16:00:12 -0700 (PDT)
Subject: [whatwg] When initializing a JS URL object,
 do we handle the case of 0 argument?
In-Reply-To: <1224548462.638617.1311633980644.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <1911155557.638885.1311634812090.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

(Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en)

The incoming arguments plainURL and baseURL are optional. The question is, when there is no argument provided, do we return an error or treat it normally, then assign the URL later? If so, which interface do we use to assign the URL? href?

Thanks!
Shawn Gong

From w3c at adambarth.com  Mon Jul 25 16:23:53 2011
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 25 Jul 2011 16:23:53 -0700
Subject: [whatwg] When initializing a JS URL object,
 do we handle the case of 0 argument?
In-Reply-To: <1911155557.638885.1311634812090.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
References: <1224548462.638617.1311633980644.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<1911155557.638885.1311634812090.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <CAJE5ia9ShOSJer-jKoEtBq_3hgbH8nZyGzJHYUQEV9UymjnmOQ@mail.gmail.com>

I've made the first URL non-optional.

Thanks,
Adam


On Mon, Jul 25, 2011 at 4:00 PM, Shawn Gong <shawn at mozilla.com> wrote:
> (Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en)
>
> The incoming arguments plainURL and baseURL are optional. The question is, when there is no argument provided, do we return an error or treat it normally, then assign the URL later? If so, which interface do we use to assign the URL? href?
>
> Thanks!
> Shawn Gong
>

From koz at chromium.org  Mon Jul 25 20:31:28 2011
From: koz at chromium.org (James Kozianski)
Date: Tue, 26 Jul 2011 13:31:28 +1000
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>
Message-ID: <CALmvxBf3+3g5eH1CG3yFEeF8sfOjJM05hp+X184iFaq5zyOT=A@mail.gmail.com>

Hi Ian,

Here are the use cases I had in mind:

1. Allow sites to conditionally show UI to promote the advantages of
registering the site as a handler.
   (requires isRegistered)

2. Allow sites to provide settings screens which allow users to register
/ deregister handlers from within the site.
   (requires isRegistered, and deregisterProtocolHandler)

The presence of an ignored list - sites who don't have permission to use
registerProtocolHandler - necessitates Michael Davidson's suggestion that
isRegistered() should return a tri-state value (REGISTERED, DECLINED,
NOTASKED). Otherwise sites that have been 'ignored' by a user won't be able
to tell if they should show their promotional UI or not.

Cheers,
James


On Sat, Jul 23, 2011 at 8:33 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 21 Apr 2011, James Kozianski wrote:
> >
> > I'd like to propose the following changes to the registerProtocolHandler
> > spec. [...]
>
> Before I study the proposals in detail, is there a description of the
> kind of experience we're trying to enable here?
>
> What are the UIs we expect to see page use wih registerProtocolHandler()?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

From ian at hixie.ch  Mon Jul 25 22:30:37 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Jul 2011 05:30:37 +0000 (UTC)
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
References: <4E242D26.3030401@alvestrand.no>
	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
	<CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>

On Thu, 14 Jul 2011, Shwetank Dixit wrote:
> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
> > > 
> > > Another question is flash. As far as I have seen, there seems to be 
> > > no option to specify whether the camera needs to use flash or not. 
> > > Is this decision left up to the device? (If someone is making an app 
> > > which is just clicking a picture of the person, then it would be 
> > > nice to have the camera use flash in low light conditions).
> >
> > getUserMedia() returns a video stream, so it wouldn't use a flash.
> 
> Wouldn't it make sense to have a provision for flash separately then? I 
> think a lot of apps would like just a picture instead of video, and in 
> those cases, flash would be required. Maybe a seperate provision in the 
> spec which defines whether to use flash, and if so, for how many 
> miliseconds. Is that doable?

In response to getUserMedia()? I don't really understand how that would 
work. Could you elaborate? How do you envisage the API working? Maybe a 
concrete example would help.

I'm particularly concerned about two things: preventing hostile sites from 
abusing a flash feature to troll the user, and preventing well-meaning but 
poorly designed sites from using the flash when the user doesn't want it 
to (e.g. when taking a photograph in an area where a flash isn't desired).


On Thu, 14 Jul 2011, timeless wrote:
>
> I'd expect a web app to have no idea about device camera specifications 
> and thus to not be able to properly specify a flash duration. I don't 
> see how such a thing is valuable.
> 
> If a user is in a movie theater, or a museum, it's quite likely they 
> won't notice a web app is forcing a flash. Let the user control flash 
> through a useragent only or host application only mode. I believe the 
> hazards of exposing flash duration outweigh any benefits. The only 
> application class I know of built using control of camera flash is 
> "flash-light", and that's both a hack and not guaranteed to be workable 
> for all possible flash technologies.

Right.


On Fri, 15 Jul 2011, Shwetank Dixit wrote:
> 
> Just like, just allowing the web app to use the camera as it is will not 
> make sense, and presumably, user agents will implement a authorization 
> by the user before the app gains access to the camera (something like 
> 'This application requests access to the camera. Allow for now/Always 
> Allow/Never Allow/Close' just like you do in geolocation right now) ... 
> just like that, you could do it for flash, where the app only gains 
> access to it if the user allows it. If that is the implementation, i do 
> not think there would be much hazards in allowing flash access.

This is quickly going to get frustrating to the user. In general, we'd 
rather not have any such prompts. For example, for video, well-designed 
browsers are likely not going to have a "yes/no" prompt, instead they'll 
just have a prompt that asks the user what camera they want to use. This 
is far less frustrating to the user.


> Apart from helping capture images/video in low light conditions, there 
> are a few other use cases for flash such as the flash light thing you 
> mentioned, as well as a possible S.O.S type app.
>
> I'm fine if the consensus is that the device/user agent will handle the 
> issue of flash by showing some sort of control where the user can click 
> between 'flash on/off/auto'. That will cover *most* of the use cases, 
> which is recording images/video in low light conditions. If so, then it 
> might be good to specify that somewhere in the spec just to make things 
> a bit clearer?

Ok, done.


On Tue, 19 Jul 2011, Per-Erik Brodin wrote:
> 
> Perhaps now that there is no longer any relation to tracks on the media 
> elements we could also change Track to something else, maybe Component. 
> I have had people complaining to me that Track is not really a good name 
> here.

I'm happy to change the name if there's a better one. I'm not sure 
Component is any better than Track though.


> Good. Could we still keep audio and video in separate lists though? It 
> makes it easier to check the number of audio or video components and you 
> can avoid loops that have to check the kind for each iteration if you 
> only want to operate on one media type.

Well in most (almost all?) cases, there'll be at most one audio track and 
at most one video track, which is why I didn't put them in separate lists. 
What use cases did you have in mind where there would be enough tracks 
that it would be better for them to be separate lists?


> I also think that it would be easier to construct new MediaStream 
> objects from individual components rather than temporarily disabling the 
> ones you do not want to copy to the new MediaStream object and then 
> re-enabling them again afterwards.

Re-enabling them afterwards would re-include them in the copies, too.

The main use case here is temporarily disabling a video or audio track in 
a video conference. I don't understand how your proposal would work for 
that. Can you elaborate?


> It is also unclear to me what happens to a LocalMediaStream object that 
> is currently being consumed in that case.

Not sure what you mean. Can you elaborate?


> Why should the label the same as the parent on the newly constructed
> MediaStream object?

The label identifies the source of the media. It's the same source, so, 
same label.


> If you send two MediaStream objects constructed from the same 
> LocalMediaStream over a PeerConnection there needs to be a way to 
> separate them on the receiving side.

What's the use case for sending the same feed twice?


> I also think it is a bit unfortunate that we now have a 'label' property 
> on the track objects that means something else than the 'label' property 
> on MediaStream, perhaps 'description' would be a more suitable name for 
> the former.

In what sense do they mean different things? I don't understand the 
problem here. Can you elaborate?


> > > We prefer having a StreamRecorder that you have to stop in order get 
> > > the recorded data (like the previous one, but with asynchronous Blob 
> > > retrieval) and we do not understand the use cases for the current 
> > > proposal where recording continues until the recorder is garbage 
> > > collected (or the Stream ends) and you always get the data from the 
> > > beginning of the recording. This also has to be tied to application 
> > > quota in some way.
> > 
> > The current design is just the result of needing to define what 
> > happens when you call getRecordedData() twice in a row. Could you 
> > elaborate on what API you think we should have?
> 
> What I am thinking of is something similar to what was proposed in 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030921.html 

That doesn't answer the question of what happens if you call stop() twice.

(Also, having to call a method and hook an event so that you can read an 
attribute seems like a rather round-about way of getting data. Is calling 
a method with a callback not simpler?)


> Preferably quota should be expressed in media time and that is heavily 
> dependent on the format being used and, regardless of any codecs

Quota doesn't seem particularly important here. It's not like you can 
really do lasting damage. It would just be a DOS attack, like creating a 
Web page with an infinite number of 10000x10000 canvases. We can just let 
the "hardware limitation" clause handle it.


> I still think that the format has to be specified somehow.

I continue to agree and continue to intend to wait for implementation 
experience before specifying this. I can't write the spec for this until I 
know what makes sense to spec.


> Perhaps it would be best to push recording to v2 since this does not 
> seem to be the primary use case for people currently showing the most 
> interest in this part of the spec.

Just because you talk more doesn't mean your use cases are more important. :-)


> > > Instead of blob: we would like to use stream: for the Stream URLs so 
> > > that we very early on in the media engine selection can use the 
> > > protocol scheme to determine how the URL will be handled. Blobs are 
> > > typically handled in the same way as other media playback. The 
> > > definition of stream: could be the same as for blob:.
> > 
> > Why can't the UA know which blob: URLs point to streams and which 
> > point to blobs?
> 
> I was not saying that it would not be possible to keep track of which 
> blob: URLs that point to blobs and which point to streams just that we 
> want to avoid doing that in the early stage of the media engine 
> selection. In my opinion a stream is quite the opposite of a blob 
> (unknown, perhaps infinite length vs. fixed length) so when printing the 
> URLs for debugging purposes it would also be much nicer to have two 
> different protocol schemes. If I remember correctly the discussions 
> leading up to the renaming of createBlobURL to createObjectURL assumed 
> that there would be stream: URLs.

You wouldn't be able to remove that logic, since http: URLs would still 
have the same needs. You can have finite and infinite http: resources, 
just like you can have finite and infinite blob: resources. I don't really 
see the problem here. Indeed, with blob:, it's trivial to find out if the 
resource is finite or not; with http: you might not know until the whole 
finite resource is downloaded.

If there is something I'm missing here please do let me know.


> > Actually, the spec doesn't currently say anything happens when a 
> > stream that is being transmitted just ends, either. I guess I should 
> > spec that...
> > 
> > ...ok, now the spec is clear that an ended stream transmits blackness 
> > and silence. Same with if some tracks are disabled. (Blackness only if 
> > there's a video track; silence only if there's an audio track.)
> 
> OK, I guess that could work. In that case you have to manually remove 
> the stream from being sent over a PeerConnection if it unexpectedly 
> ends.

Right. This is desireable; scripts that have not been written to deal with 
unexpected conditions should fail safely, not suddenly find variables are 
changing values in ways that the authors didn't consider.


> Should playing back an ended stream locally in a video element also 
> produce silence and blackness then?

As currently specified, yes.


> We have been assuming network error which has the nice consequence that 
> you can discard ended streams that are only reachable by their stream: 
> URLs even if the URLs are not revoked since trying to play back such a 
> stream: URL is indistinguishable from trying to play back an invalid 
> stream: URL, in that case.

Well by the point a stream: URL can only provide silence and blackness 
there's really not much to keep around, so it's not like it costs much. 
But having them give a network error would be quite tidy, true.

I could go either way on this. On the one hand, it seems good for the 
behaviour to be consistent on both sides of the PeerConnection. On the 
other hand, there's a conceptual neatness to having ended streams act as a 
network error.

Anyone else have a preference?


> > > PeerConnection is an EventTarget but it still uses a callback for 
> > > the signaling messages and this mixture of events and callbacks is a 
> > > bit awkward in my opinion. If you would like to change the function 
> > > that handles signaling messages after calling the constructor you 
> > > would have to wrap a function call inside the callback to the actual 
> > > signal handling function, instead of just (re-)setting an onsignal 
> > > (or whatever) attribute listener (the event could reuse the 
> > > MessageEvent interface).
> > 
> > When would you change the callback?
> 
> If you would like to send the signaling messages peer-to-peer over the 
> data channel, once it is established.

That seems like a disaster waiting to happen. The UDP data channel is 
unreliable, the signaling channel has to be reliable. Worse, the UDP data 
channel might go down at any second, and then the user agent would try to 
re-establish it using the signaling channel.


> > My concern with making the callback an event handler is that it leads to a
> > set of poor failure modes and complications in the API:
> > 
> >   - It's easy to not register a callback, which makes no sense. There's
> >     literally never a use for create a PeerConnection without a signaling
> >     channel, as far as I can tell, so making it easier to create one
> >     without a callback than with seems like a bad design.
> 
> I think this is the case for many APIs.

Just because we made bad APIs before doesn't mean we should do it again!


> For example, creating an EventSource without registering any listener 
> for incoming events equally does not make sense.

Actually, it does. One operation mode for EventSource is to have events 
with different names, each triggering a different event listener.


> >   - It's easy to register multiple callbacks. This equally makes no sense,
> >     and would likely only ever be the source of bugs.
> 
> Yes it would be possible but I am not sure that it would be any easier 
> to make such a mistake than to make any other mistake that would cause 
> the application to malfunction.

We're not comparing how easy it is to make this mistake compared to other 
mistakes, we're comparing how easy it is to make this mistake compared to 
not being _able_ to make this mistake.

The net number of mistakes will be some fraction of the net number of 
possible mistakes. Reduce the second number and you reduce the first.


> >   - It makes getting the data more complicated. Instead of passing the
> >     callback the string to send, we end up passing an object which has on
> >     it one attribute that contains the string.
> 
> Yeah, if getting 'event.data' is more complicated than just getting 
> 'data'.

It's not like the difference between a "Hello World" document and a video 
conferencing app, but it's still more, needless, complexity.


> To get the incoming stream from a StreamEvent (should probably be 
> renamed to MediaStreamEvent for consistency) the author would have to 
> know how to do this anyway.

I'm not saying authors won't have to figure out how to use events; events 
are all over the platform. I'm just saying that if we can make things 
simpler without breaking use cases, as here, we should.

(I fixed the event interface name.)


> > > There is a potential problem in the exchange of SDPs in that glare 
> > > conditions can occur if both peers add streams simultaneously, in 
> > > which case there will be two different outstanding offers that none 
> > > of the peers are allowed to respond to according to the SDP 
> > > offer-answer model. Instead of using one SDP session for all media 
> > > as the specification suggests, we are handling the offer-answer for 
> > > each stream separately to avoid such conditions.
> > 
> > Why isn't this handled by the ICE role conflict processing rules? It 
> > seems like simultaneous ICE restarts would be trivially resolvable by 
> > just following the rules in the ICE spec. Am I missing something?
> 
> This problem is not related to ICE but rather to the SDP offer-answer 
> model which is separate from the ICE processing. The problem is that SDP 
> offer-answer does not allow you to respond to an offer when you have an 
> outstanding offer for the same set of streams.

As far as I can tell, your interpretation is incorrect. This is entirely 
related to ICE, and ICE, as far as I can tell, defines this exact case in 
its role conflict resolution.

The only time this can happen is if you have both ends do an ICE restart 
at exactly the same time. The offer from each ICE agent will be received 
by the other as if it was the response, and thus there will be a role 
conflict and the ICE role conflict resolution process will kick in. No?


> The way we are avoiding this is by sending SDP fragments (only the SDP 
> lines related to the affected stream) rather than the full SDP each 
> time.

That seems completely incompatible with ICE requirements.


On Wed, 20 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> On Mon, Jul 18, 2011 at 20:38, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 18 Jul 2011, Tommy Widenflycht (??~[~O??~Z????~[~X??~[~X??~Z??) wrote:
> > >
> > > I am very confused regarding the below paragraph from the latest 
> > > spec:
> > >
> > > When a track in a MediaStream parent is disabled, any 
> > > MediaStreamTrack objects corresponding to the tracks in any 
> > > MediaStream objects that were created from parent are disassociated 
> > > from any track, and must not be reused for tracks again. If a 
> > > disabled track in a MediaStream parent is re-enabled, from the 
> > > perspective of any MediaStream objects that were created from parent 
> > > it is a new track and thus new MediaStreamTrack objects must be 
> > > created for the tracks that correspond to the re-enabled track.
> > >
> > > After cloning a LocalMediaStream it looks like this:
> > >
> > > LocalMediaStream -> MediaStream1
> > > Track1(E)           Track1(E)
> > > Track2(E)           Track2(E)
> > > Track3(E)           Track3(E)
> > >
> > > and as I interpret the spec it looks like this if Track1 in the 
> > > LocalMediaStream is disabled:
> > >
> > > LocalMediaStream -> MediaStream1
> > > Track1(D)           Track2(E)
> > > Track2(E)           Track3(E)
> > > Track3(E)
> >
> > Correct so far (though I'd avoid the term "cloning" since it's not 
> > quite what's going on here -- the spec uses "forking", which may be 
> > closer though is still not ideal).
> >
> > > So Track1 disappears from the MediaStream1 object and doesn't come 
> > > back even if Track1 in the LMS object is enabled:
> > >
> > > LocalMediaStream -> MediaStream1
> > > Track1(E)           Track2(E)
> > > Track2(E)           Track3(E)
> > > Track3(E)
> >
> > No, it'll create a new track object:
> >
> >  LocalMediaStream -> MediaStream1
> >  Track1(E)           Track4(E)
> >  Track2(E)           Track2(E)
> >  Track3(E)           Track3(E)
> >
> > This is specified in the sentence that starts "If a disabled track in 
> > a MediaStream parent is re-enabled...".
>
> Thanks for the explanation. To me this sounds overly complicated, why 
> not just make it so that an disable of a track will override the track 
> settings for forked MediaStreams?

I don't understand what you mean. How would that be different?


> This will definitely simplify implementation, and confuse web developers 
> less imho. MSTracks coming and going doesn't feel right. Especially 
> since there are no callbacks/events that a MS changes.

You don't need a callback, since only the author can do this in the firstp 
place.


> Also some follow-up questions regarding the new TrackLists:
> 
> What should happen when a track fails? Should the entire stream fail, 
> the MSTrack silently be removed or the MSTrack disassociated with the 
> track (and thus becoming a do-nothing object)?

What do you mean by "fails"?


> What should happen when a stream with two or more video tracks is 
> associated to a <video> tag? Just render the first enabled one?

Same as if you had a regular video file with multiple tracks.

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

From callow_mark at hicorp.co.jp  Mon Jul 25 23:22:17 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Tue, 26 Jul 2011 15:22:17 +0900
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
 and other feedback
In-Reply-To: <Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
References: <4E242D26.3030401@alvestrand.no>	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>	<CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
	<Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
Message-ID: <4E2E5D19.9040704@hicorp.co.jp>

There is a lot more that could be done than simply triggering the flash.
See /The Frankencamera: An Experimental Platform for Computational
Photography/ <http://graphics.stanford.edu/papers/fcam/> and The FCAM
API <http://fcam.garage.maemo.org/>.

Regards

    -Mark

On 26/07/2011 14:30, Ian Hickson wrote:
> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
>>> > > > 
>>> > > > Another question is flash. As far as I have seen, there seems to be 
>>> > > > no option to specify whether the camera needs to use flash or not. 
>>> > > > Is this decision left up to the device? (If someone is making an app 
>>> > > > which is just clicking a picture of the person, then it would be 
>>> > > > nice to have the camera use flash in low light conditions).
>> > >
>> > > getUserMedia() returns a video stream, so it wouldn't use a flash.
> > 
> > Wouldn't it make sense to have a provision for flash separately then? I 
> > think a lot of apps would like just a picture instead of video, and in 
> > those cases, flash would be required. Maybe a seperate provision in the 
> > spec which defines whether to use flash, and if so, for how many 
> > miliseconds. Is that doable?

From jkorpela at cs.tut.fi  Mon Jul 25 23:22:17 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Tue, 26 Jul 2011 09:22:17 +0300
Subject: [whatwg] Physical quantities: <var> or <i>?
In-Reply-To: <Pine.LNX.4.64.1107222252350.2079@ps20323.dreamhostps.com>
References: <1DDAC71F28644CD99F84542A4EFAFBEB@JukanPC>
	<BANLkTimQLe75LnjQC2HgyaKrRKu=7fFD=w@mail.gmail.com>
	<172D93ED6EC74255ADA2D5262080E98A@JukanPC>
	<Pine.LNX.4.64.1107222252350.2079@ps20323.dreamhostps.com>
Message-ID: <4E2E5D19.3040701@cs.tut.fi>

25.07.2011 22:02, Ian Hickson wrote:

>> So what markup should we use for E = mc?, given that by the applicable
>> standards, E, M, and c should appear in italics and the other characters as
>> normal (upright)?
>
> It sounds like you want to use these characters:
>
>     U+1D438 MATHEMATICAL ITALIC CAPITAL E
>     U+1D45A MATHEMATICAL ITALIC SMALL M
>     U+1D450 MATHEMATICAL ITALIC SMALL C

No, I don?t want to use them, since only about one person in a million 
would see the expression. There are several reasons to that, including 
the absence of those characters in fonts?the only commonly available 
font that contained a reasonable collection of Plane 1 characters was 
code2001, and it does not seem to be distributed by its author any more.

Characters not supported by any of the fonts installed in the user?s 
system don?t degrade well. The user sees a small box or the ??? 
character (which may appear due to other problems, too).

Comparing this with how well <i>E</i> = <i>m</i><i>c</i>? works, I don?t 
think anyone who understands the implications will give a second though 
to using such Plane 1 characters in HTML documents.

> Alternatively, you can use MathML to mark up the equation.

Or I could use LaTeX and get a presentation of acceptable quality. Or an 
image, as people still widely use. The question was about markup of 
physical quantities in HTML. Using other tools just to present a casual 
equation in running text would be disproportionate.

> Whether you want something in italics or not is more a matter for CSS than
> a matter for HTML.

In many contexts, by long traditions and conventions, the use of italics 
is a matter of content, not casual presentation. When people know they 
cannot use italics, they are forced to simulating it (e.g., writing /a/ 
to denote italic ?a?) or to avoiding the issue with clumsy methods like 
long prose explanations. Wouldn?t it be odd to pretend that in HTML, you 
are forced to something like that? After all, <i> has been with us since 
the dawn of HTML, and all browsers support it when they can use italics 
at all (and may use some special representation when not).

>> Should we consider the var element as covering physical quantities too?
>> After all, they can be regarded as variables in a broad sense, as
>> symbols that denote different values in different situations. However,
>> <var>c</var>  would be odd, wouldn't it, since the symbol denotes a
>> universal constant of nature.
>
> You can look at it as being a variable whose value is a constant of
> nature. I've clarified the spec to indicate that this is fine.

I don?t think you have clarified whether <var> is suitable for physical 
quantities, but I guess you meant to imply it?even though there is not a 
single example about markup for physical quantities.

On the other hand, it seems that it doesn?t really matter. The <var> 
element has now been defined to have such a wide and vague meaning that 
it is pointless to use it. There is little reason to expect that any 
software will ever pay attention to <var> markup on any semantic basis.

So authors will use <i> if they think italics is semantically essential, 
and <var> won?t be used much.

>> A programming
>> language variable is something that is _not_ conventionally rendered in
>> italics. Rather, they are usually (though for no really good reason)
>> rendered in a monospace font, like any other expressions in computer
>> languages.
>
> Indeed. And vectors are usually bold.

So why should authors be told to use markup that by default (and always 
when CSS is off) results in programming language constructs to be 
italicized? Flagging ?placeholders? with italics (as in ?issue the 
command <kbd>rm <i>filename</i></kbd> to delete a file) is a widely used 
and understood style, but programming language variables are a 
completely different issue.

>> Too bad there's no example of<var>  used in programming context. The
>> current wording suggests that it would be normal, when discussing
>> programming, to write, say, "Then we define the variable
>> <var>myFoo</var>  of type<code>fooType</code>  with initial value
>> <code>"Foo"</code>  - -", which really makes no sense, even if we use
>> both<var>  and<code>  for myFoo.
>
> Why does it make no sense?

Because it implies that in default rendering, identifiers of variables 
appear in italics whereas identifiers of types or classes do not. Why 
would anyone use extra <var> markup when it has no other implications 
than requiring extra CSS code to remove (when possible) italics?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From christoph.paeper at crissov.de  Tue Jul 26 04:04:07 2011
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 26 Jul 2011 13:04:07 +0200
Subject: [whatwg] [Selectors4] case-insensitive attribute value matching
	(in XML)
In-Reply-To: <op.vy6zxuiz64w2qv@annevk-macbookpro.local>
References: <op.vy48y1mf64w2qv@annevk-macbookpro.local>
	<4E2DA1D3.4020309@inkedblade.net>
	<20110725181711.GA22625@pickering.dbaron.org>
	<4E2DB9B0.60604@inkedblade.net>
	<6F190DD9-8EE6-450B-9FFE-ECD76945F80C@hp.com>
	<op.vy6zxuiz64w2qv@annevk-macbookpro.local>
Message-ID: <554C7A95-C4D6-4DAF-A62F-E5CB7A515C42@crissov.de>

Anne van Kesteren:
> I'm still trying to get HTML and browsers to change so that attribute values always match case-sensitively, irrespective of markup language. The current magic attribute list in HTML whose values needs to be matched ASCII case-insensitively is just ugly.

Can?t that be changed to something like the following?

  When an attribute takes as a value
  ? a single keyword or
  ? a whitespace-separated list of keywords,
  where all valid keywords are defined in this spexcification,
  these keywords are ASCII case-insensitive.
  All other attribute values are case-sensitive.

or just

  All element names, attribute names and attribute value keywords
  defined in this specification are ASCII case-insensitive.
  All other attribute values are case-sensitive.

From aykut.sensoy at bild.de  Tue Jul 26 04:27:35 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Tue, 26 Jul 2011 11:27:35 +0000
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <4E243F2C.2040605@gmx.de>
Message-ID: <CA547099.10D90%aykut.sensoy@bild.de>

http://www.google.com/support/news_pub/bin/answer.py?answer=93994

See Link above, Google says, that they provide "DC.date.issued", but this
is also not part auf the whatwg metaextensions list.
 


kind regards

Aykut



Am 18.07.11 16:11 schrieb "Julian Reschke" unter <julian.reschke at gmx.de>:

>On 2011-07-18 15:59, aykut.sensoy at bild.de wrote:
>> hi julian,
>> i have asked one from the seo team and he says for example the
>>"freshness
>> factor" is important for google.
>> is it possible to use the time-tag in the head instead (i mean
>>invisible)?
>> dc:created is also not in the Meta Extensions List, see:
>> http://wiki.whatwg.org/wiki/MetaExtensions
>
>I *believe* the SEO time is misguided when it thinks that
>meta/@name="date" affects Google. But only Google can tell us.
>
>I mentioned dc:created not because it's valid, but because it's at least
>*specified* and in more wider use.
>
>Best regards, Julian
>


From tommyw at google.com  Tue Jul 26 06:03:26 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Tue, 26 Jul 2011 15:03:26 +0200
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
References: <4E242D26.3030401@alvestrand.no>
	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
	<CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
	<Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
Message-ID: <CALLKCfOeJLRL1ynw33NSC0bzvfWgQ1HYiZ3oTJJa5OSAN=44iQ@mail.gmail.com>

On Tue, Jul 26, 2011 at 07:30, Ian Hickson <ian at hixie.ch> wrote:
>
>
> > If you send two MediaStream objects constructed from the same
> > LocalMediaStream over a PeerConnection there needs to be a way to
> > separate them on the receiving side.
>
> What's the use case for sending the same feed twice?
>

There's no proper use case as such but the spec allows this.


>
>
> > I also think it is a bit unfortunate that we now have a 'label' property
> > on the track objects that means something else than the 'label' property
> > on MediaStream, perhaps 'description' would be a more suitable name for
> > the former.
>
> In what sense do they mean different things? I don't understand the
> problem here. Can you elaborate?
>

label on a MediaStream is a unique identifier, while the label on a
MediaStreamTrack is just a description like "Logitech Vision Pro", "Line In"
or "Built-in Mic". I too find this a bit odd.


>
>
> On Wed, 20 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> > On Mon, Jul 18, 2011 at 20:38, Ian Hickson <ian at hixie.ch> wrote:
> > > On Mon, 18 Jul 2011, Tommy Widenflycht (??~[~O??~Z????~[~X??~[~X??~Z??)
> wrote:
> > > >
> > > > I am very confused regarding the below paragraph from the latest
> > > > spec:
> > > >
> > > > When a track in a MediaStream parent is disabled, any
> > > > MediaStreamTrack objects corresponding to the tracks in any
> > > > MediaStream objects that were created from parent are disassociated
> > > > from any track, and must not be reused for tracks again. If a
> > > > disabled track in a MediaStream parent is re-enabled, from the
> > > > perspective of any MediaStream objects that were created from parent
> > > > it is a new track and thus new MediaStreamTrack objects must be
> > > > created for the tracks that correspond to the re-enabled track.
> > > >
> > > > After cloning a LocalMediaStream it looks like this:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(E)           Track1(E)
> > > > Track2(E)           Track2(E)
> > > > Track3(E)           Track3(E)
> > > >
> > > > and as I interpret the spec it looks like this if Track1 in the
> > > > LocalMediaStream is disabled:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(D)           Track2(E)
> > > > Track2(E)           Track3(E)
> > > > Track3(E)
> > >
> > > Correct so far (though I'd avoid the term "cloning" since it's not
> > > quite what's going on here -- the spec uses "forking", which may be
> > > closer though is still not ideal).
> > >
> > > > So Track1 disappears from the MediaStream1 object and doesn't come
> > > > back even if Track1 in the LMS object is enabled:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(E)           Track2(E)
> > > > Track2(E)           Track3(E)
> > > > Track3(E)
> > >
> > > No, it'll create a new track object:
> > >
> > >  LocalMediaStream -> MediaStream1
> > >  Track1(E)           Track4(E)
> > >  Track2(E)           Track2(E)
> > >  Track3(E)           Track3(E)
> > >
> > > This is specified in the sentence that starts "If a disabled track in
> > > a MediaStream parent is re-enabled...".
> >
> > Thanks for the explanation. To me this sounds overly complicated, why
> > not just make it so that an disable of a track will override the track
> > settings for forked MediaStreams?
>
> I don't understand what you mean. How would that be different?
>
>
If I may make an analogy to the real world: plumbing.

Each fork of a MediaStream is a new joint in the pipe, my suggestion
introduces a tap at each joint. No matter how you open and close the tap at
the end (or middle); if any previous tap is closed there's nothing coming
through.
The spec currently removes and add the entire pipe after the changed joint.


>
> > Also some follow-up questions regarding the new TrackLists:
> >
> > What should happen when a track fails? Should the entire stream fail,
> > the MSTrack silently be removed or the MSTrack disassociated with the
> > track (and thus becoming a do-nothing object)?
>
> What do you mean by "fails"?
>

Yanking the USB cable to the camera for example. This should imho stop the
MS, not just silently send black video.


> > What should happen when a stream with two or more video tracks is
> > associated to a <video> tag? Just render the first enabled one?
>
> Same as if you had a regular video file with multiple tracks.
>
>
And that is? Sorry, this might be written down somewhere and I have missed
it.


/Tommy

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.

From ddahl at mozilla.com  Tue Jul 26 12:59:20 2011
From: ddahl at mozilla.com (David Dahl)
Date: Tue, 26 Jul 2011 12:59:20 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <1192225079.577736.1311175542151.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <815375749.651048.1311710360055.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

Hello All:

Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.

Summary:

    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
    HASH and HMAC methods may be implemented first
    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
        Keypairs must be generated on a per-origin basis
        The Keypair for a specific origin cannot be used in another origin 
    No private or wrapped key material will be accessible to content scripts
    Each implementation will provide a mechanism to clear keys
    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
    The returned encrypted object format will be a raw ArrayBuffer
    The public key format will be a raw ArrayBuffer
        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
    HASH and HMAC methods should be synchronous to make them simpler
        HASH and HMAC methods should be constructors 
    We may implement the HASH and HMAC APIs first then the PublicKey API

A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14

The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest 

Any comments and discussion will be most welcome.

Regards,

David Dahl

From scott at crisscott.com  Tue Jul 26 14:11:36 2011
From: scott at crisscott.com (=?utf-8?B?c2NvdHRAY3Jpc3Njb3R0LmNvbQ==?=)
Date: Tue, 26 Jul 2011 17:11:36 -0400
Subject: [whatwg]
	=?utf-8?q?PeerConnection=2C_MediaStream=2C_getUserMedia?=
	=?utf-8?q?=28=29=2C=09and_other_feedback?=
Message-ID: <0MTBQE-1Qt09R0kNS-00SFJA@mrelay.perfora.net>



----- Reply message -----
From: "Ian Hickson" <ian at hixie.ch>
Date: Tue, Jul 26, 2011 1:30 am
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),	and other feedback
To: "whatwg at whatwg.org" <whatwg at whatwg.org>


From Simetrical+w3c at gmail.com  Tue Jul 26 14:26:32 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Tue, 26 Jul 2011 17:26:32 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
Message-ID: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>

Since February, I've been working on writing a detailed specification
for browser editing, primarily the document.execCommand() and
document.queryCommand*() methods.  These were created by Microsoft in
the 1990s and were subsequently adopted in some form by all other
browsers, and today browsers have to implement them to be compatible
with web content, but no detailed specification ever existed.
Interoperability is practically nonexistent as a result, which has
driven all major content editing frameworks away from using
execCommand().  Hopefully we can start to fix that and make these APIs
a part of the web platform that just works.

The current version of the specification is at
<http://aryeh.name/spec/editing/editing.html>.  It's about fifty pages
printed, and supersedes the Editing APIs section of HTML
<http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis>
(which is more like two pages).  In the style of modern web specs, it
is phrased in terms of algorithms that attempt to cover all corner
cases unambiguously and leave no behavior undefined, and it tries to
match the behavior of existing browsers to the greatest extent
possible.  At this point, it's stable and complete enough that I
believe it's ready for serious review by implementers, and I would
like as much detailed feedback as possible.

There is a basically complete JavaScript implementation, which is used
to produce expected results for a largely undocumented and entirely ad
hoc test suite:
<http://aryeh.name/spec/editing/autoimplementation.html>.  I used the
tests as an aid to writing the spec, and they probably aren't well
suited to aid implementers in implementing it.  I will probably get
around to porting them to something like testharness.js at some point.
 I haven't tried testing my implementation on real-world sites, only
on artificial input, so I don't know at this point how implementable
it really is, but the JS implementation means that it at least has
large parts that make sense.

Anyone reviewing the spec should be advised that I put extensive
rationale in HTML comments.  If you want to know why the spec says
what it does, check the HTML source.  I plan to change this to use
<details> or such in the near future.  There are lots of minor known
issues still left, but none that I thought was important enough that
it needs to delay review.  Feedback can be sent to the whatwg list,
CCing me, with [editing] in the subject.  (I'm also fine receiving
feedback on public-html or public-webapps, but I don't know if the
chairs would be okay with that, since it's off-topic.)  I should be
available to respond to all feedback promptly at least through the end
of August.  After that, I can't make specific guarantees about my
availability, but I do plan to continue maintaining the spec in the
long term.

I've CCd or BCCd everyone who's commented on or contributed to this
spec at some point.

From ian at hixie.ch  Tue Jul 26 14:44:44 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Jul 2011 21:44:44 +0000 (UTC)
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
Message-ID: <Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>


On Fri, 29 Apr 2011, Simon Heckmann wrote:
> 
> I have read a lot in the last month about the future of html and web 
> applications and I am very impressed by the progress this makes. 
> However, I have come across some thing that annoys me: Permissions. I 
> know they are important and I know they are needed but currently I find 
> this quite inconvenient. And with more and more permissions coming up 
> this might get worse so I spent some time thinking about it.
> 
> I have written a short document covering my proposal: 
> www.simonheckmann.de/download/Proposal.pdf (3 pages, ~200KB)
> 
> It should just take only a few minutes to read and includes examples and 
> screenshots. I am really looking forward to hearing your thoughts on 
> this. Please feel free to share this idea with whomever you want to. If 
> you think I should post this proposal somewhere else please say so.

Robert O'Callahan posted a good response:

http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html

In short, the better solution isn't to ask for permissions up-front, but 
to ask for fewer permissions. The ideal solution is to not ask for any 
permission but to base the permission on a natural user gesture. For 
example, drag-and-drop of files to a site doesn't require permissions, but 
it is an implicit permission grant. Same with <input type=file>. With 
getUserMedia() we are doing something similar: instead of asking for 
permission, the user is asked for a specific input to be selected.

Permission grants are a bug.


On Sat, 30 Apr 2011, Glenn Maynard wrote:
> 
> I'd wonder what their response is to Android; the problems on that 
> platform are obvious.  The result is exactly as you say: people end up 
> giving up and just accepting everything.
> 
> (The permissions request for Skype includes: "read contact data, write 
> contact data, coarse (network-based) location, full Internet access, act 
> as an account authenticator, manage the accounts list, user the 
> authentication credentials of an account, modify/delete USB storage 
> contents, change your audio settings, record audio, read phone state and 
> identity, disable keylock, modify global system settings, prevent phone 
> from sleeping, retrieve running applications, write sync settings, view 
> network state, view Wi-Fi state, control vibrator, read sync settings, 
> read sync statistics, discover known accounts".  It's hopeless; if "take 
> out a mortgage on your house" was in there, nobody would notice.)
> 
> Of course, asking each of these while using the application would also 
> be painfully annoying, and it's not obvious how to make permissions 
> meaningful to the user (eg. when you use its feature) while also scaling 
> to lots of permissions.

Indeed. The system shouldn't ask for any permissions. For example instead 
of reading contact data, it could cause the OS to pop up a contacts list 
from which you can pick a contact to give access to it to the app.


On Sun, 1 May 2011, Robert O'Callahan wrote:
> 
> Notifications are a particularly hard case for the principle of 
> requesting permissions in response to user action, because the whole 
> point of notifications is that they happen when the user isn't giving 
> the application attention :-).

My proposal for notifications was to have them default to being just 
inside the page (nothing that a <div> couldn't do), but that they would 
include explicit UI to promote them to full-system notifications; and 
vice-versa, so a system notification could be demoted back to just in-page 
notification with a similar gesture.


On Tue, 3 May 2011, Cameron Heavon-Jones wrote:
> 
> The quantity of permission requests can be managed in an effective 
> manner by the agent allowing the user to store their preferences for the 
> next command or as a universal setting.

That doesn't work. It might be appropriate for Bing Maps to have access to 
my Geolocation information, but I certainly don't want some random blog to 
have access to it. Defaults don't work here.


> For web applications to specify their required permissions would seem to 
> introduce a duplication of specification. If a web application includes 
> an image file upload which the user chooses to capture from webcam, 
> first how is the application to know that the user would use a web cam?

There's no need for the app to know. It can just allow the user to upload 
a photo, and the browser can offer to use the webcam.



I haven't added anythign to the spec in relation to this proposal.

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

From silviapfeiffer1 at gmail.com  Tue Jul 26 14:58:30 2011
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 27 Jul 2011 07:58:30 +1000
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <815375749.651048.1311710360055.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
References: <1192225079.577736.1311175542151.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<815375749.651048.1311710360055.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>

If I understand this correctly, then this is introducing a mechanism
for Web publishers to provide a secure service to users where the data
exchanged between the server and the UA is encrypted and not decodable
by anyone else listening in on that communication or getting access to
the data stored in the browser for that communication.

If so, could this be a means to provide a one-session-only decoding
key to a UA to decode a specially encoded piece of content (e.g. a
video) from a publisher? I am quite directly thinking that this could
be a first step towards providing DRM methodology in the browser, but
also for example for about having secure private video conversations
without needing to install browser plugins.

Apologies for taking this thread a bit off topic - I am just curious.

Cheers,
Silvia.


On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
> Hello All:
>
> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>
> Summary:
>
> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
> ? ?HASH and HMAC methods may be implemented first
> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
> ? ? ? ?Keypairs must be generated on a per-origin basis
> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
> ? ?No private or wrapped key material will be accessible to content scripts
> ? ?Each implementation will provide a mechanism to clear keys
> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
> ? ?The returned encrypted object format will be a raw ArrayBuffer
> ? ?The public key format will be a raw ArrayBuffer
> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
> ? ?HASH and HMAC methods should be synchronous to make them simpler
> ? ? ? ?HASH and HMAC methods should be constructors
> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>
> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>
> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> Any comments and discussion will be most welcome.
>
> Regards,
>
> David Dahl
>

From ian at hixie.ch  Tue Jul 26 15:22:46 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Jul 2011 22:22:46 +0000 (UTC)
Subject: [whatwg] Styling of datagrid content
In-Reply-To: <45F5DC15.8060306@westnet.com.au>
References: <45F5DC15.8060306@westnet.com.au>
Message-ID: <Pine.LNX.4.64.1107262221310.2079@ps20323.dreamhostps.com>

On Tue, 13 Mar 2007, Sean Hogan wrote:
>
> How do you define style for datagrids?
> e.g.
> - row color
> - alternating row color
> - selected row color
> - initial column widths
> - fixed column widths

For the time being, I have abandoned the idea of specifying a <datagrid> 
element. My plan is to wait to see if recent developments around XBL go 
anywhere, and if they do, see if <datagrid> can just be implemented using 
a widget binding by authors rather than having a native widget.

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

From ddahl at mozilla.com  Tue Jul 26 15:26:10 2011
From: ddahl at mozilla.com (David Dahl)
Date: Tue, 26 Jul 2011 15:26:10 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
Message-ID: <1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

Silvia:

The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.

I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.

Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).

The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases

Cheers,

David

----- Original Message -----
From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
To: "David Dahl" <ddahl at mozilla.com>
Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
Sent: Tuesday, July 26, 2011 4:58:30 PM
Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report

If I understand this correctly, then this is introducing a mechanism
for Web publishers to provide a secure service to users where the data
exchanged between the server and the UA is encrypted and not decodable
by anyone else listening in on that communication or getting access to
the data stored in the browser for that communication.

If so, could this be a means to provide a one-session-only decoding
key to a UA to decode a specially encoded piece of content (e.g. a
video) from a publisher? I am quite directly thinking that this could
be a first step towards providing DRM methodology in the browser, but
also for example for about having secure private video conversations
without needing to install browser plugins.

Apologies for taking this thread a bit off topic - I am just curious.

Cheers,
Silvia.


On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
> Hello All:
>
> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>
> Summary:
>
> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
> ? ?HASH and HMAC methods may be implemented first
> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
> ? ? ? ?Keypairs must be generated on a per-origin basis
> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
> ? ?No private or wrapped key material will be accessible to content scripts
> ? ?Each implementation will provide a mechanism to clear keys
> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
> ? ?The returned encrypted object format will be a raw ArrayBuffer
> ? ?The public key format will be a raw ArrayBuffer
> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
> ? ?HASH and HMAC methods should be synchronous to make them simpler
> ? ? ? ?HASH and HMAC methods should be constructors
> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>
> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>
> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> Any comments and discussion will be most welcome.
>
> Regards,
>
> David Dahl
>

From silviapfeiffer1 at gmail.com  Tue Jul 26 15:41:47 2011
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 27 Jul 2011 08:41:47 +1000
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>

OK, so it would apply to a private video conference, but not to
protect a server-client-delivery. That's good to know, thanks.
Silvia.

On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
> Silvia:
>
> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>
> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>
> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>
> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>
> Cheers,
>
> David
>
> ----- Original Message -----
> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
> To: "David Dahl" <ddahl at mozilla.com>
> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
> Sent: Tuesday, July 26, 2011 4:58:30 PM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>
> If I understand this correctly, then this is introducing a mechanism
> for Web publishers to provide a secure service to users where the data
> exchanged between the server and the UA is encrypted and not decodable
> by anyone else listening in on that communication or getting access to
> the data stored in the browser for that communication.
>
> If so, could this be a means to provide a one-session-only decoding
> key to a UA to decode a specially encoded piece of content (e.g. a
> video) from a publisher? I am quite directly thinking that this could
> be a first step towards providing DRM methodology in the browser, but
> also for example for about having secure private video conversations
> without needing to install browser plugins.
>
> Apologies for taking this thread a bit off topic - I am just curious.
>
> Cheers,
> Silvia.
>
>
> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>> Hello All:
>>
>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>
>> Summary:
>>
>> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>> ? ?HASH and HMAC methods may be implemented first
>> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>> ? ? ? ?Keypairs must be generated on a per-origin basis
>> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
>> ? ?No private or wrapped key material will be accessible to content scripts
>> ? ?Each implementation will provide a mechanism to clear keys
>> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>> ? ?The returned encrypted object format will be a raw ArrayBuffer
>> ? ?The public key format will be a raw ArrayBuffer
>> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>> ? ?HASH and HMAC methods should be synchronous to make them simpler
>> ? ? ? ?HASH and HMAC methods should be constructors
>> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>>
>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>
>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>
>> Any comments and discussion will be most welcome.
>>
>> Regards,
>>
>> David Dahl
>>
>

From simon at simonheckmann.de  Tue Jul 26 15:55:30 2011
From: simon at simonheckmann.de (Simon Heckmann)
Date: Wed, 27 Jul 2011 00:55:30 +0200
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
Message-ID: <69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>

Okay, I am a little confused now: What about the following use case:

On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.

On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.

As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?

Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?

Thank you very much!

Kind regards,
Simon Heckmann


Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:

> OK, so it would apply to a private video conference, but not to
> protect a server-client-delivery. That's good to know, thanks.
> Silvia.
> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>> Silvia:
>> 
>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>> 
>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>> 
>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>> 
>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>> 
>> Cheers,
>> 
>> David
>> 
>> ----- Original Message -----
>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>> To: "David Dahl" <ddahl at mozilla.com>
>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>> 
>> If I understand this correctly, then this is introducing a mechanism
>> for Web publishers to provide a secure service to users where the data
>> exchanged between the server and the UA is encrypted and not decodable
>> by anyone else listening in on that communication or getting access to
>> the data stored in the browser for that communication.
>> 
>> If so, could this be a means to provide a one-session-only decoding
>> key to a UA to decode a specially encoded piece of content (e.g. a
>> video) from a publisher? I am quite directly thinking that this could
>> be a first step towards providing DRM methodology in the browser, but
>> also for example for about having secure private video conversations
>> without needing to install browser plugins.
>> 
>> Apologies for taking this thread a bit off topic - I am just curious.
>> 
>> Cheers,
>> Silvia.
>> 
>> 
>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>> Hello All:
>>> 
>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>> 
>>> Summary:
>>> 
>>>    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>    HASH and HMAC methods may be implemented first
>>>    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>        Keypairs must be generated on a per-origin basis
>>>        The Keypair for a specific origin cannot be used in another origin
>>>    No private or wrapped key material will be accessible to content scripts
>>>    Each implementation will provide a mechanism to clear keys
>>>    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>    The returned encrypted object format will be a raw ArrayBuffer
>>>    The public key format will be a raw ArrayBuffer
>>>        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>    HASH and HMAC methods should be synchronous to make them simpler
>>>        HASH and HMAC methods should be constructors
>>>    We may implement the HASH and HMAC APIs first then the PublicKey API
>>> 
>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>> 
>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>> 
>>> Any comments and discussion will be most welcome.
>>> 
>>> Regards,
>>> 
>>> David Dahl
>>> 
>> 

From roBman at mob-labs.com  Tue Jul 26 17:56:11 2011
From: roBman at mob-labs.com (Rob Manson)
Date: Wed, 27 Jul 2011 10:56:11 +1000
Subject: [whatwg] Access to live/raw audio and video stream data from both
 local and remote sources
Message-ID: <1311728171.2937.90113.camel@robslapu>

Hi,

sorry for posting across multiple groups, but I hope you'll see from my
comments below that this is really needed. 

This is definitely not intended as criticism of any of the work going
on.  It's intended as constructive feedback that hopefully provides
clarification on a key use case and it's supporting requirements.

        "Access to live/raw audio and video stream data from both local
        and remote sources in a consistent way"

I've spent quite a bit of time trying to follow a clear thread of
requirements/solutions that provide API access to raw stream data (e.g.
audio, video, etc.).  But I'm a bit concerned this is falling in the gap
between the DAP and RTC WGs.  If this is not the case then please point
me to the relevant docs and I'll happily get back in my box 8)

Here's how the thread seems to flow at the moment based on public
documents.

On the DAP page [1] the mission states:
        "the Device APIs and Policy Working Group is to create
        client-side APIs that enable the development of Web Applications
        and Web Widgets that interact with devices services such as
        Calendar, Contacts, Camera, etc"

So it seems clear that this is the place to start.  Further down that
page the "HTML Media Capture" and "Media Capture" APIs are listed.

HTML Media Capture (camera/microphone interactions through HTML forms)
initially seems like a good candidate, however the intro in the latest
PWD [2] clearly states:
        "Providing streaming access to these capabilities is outside of
        the scope of this specification."

Followed by a NOTE that states:
        "The Working Group is investigating the opportunity to specify
        streaming access via the proposed <device> element."
        
The link on the "proposed <device> element" [3] links to a "no longer
maintained" document that then redirects to the top level of the whatwg
"current work" page [4].  On that page the most relevant link is the
video conferencing and peer-to-peer communication section [5].  More
about that further below.

So back to the DAP page to follow explore the other Media Capture API
(programmatic access to camera/microphone) [1] and it's latest PWD [6].
The abstract states:
        "This specification defines an Application Programming Interface
        (API) that provides access to the audio, image and video capture
        capabilities of the device."

And the introduction states:
        "The Capture API defines a high-level interface for accessing
        the microphone and camera of a hosting device. It completes the
        HTML Form Based Media Capturing specification [HTMLMEDIACAPTURE]
        with a programmatic access to start a parametrized capture
        process."
        
So it seems clear that this is not related to streams in any way either.

The Notes column for this API on the DAP page [1] also states:
        "Programmatic API that completes the form based approach
        Need to check if still interest in this
        How does it relate with the Web RTC Working Group?"

Is there an updated position on this?

So if you then head over to the WebRTC WG's charter [7] it states:
        "...to define client-side APIs to enable Real-Time
        Communications in Web browsers.
        
        These APIs should enable building applications that can be run
        inside a browser, requiring no extra downloads or plugins, that
        allow communication between parties using audio, video and
        supplementary real-time communication, without having to use
        intervening servers..."
        
So this is clearly focused upon peer-to-peer communication "between"
systems and the stream related access is naturally just treated as an
ancillary requirement.  The scope section then states:
        "Enabling real-time communications between Web browsers require
        the following client-side technologies to be available:
        
        - API functions to explore device capabilities, e.g. camera,
        microphone, speakers (currently in scope for the Device APIs &
        Policy Working Group)
        - API functions to capture media from local devices (camera and
        microphone) (currently in scope for the Device APIs & Policy
        Working Group)
        - API functions for encoding and other processing of those media
        streams,
        - API functions for establishing direct peer-to-peer
        connections, including firewall/NAT traversal
        - API functions for decoding and processing (including echo
        cancelling, stream synchronization and a number of other
        functions) of those streams at the incoming end,
        - Delivery to the user of those media streams via local screens
        and audio output devices (partially covered with HTML5)"
        
So this is where I really start to feel the gap growing.  The DAP is
pointing to RTC saying not sure how if our Camera/Microphone APIs are
being superseded by the work in the RTC...and the RTC then points back
to say it will be relying on work in the DAP.  However the RTCs
Recommended Track Deliverables list does include:
        "Media Stream Functions, Audio Stream Functions and Video Stream
        Functions"

So then it's back to the whatwg MediaStream and LocalMediaStream current
work [8].  Following this through you end up back at the <audio> and
<video> media element with some brief discussion about media data [9].

Currently the only API that I'm aware of that allows live access to the
audio data through the <audio> tag is the relatively proprietary Mozilla
Audio Data API [10].

And while the video stream data can be accessed by rendering each frame
into a canvas 2d graphics context and then using getImageData to extract
and manipulate it from there [11], this seems more like a work around
than an elegantly designed solution.
 
As I said above, this is not intended as a criticism of the work that
the DAP WG, WebRTC WG or WHATWG are doing.  It's intended as
constructive feedback to highlight that the important use case of
"Access to live/raw audio and video stream data from both local and
remote sources" appears to be falling in the gaps between the groups. 

>From my perspective this is a critical use case for many advanced web
apps that will help bring them in line with what's possible in the
native single vendor stack based apps at the moment (e.g. iPhone &
Android).  And it's also critical for the advancement of web standards
based AR applications and other computer vision, hearing and signal
processing applications.

I understand that a lot of these specifications I've covered are in very
formative stages and that requirements and PWDs are just being drafted
as I write.  And that's exactly why I'm raising this as a single and
consolidated perspective that spans all these groups.  I hope this goes
some way towards "Access to live/raw audio and video stream data from
both local and remote sources" being treated as an essential and core
use case that binds together the work of all these groups.  With a clear
vision for this and a little consolidated work I think this will then
also open up a wide range of other app opportunities that we haven't
even thought of yet.  But at the moment it really feels like this is
being treated as an assumed requirement and could end up as a poorly
formed second class bundle of semi-related API hooks.

For this use case I'd really like these clear requirements to be
supported:
- access the raw stream data for both audio and video in similar ways
- access the raw stream data from both remote and local streams in
similar ways
- ability to inject new data or the transformed original data back into
streams and presented audio/video tags in a consistent way
- all of this be optimised for performance to meet the demands of live
signal processing

roBman

PS: I've also cc'd in the mozilla dev list as I think this directly
relates to the current "booting to the web" thread [12]


[1] http://www.w3.org/2009/dap/
[2] http://www.w3.org/TR/2011/WD-html-media-capture-20110414/#introduction
[3] http://dev.w3.org/html5/html-device/ 
[4] http://www.whatwg.org/specs/web-apps/current-work/complete/#devices 
[5] http://www.whatwg.org/specs/web-apps/current-work/complete/#auto-toc-9
[6] http://www.w3.org/TR/2010/WD-media-capture-api-20100928/
[7] http://www.w3.org/2011/04/webrtc-charter.html
[8] http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html#mediastream 
[9] http://www.whatwg.org/specs/web-apps/current-work/complete/the-iframe-element.html#media-data
[10] https://wiki.mozilla.org/Audio_Data_API
[11] https://developer.mozilla.org/En/Manipulating_video_using_canvas
[12] http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/7668a9d46a43e482# 


From w3c at adambarth.com  Tue Jul 26 19:14:40 2011
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 26 Jul 2011 19:14:40 -0700
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
Message-ID: <CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>

Hi Simon,

That would look something like the following:

== Phase 1: Key Generation (Client-Side) ==

crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
  ... send pubKey to the server ...
  ... store keyID somewhere??? ...
});

== Phase 2: Encryption (Server-Side) ==

The server encrypts file F under public key pubKey.
The server sends the encrypted file EF to the client and stores it
locally using the File API.

== Phase 3: Decryption (Client-Side) ==

... retrieve keyID from somewhere??? ...

crypto.pk.decrypt(EF, keyID, function(plainText) {
  ... rejoice ...
});

To fill in the ??? we need to store the keyID somewhere.  (To be
clear, the keyID is just a capability to use the private key, which
never leaves the user agent's secure key store.)  To complete your
example, we'd need to provide a facility to protect the keyID with the
user's password.

Adam


On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
> Okay, I am a little confused now: What about the following use case:
>
> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>
> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>
> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>
> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>
> Thank you very much!
>
> Kind regards,
> Simon Heckmann
>
>
> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>
>> OK, so it would apply to a private video conference, but not to
>> protect a server-client-delivery. That's good to know, thanks.
>> Silvia.
>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>> Silvia:
>>>
>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>
>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>
>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>
>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> ----- Original Message -----
>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>> To: "David Dahl" <ddahl at mozilla.com>
>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>
>>> If I understand this correctly, then this is introducing a mechanism
>>> for Web publishers to provide a secure service to users where the data
>>> exchanged between the server and the UA is encrypted and not decodable
>>> by anyone else listening in on that communication or getting access to
>>> the data stored in the browser for that communication.
>>>
>>> If so, could this be a means to provide a one-session-only decoding
>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>> video) from a publisher? I am quite directly thinking that this could
>>> be a first step towards providing DRM methodology in the browser, but
>>> also for example for about having secure private video conversations
>>> without needing to install browser plugins.
>>>
>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>
>>> Cheers,
>>> Silvia.
>>>
>>>
>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>> Hello All:
>>>>
>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>
>>>> Summary:
>>>>
>>>> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>> ? ?HASH and HMAC methods may be implemented first
>>>> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>> ? ? ? ?Keypairs must be generated on a per-origin basis
>>>> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
>>>> ? ?No private or wrapped key material will be accessible to content scripts
>>>> ? ?Each implementation will provide a mechanism to clear keys
>>>> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>> ? ?The returned encrypted object format will be a raw ArrayBuffer
>>>> ? ?The public key format will be a raw ArrayBuffer
>>>> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>> ? ?HASH and HMAC methods should be synchronous to make them simpler
>>>> ? ? ? ?HASH and HMAC methods should be constructors
>>>> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>
>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>
>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>
>>>> Any comments and discussion will be most welcome.
>>>>
>>>> Regards,
>>>>
>>>> David Dahl
>>>>
>>>
>

From ddahl at mozilla.com  Tue Jul 26 21:42:28 2011
From: ddahl at mozilla.com (David Dahl)
Date: Tue, 26 Jul 2011 21:42:28 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
Message-ID: <1678257437.657460.1311741748246.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>


----- Original Message ----
> From: "Simon Heckmann" <simon at simonheckmann.de>
> To: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
> Cc: "David Dahl" <ddahl at mozilla.com>, "WHATWG Proposals" <whatwg at lists.whatwg.org>
> Sent: Tuesday, July 26, 2011 5:55:30 PM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report

> Additionally, are there plans or a roapmap to bring the DOMCrypt
> specification to a W3C technical report?
> 

Yes. Getting this API on a standards track is one of the project goals.

Cheers,

David

From rniwa at webkit.org  Tue Jul 26 23:34:54 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Tue, 26 Jul 2011 23:34:54 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Message-ID: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>

Hi all,

In the last couple of weeks, I've been working with developers of CKEditor,
TinyMCE, and Google Docs to come up with *new API for undo and redo*.

Why? Because* undo and redo are broken on the Web today*. Whenever Web apps
try to add a custom editing operation without using execCommand or do a "fix
up" after browser executes a user editing action, user agents get confused
by DOM mutations made by the apps and won't be able to undo or redo user
editing actions and execCommand. This forces Web apps to re-implement undo
and redo themselves, and in fact, *many rich text editors store innerHTML of
a contenteditable element* as a string in their internal undo transaction
history (a.k.a undo stack).

Also, there's no way for Web apps to add new undo item and populate undo and
redo menus on user agent's native UI.  In addition, if an editor app has a
widget with input/textarea, then the undo stack of the editor gets confused
when the widget goes away because the undo transaction history exists only
per document.

In order to solve above and numerous other problems, we've come to a
conclusion that we need to *add UndoManager and Transaction*.

*UndoManager* is an interface for managing undo transaction history.  It
exists on a document and an element with the *undoscope* content attribute.
 UndoManager applies new transaction (i.e. make undoable DOM changes) and
manage them.  The main purpose of UndoManager is to communicate the list of
undoable items with the user agent so that the user agent can provide a
native UI (e.g. populating menu items with them).

A *transaction* is a collection of DOM mutations that can be applied,
unapplied, or reapplied. UndoManager manages transactions and execute
unapply and reapply upon undo and redo respectively.

There are two types of DOM transactions:

   - *Managed transaction* - the app supplies apply() and the user agent
   automatically takes care of undo and redo. It is *compatible with user
   editing actions and editing commands*, and allows Web apps to easily add
   new editing operations or fix up DOM after user editing actions or editing
   commands and still have the user agent manage the undo and redo.
   - *Manual transaction* - the app supplies apply(), unapply(), and
   reapply() and *the app takes the full control of undo and redo*. However,
   it is NOT compatible with user editing actions, editing commands, or managed
   transactions, meaning that, the user agents won't be able to undo or redo
   them. This transaction is useful for apps such as a collaborative editor
   that implements domain-specific undo or redo.

You can see more concrete definitions of UndoManager and Transaction at:
https://rniwa.com/editing/undomanager.html and see a list of uses cases at
https://rniwa.com/editing/undomanager-usecases.html.  The documents are
incomplete and I need your feedback in order to refine details.

Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.

From simon at simonheckmann.de  Wed Jul 27 01:18:18 2011
From: simon at simonheckmann.de (Simon Heckmann)
Date: Wed, 27 Jul 2011 10:18:18 +0200
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
	<CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
Message-ID: <2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>

Thank you for your reply, but to me this seems overly complicated. Why do I need a KeyId?

What about the following proposal:

Phase one: The server knows the user's password and encrypts the file.
Phase two: The encrypted file is stored on the local hard drive using the File API.
Pase three: User enters the password, which is hashed and used for decryption:

var password = document.getElementById('passwordfield').value;
var hash = window.crypto.hash('md5', password);
var data = window.crypto.decrypt('aes-256', hash, encfiledata);

This code is just a sample, but it looks way more convenient to me. Additionally there is no need to store the keyid somewhere?!?

Kind regards,
Simon Heckmann


Am 27.07.2011 um 04:14 schrieb Adam Barth <w3c at adambarth.com>:

> Hi Simon,
> 
> That would look something like the following:
> 
> == Phase 1: Key Generation (Client-Side) ==
> 
> crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
>  ... send pubKey to the server ...
>  ... store keyID somewhere??? ...
> });
> 
> == Phase 2: Encryption (Server-Side) ==
> 
> The server encrypts file F under public key pubKey.
> The server sends the encrypted file EF to the client and stores it
> locally using the File API.
> 
> == Phase 3: Decryption (Client-Side) ==
> 
> ... retrieve keyID from somewhere??? ...
> 
> crypto.pk.decrypt(EF, keyID, function(plainText) {
>  ... rejoice ...
> });
> 
> To fill in the ??? we need to store the keyID somewhere.  (To be
> clear, the keyID is just a capability to use the private key, which
> never leaves the user agent's secure key store.)  To complete your
> example, we'd need to provide a facility to protect the keyID with the
> user's password.
> 
> Adam
> 
> 
> On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
>> Okay, I am a little confused now: What about the following use case:
>> 
>> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>> 
>> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>> 
>> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>> 
>> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>> 
>> Thank you very much!
>> 
>> Kind regards,
>> Simon Heckmann
>> 
>> 
>> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>> 
>>> OK, so it would apply to a private video conference, but not to
>>> protect a server-client-delivery. That's good to know, thanks.
>>> Silvia.
>>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>> Silvia:
>>>> 
>>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>> 
>>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>> 
>>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>> 
>>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>> 
>>>> Cheers,
>>>> 
>>>> David
>>>> 
>>>> ----- Original Message -----
>>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>>> To: "David Dahl" <ddahl at mozilla.com>
>>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>> 
>>>> If I understand this correctly, then this is introducing a mechanism
>>>> for Web publishers to provide a secure service to users where the data
>>>> exchanged between the server and the UA is encrypted and not decodable
>>>> by anyone else listening in on that communication or getting access to
>>>> the data stored in the browser for that communication.
>>>> 
>>>> If so, could this be a means to provide a one-session-only decoding
>>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>>> video) from a publisher? I am quite directly thinking that this could
>>>> be a first step towards providing DRM methodology in the browser, but
>>>> also for example for about having secure private video conversations
>>>> without needing to install browser plugins.
>>>> 
>>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>> 
>>>> Cheers,
>>>> Silvia.
>>>> 
>>>> 
>>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>> Hello All:
>>>>> 
>>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>> 
>>>>> Summary:
>>>>> 
>>>>>    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>>>    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>>>    HASH and HMAC methods may be implemented first
>>>>>    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>>>        Keypairs must be generated on a per-origin basis
>>>>>        The Keypair for a specific origin cannot be used in another origin
>>>>>    No private or wrapped key material will be accessible to content scripts
>>>>>    Each implementation will provide a mechanism to clear keys
>>>>>    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>>>    The returned encrypted object format will be a raw ArrayBuffer
>>>>>    The public key format will be a raw ArrayBuffer
>>>>>        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>>>    HASH and HMAC methods should be synchronous to make them simpler
>>>>>        HASH and HMAC methods should be constructors
>>>>>    We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>> 
>>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>> 
>>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>> 
>>>>> Any comments and discussion will be most welcome.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> David Dahl
>>>>> 
>>>> 
>> 

From w3c at adambarth.com  Wed Jul 27 01:57:04 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 27 Jul 2011 01:57:04 -0700
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
	<CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
	<2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>
Message-ID: <CAJE5ia_SC=ChnMesE1hXejkHjWZYByVC1x-9kkUJDXahMJqGRA@mail.gmail.com>

The downside of that sort of API is that you end up storing key
material in the JavaScript heap.  There's some question about whether
we should avoid doing that, which is part of the motivation to do the
public key API before the symmetric API.

Your example also raise the question of how to do key derivation and
key agreement.  Taking the MD5 hash of a password isn't really the
best key derivation function!  There's a design question of whether we
should design the API to be usable (relatively) safely by non-experts.
 Given that this is an API for the web, you can understand the desire
to make things as "idiot-proof" as possible.

I'd certainly like to see DOMCrypt be able to handle these sorts of
use cases in the future.  It's mostly a question of which use cases to
address first.

Adam


On Wed, Jul 27, 2011 at 1:18 AM, Simon Heckmann <simon at simonheckmann.de> wrote:
> Thank you for your reply, but to me this seems overly complicated. Why do I need a KeyId?
>
> What about the following proposal:
>
> Phase one: The server knows the user's password and encrypts the file.
> Phase two: The encrypted file is stored on the local hard drive using the File API.
> Pase three: User enters the password, which is hashed and used for decryption:
>
> var password = document.getElementById('passwordfield').value;
> var hash = window.crypto.hash('md5', password);
> var data = window.crypto.decrypt('aes-256', hash, encfiledata);
>
> This code is just a sample, but it looks way more convenient to me. Additionally there is no need to store the keyid somewhere?!?
>
> Kind regards,
> Simon Heckmann
>
>
> Am 27.07.2011 um 04:14 schrieb Adam Barth <w3c at adambarth.com>:
>
>> Hi Simon,
>>
>> That would look something like the following:
>>
>> == Phase 1: Key Generation (Client-Side) ==
>>
>> crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
>> ?... send pubKey to the server ...
>> ?... store keyID somewhere??? ...
>> });
>>
>> == Phase 2: Encryption (Server-Side) ==
>>
>> The server encrypts file F under public key pubKey.
>> The server sends the encrypted file EF to the client and stores it
>> locally using the File API.
>>
>> == Phase 3: Decryption (Client-Side) ==
>>
>> ... retrieve keyID from somewhere??? ...
>>
>> crypto.pk.decrypt(EF, keyID, function(plainText) {
>> ?... rejoice ...
>> });
>>
>> To fill in the ??? we need to store the keyID somewhere. ?(To be
>> clear, the keyID is just a capability to use the private key, which
>> never leaves the user agent's secure key store.) ?To complete your
>> example, we'd need to provide a facility to protect the keyID with the
>> user's password.
>>
>> Adam
>>
>>
>> On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
>>> Okay, I am a little confused now: What about the following use case:
>>>
>>> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>>>
>>> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>>>
>>> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>>>
>>> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>>>
>>> Thank you very much!
>>>
>>> Kind regards,
>>> Simon Heckmann
>>>
>>>
>>> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>>>
>>>> OK, so it would apply to a private video conference, but not to
>>>> protect a server-client-delivery. That's good to know, thanks.
>>>> Silvia.
>>>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>> Silvia:
>>>>>
>>>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>>>
>>>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>>>
>>>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>>>
>>>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>>>> To: "David Dahl" <ddahl at mozilla.com>
>>>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>>>
>>>>> If I understand this correctly, then this is introducing a mechanism
>>>>> for Web publishers to provide a secure service to users where the data
>>>>> exchanged between the server and the UA is encrypted and not decodable
>>>>> by anyone else listening in on that communication or getting access to
>>>>> the data stored in the browser for that communication.
>>>>>
>>>>> If so, could this be a means to provide a one-session-only decoding
>>>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>>>> video) from a publisher? I am quite directly thinking that this could
>>>>> be a first step towards providing DRM methodology in the browser, but
>>>>> also for example for about having secure private video conversations
>>>>> without needing to install browser plugins.
>>>>>
>>>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>>>
>>>>> Cheers,
>>>>> Silvia.
>>>>>
>>>>>
>>>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>>> Hello All:
>>>>>>
>>>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>>>> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>>>> ? ?HASH and HMAC methods may be implemented first
>>>>>> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>>>> ? ? ? ?Keypairs must be generated on a per-origin basis
>>>>>> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
>>>>>> ? ?No private or wrapped key material will be accessible to content scripts
>>>>>> ? ?Each implementation will provide a mechanism to clear keys
>>>>>> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>>>> ? ?The returned encrypted object format will be a raw ArrayBuffer
>>>>>> ? ?The public key format will be a raw ArrayBuffer
>>>>>> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>>>> ? ?HASH and HMAC methods should be synchronous to make them simpler
>>>>>> ? ? ? ?HASH and HMAC methods should be constructors
>>>>>> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>>>
>>>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>>>
>>>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>>>
>>>>>> Any comments and discussion will be most welcome.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David Dahl
>>>>>>
>>>>>
>>>
>

From simon at simonheckmann.de  Wed Jul 27 02:13:38 2011
From: simon at simonheckmann.de (Simon Heckmann)
Date: Wed, 27 Jul 2011 11:13:38 +0200
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAJE5ia_SC=ChnMesE1hXejkHjWZYByVC1x-9kkUJDXahMJqGRA@mail.gmail.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
	<CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
	<2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>
	<CAJE5ia_SC=ChnMesE1hXejkHjWZYByVC1x-9kkUJDXahMJqGRA@mail.gmail.com>
Message-ID: <C5A3FA4E-0BB2-4695-A50E-5838E1AB62F8@simonheckmann.de>

I totally agree with you. My code was just an example. I also think it should be idiot proof. 

However, I think the whole API should be loosly coupled. Requiring the client to initialize a cryptographic function on the server seems to tightly linked. I think it should be possible to decrypt any chunk of data with the DOMCrypt API as long as I know the algorithm and the key. But maybe this is out of scope and I am thinking in too universal concepts?

Kind regards,
Simon Heckmann


Am 27.07.2011 um 10:57 schrieb Adam Barth <w3c at adambarth.com>:

> The downside of that sort of API is that you end up storing key
> material in the JavaScript heap.  There's some question about whether
> we should avoid doing that, which is part of the motivation to do the
> public key API before the symmetric API.
> 
> Your example also raise the question of how to do key derivation and
> key agreement.  Taking the MD5 hash of a password isn't really the
> best key derivation function!  There's a design question of whether we
> should design the API to be usable (relatively) safely by non-experts.
> Given that this is an API for the web, you can understand the desire
> to make things as "idiot-proof" as possible.
> 
> I'd certainly like to see DOMCrypt be able to handle these sorts of
> use cases in the future.  It's mostly a question of which use cases to
> address first.
> 
> Adam
> 
> 
> On Wed, Jul 27, 2011 at 1:18 AM, Simon Heckmann <simon at simonheckmann.de> wrote:
>> Thank you for your reply, but to me this seems overly complicated. Why do I need a KeyId?
>> 
>> What about the following proposal:
>> 
>> Phase one: The server knows the user's password and encrypts the file.
>> Phase two: The encrypted file is stored on the local hard drive using the File API.
>> Pase three: User enters the password, which is hashed and used for decryption:
>> 
>> var password = document.getElementById('passwordfield').value;
>> var hash = window.crypto.hash('md5', password);
>> var data = window.crypto.decrypt('aes-256', hash, encfiledata);
>> 
>> This code is just a sample, but it looks way more convenient to me. Additionally there is no need to store the keyid somewhere?!?
>> 
>> Kind regards,
>> Simon Heckmann
>> 
>> 
>> Am 27.07.2011 um 04:14 schrieb Adam Barth <w3c at adambarth.com>:
>> 
>>> Hi Simon,
>>> 
>>> That would look something like the following:
>>> 
>>> == Phase 1: Key Generation (Client-Side) ==
>>> 
>>> crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
>>>  ... send pubKey to the server ...
>>>  ... store keyID somewhere??? ...
>>> });
>>> 
>>> == Phase 2: Encryption (Server-Side) ==
>>> 
>>> The server encrypts file F under public key pubKey.
>>> The server sends the encrypted file EF to the client and stores it
>>> locally using the File API.
>>> 
>>> == Phase 3: Decryption (Client-Side) ==
>>> 
>>> ... retrieve keyID from somewhere??? ...
>>> 
>>> crypto.pk.decrypt(EF, keyID, function(plainText) {
>>>  ... rejoice ...
>>> });
>>> 
>>> To fill in the ??? we need to store the keyID somewhere.  (To be
>>> clear, the keyID is just a capability to use the private key, which
>>> never leaves the user agent's secure key store.)  To complete your
>>> example, we'd need to provide a facility to protect the keyID with the
>>> user's password.
>>> 
>>> Adam
>>> 
>>> 
>>> On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
>>>> Okay, I am a little confused now: What about the following use case:
>>>> 
>>>> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>>>> 
>>>> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>>>> 
>>>> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>>>> 
>>>> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>>>> 
>>>> Thank you very much!
>>>> 
>>>> Kind regards,
>>>> Simon Heckmann
>>>> 
>>>> 
>>>> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>>>> 
>>>>> OK, so it would apply to a private video conference, but not to
>>>>> protect a server-client-delivery. That's good to know, thanks.
>>>>> Silvia.
>>>>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>>> Silvia:
>>>>>> 
>>>>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>>>> 
>>>>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>>>> 
>>>>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>>>> 
>>>>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>>>>> To: "David Dahl" <ddahl at mozilla.com>
>>>>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>>>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>>>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>>>> 
>>>>>> If I understand this correctly, then this is introducing a mechanism
>>>>>> for Web publishers to provide a secure service to users where the data
>>>>>> exchanged between the server and the UA is encrypted and not decodable
>>>>>> by anyone else listening in on that communication or getting access to
>>>>>> the data stored in the browser for that communication.
>>>>>> 
>>>>>> If so, could this be a means to provide a one-session-only decoding
>>>>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>>>>> video) from a publisher? I am quite directly thinking that this could
>>>>>> be a first step towards providing DRM methodology in the browser, but
>>>>>> also for example for about having secure private video conversations
>>>>>> without needing to install browser plugins.
>>>>>> 
>>>>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>>>> 
>>>>>> Cheers,
>>>>>> Silvia.
>>>>>> 
>>>>>> 
>>>>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>>>> Hello All:
>>>>>>> 
>>>>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>>>> 
>>>>>>> Summary:
>>>>>>> 
>>>>>>>    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>>>>>    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>>>>>    HASH and HMAC methods may be implemented first
>>>>>>>    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>>>>>        Keypairs must be generated on a per-origin basis
>>>>>>>        The Keypair for a specific origin cannot be used in another origin
>>>>>>>    No private or wrapped key material will be accessible to content scripts
>>>>>>>    Each implementation will provide a mechanism to clear keys
>>>>>>>    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>>>>>    The returned encrypted object format will be a raw ArrayBuffer
>>>>>>>    The public key format will be a raw ArrayBuffer
>>>>>>>        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>>>>>    HASH and HMAC methods should be synchronous to make them simpler
>>>>>>>        HASH and HMAC methods should be constructors
>>>>>>>    We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>>>> 
>>>>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>>>> 
>>>>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>>>> 
>>>>>>> Any comments and discussion will be most welcome.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> David Dahl
>>>>>>> 
>>>>>> 
>>>> 
>> 

From ddahl at mozilla.com  Wed Jul 27 07:16:17 2011
From: ddahl at mozilla.com (David Dahl)
Date: Wed, 27 Jul 2011 07:16:17 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <C5A3FA4E-0BB2-4695-A50E-5838E1AB62F8@simonheckmann.de>
Message-ID: <921425056.660750.1311776177162.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

----- Original Message -----
> From: "Simon Heckmann" <simon at simonheckmann.de>
> To: "Adam Barth" <w3c at adambarth.com>
> Cc: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>, "WHATWG Proposals" <whatwg at lists.whatwg.org>, "David Dahl"
> <ddahl at mozilla.com>
> Sent: Wednesday, July 27, 2011 4:13:38 AM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
> I totally agree with you. My code was just an example. I also think it
> should be idiot proof.
> 
> However, I think the whole API should be loosly coupled. Requiring the
> client to initialize a cryptographic function on the server seems to
> tightly linked. 
This is how we can limit the scope and reduce the attacks that are possible cross-domain. The keypair is usable only with the origin that created it.  

> I think it should be possible to decrypt any chunk of
> data with the DOMCrypt API as long as I know the algorithm and the
> key. But maybe this is out of scope and I am thinking in too universal
> concepts?
> 
Perhaps, however, your use cases are not out of the question. We just want to start with a smaller surface, making this API simpler to implement and use.

Regards,

David

From mhanson at mozilla.com  Wed Jul 27 09:30:26 2011
From: mhanson at mozilla.com (Mike Hanson)
Date: Wed, 27 Jul 2011 09:30:26 -0700
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
	<Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
Message-ID: <43DCE7F1-AD1A-4587-A0BA-E61B9F2AA291@mozilla.com>

On Jul 26, 2011, at 2:44 PM, Ian Hickson wrote:

> On Fri, 29 Apr 2011, Simon Heckmann wrote:
>> 
>> I have read a lot in the last month about the future of html and web 
>> applications and I am very impressed by the progress this makes. 
>> However, I have come across some thing that annoys me: Permissions. I 
>> know they are important and I know they are needed but currently I find 
>> this quite inconvenient. And with more and more permissions coming up 
>> this might get worse so I spent some time thinking about it.
> 
> <snip>
> In short, the better solution isn't to ask for permissions up-front, but 
> to ask for fewer permissions. The ideal solution is to not ask for any 
> permission but to base the permission on a natural user gesture. For 
> example, drag-and-drop of files to a site doesn't require permissions, but 
> it is an implicit permission grant. Same with <input type=file>. With 
> getUserMedia() we are doing something similar: instead of asking for 
> permission, the user is asked for a specific input to be selected.
> <snip>
> Indeed. The system shouldn't ask for any permissions. For example instead 
> of reading contact data, it could cause the OS to pop up a contacts list 
> from which you can pick a contact to give access to it to the app.

The challenging use case, and one that we had trouble with when we prototyped the Contacts API, is for ongoing or persistent access.  The best approach we have right now is to use explicit markup to "sandbox" the permissions grant away from untrusted code.

In the Contacts case, for example, autocomplete of email addresses, names, and phone numbers was a desired use case.  A naive approach is to let the web app read the entire database and perform autocompletion in content.  The safe approach, which was harder and less flexible, is to attach autocomplete behavior to input type="tel" and "email", and to set the autocompleted value only when the user has selected it.

There are definite UX limitations to that approach - the content can't provide visual hinting during the autocomplete, for example (it would be nice if a photo gallery could trim down the set of photos from my friends as I narrow in on the name).  The limitations create an incentive for content to try to get the full set of data anyway, through some other channel.  As Roc commented, finding a way to be comfortable with a higher-level permissions grant that persisted over a longer span could be one way to address that.
--
Michael Hanson, Mozilla Labs

From cmhjones at gmail.com  Wed Jul 27 09:59:36 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Wed, 27 Jul 2011 17:59:36 +0100
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
	<Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
Message-ID: <49A84F2A-C13D-4E96-860D-6CB9854E0523@gmail.com>


On 26/07/2011, at 10:44 PM, Ian Hickson wrote:
> Robert O'Callahan posted a good response:
> 
> http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html
> 
> In short, the better solution isn't to ask for permissions up-front, but 
> to ask for fewer permissions. The ideal solution is to not ask for any 
> permission but to base the permission on a natural user gesture. For 
> example, drag-and-drop of files to a site doesn't require permissions, but 
> it is an implicit permission grant. Same with <input type=file>. With 
> getUserMedia() we are doing something similar: instead of asking for 
> permission, the user is asked for a specific input to be selected.
> 
> Permission grants are a bug.
> 

nice recap and clarity on implicit vs explicit permissions. the concept of asking for permission and how to manage this would seem to remain open for explicit permission grants, the most pressing case being geolocation. might there be more use cases in future? this may open the case for more universal management mechanism through the UA, and potentially a generalized specification?

> On Sat, 30 Apr 2011, Glenn Maynard wrote:
>> 
>> Of course, asking each of these while using the application would also 
>> be painfully annoying, and it's not obvious how to make permissions 
>> meaningful to the user (eg. when you use its feature) while also scaling 
>> to lots of permissions.
> 
> Indeed. The system shouldn't ask for any permissions. For example instead 
> of reading contact data, it could cause the OS to pop up a contacts list 
> from which you can pick a contact to give access to it to the app.

yes, possibly permissions should be viewed not in terms of the resource they may require to access (webcam, mic, printer, etc) but the conceptual user interaction - image\video source, audio source, document serialization, etc...

> 
> On Sun, 1 May 2011, Robert O'Callahan wrote:
>> 
>> Notifications are a particularly hard case for the principle of 
>> requesting permissions in response to user action, because the whole 
>> point of notifications is that they happen when the user isn't giving 
>> the application attention :-).
> 
> My proposal for notifications was to have them default to being just 
> inside the page (nothing that a <div> couldn't do), but that they would 
> include explicit UI to promote them to full-system notifications; and 
> vice-versa, so a system notification could be demoted back to just in-page 
> notification with a similar gesture.

possibly the interaction should not be with the system but the browser. this leaves any system-level integration in full control of the browser and restricts the specification to a single level of abstraction.

> On Tue, 3 May 2011, Cameron Heavon-Jones wrote:
>> 
>> The quantity of permission requests can be managed in an effective 
>> manner by the agent allowing the user to store their preferences for the 
>> next command or as a universal setting.
> 
> That doesn't work. It might be appropriate for Bing Maps to have access to 
> my Geolocation information, but I certainly don't want some random blog to 
> have access to it. Defaults don't work here.

the UI concept is that of user preference management, it can apply to permissions, confirmations, or any other user configurable setting.

there is no reason geolocation can't be managed in the same way. if i always want bing maps to have access to my location, it would be nice to be able to register that preference. for some random blog that always asks for my location, it would be nice to block it from asking again.

it's not defaults, but in-process persistent configuration.

>> For web applications to specify their required permissions would seem to 
>> introduce a duplication of specification. If a web application includes 
>> an image file upload which the user chooses to capture from webcam, 
>> first how is the application to know that the user would use a web cam?
> 
> There's no need for the app to know. It can just allow the user to upload 
> a photo, and the browser can offer to use the webcam.

indeed.

> I haven't added anythign to the spec in relation to this proposal.
> 

the proposal for a web app descriptor for implicit permissions would seem to be debunked, however the greater question of how to manage the explicit geolocation feature is both still open and an issue being encountered today. 

what concerns me is the interaction between web application\document and browser shell\chrome which is new territory. the concept of background web pages, introducing notification requirements, is also an area requiring active attention.

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

Thanks,
Cameron Jones


From cmhjones at gmail.com  Wed Jul 27 10:44:34 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Wed, 27 Jul 2011 18:44:34 +0100
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <43DCE7F1-AD1A-4587-A0BA-E61B9F2AA291@mozilla.com>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
	<Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
	<43DCE7F1-AD1A-4587-A0BA-E61B9F2AA291@mozilla.com>
Message-ID: <1A4DBE8E-BCA7-4325-9EBB-95ED91ADDFC3@gmail.com>


On 27/07/2011, at 5:30 PM, Mike Hanson wrote:
> The challenging use case, and one that we had trouble with when we prototyped the Contacts API, is for ongoing or persistent access.  The best approach we have right now is to use explicit markup to "sandbox" the permissions grant away from untrusted code.
> 
> In the Contacts case, for example, autocomplete of email addresses, names, and phone numbers was a desired use case.  A naive approach is to let the web app read the entire database and perform autocompletion in content.  The safe approach, which was harder and less flexible, is to attach autocomplete behavior to input type="tel" and "email", and to set the autocompleted value only when the user has selected it.

This is a sound approach, i'm not sure of the implementation complexities. 

The mapping of "tel" and "email" inputs to a contacts list is functional, not systematic. Might this be extended for some other inputs: date(*), url, search etc?

This functionality may be declared and defined through a new attribute, since autocomplete is already used, something like "autoassist"? 

Maybe this would be able to over-ride the default "file" input behaviour of launching a popup in the case i just want to manually enter a file:///

> 
> There are definite UX limitations to that approach - the content can't provide visual hinting during the autocomplete, for example (it would be nice if a photo gallery could trim down the set of photos from my friends as I narrow in on the name).  

This would seems to be ok as long as the contents remain sandboxed until selection is confirmed.

> The limitations create an incentive for content to try to get the full set of data anyway, through some other channel.  As Roc commented, finding a way to be comfortable with a higher-level permissions grant that persisted over a longer span could be one way to address that.

It would be nice for a page\site\app to still be able to access a full contacts list if desired. Though it would seem to extend the integration into the full Contacts API which is of far larger scope.

> --
> Michael Hanson, Mozilla Labs


Thanks,
Cameron Jones

From Simetrical+w3c at gmail.com  Wed Jul 27 12:24:15 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 27 Jul 2011 15:24:15 -0400
Subject: [whatwg] Nested list
In-Reply-To: <5a068af50907021505jd494b69n552f7ea68032c344@mail.gmail.com>
References: <5a068af50907021505jd494b69n552f7ea68032c344@mail.gmail.com>
Message-ID: <CAKA+Axmms6zTKNmSiYs+rFKyBh9KSpYPB+mPfwSPt-J360stEQ@mail.gmail.com>

(Ian pointed out this old thread to me that he hadn't yet responded
to, so I'll respond now.)

On Thu, Jul 2, 2009 at 6:05 PM, Ryosuke Niwa <rniwa at google.com> wrote:
> Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
> nested OL or UL without LI. ?See
> http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.2 ?In fact, the
> nested list example is marked deprecated. ?But in practice, all major
> user agents produce nested list when execCommand("Indent"...) is
> executed. ?Is there any chance we can?standardize?nested lists, and in
> particular, what UA produce?

I opened a bug about this a while ago:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12609

> For example, all?major?browsers (Firefox, IE, & WebKit)?produce
> slightly different?versions of HTML?when?indenting?"item?2"?in the
> following HTML (assume it's content-editable):
> <ol>
> <ol id="u1"><li id="i1">item 1</li></ol>
> <li id="i2">item 2</li>
> <ol id="u3"><li id="i3">item 3</li></ol>
> </ol>
>
> In particular, many UA remove arbitrary id attributes.

If you remove the whitespace nodes (which currently confuse my
algorithms in lots of places -- it's a known issue), it produces

<ol><ol id="u1"><li id="i1">item 1</li><li id="i2">ite[m] 2</li><li
id="i3">item 3</li></ol></ol>

according to my implementation.  This is because of the following
steps in the indent algorithm at the time of this writing:

* Let tag be the local name of the parent of first node.
* Wrap node list, with sibling criteria matching only HTML elements
with local name tag and new parent instructions returning the result
of calling createElement(tag) on the ownerDocument of first node.
http://aryeh.name/gitweb.cgi?p=editing;a=blob_plain;f=editing.html;hb=e4c523de#indent

Since the sibling criteria only require the sibling to have local name
tag (in this case "ol"), without regard to attributes, it's considered
valid for merging.  Since both the previous and next siblings match
the sibling criteria, the next sibling is merged into the previous
sibling, so the resulting element has the id of the original first
element.

Chrome 14 dev merges them but keeps the id of the second list, not the
first.  Firefox 7.0a2 merges into the second list, and ignores the
first list even if it has no id -- it seems to ignore previous
siblings if there's a legitimate next sibling.  Opera 11.50 gives the
same output as the spec.  IE10PP2 merges the three items into one list
that has no id at all.  I think that the spec (= Opera) is reasonable
here -- anyone disagree?

I added a few tests to my test suite based on this feedback:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=d4233f8f

On Mon, Jul 13, 2009 at 7:01 AM, Simon Pieters <simonp at opera.com> wrote:
> I think this is a bug in execCommand('indent') and should be fixed in
> browsers.

I disagree.  I found when writing my spec that having <ol>/<ul> nested
inside <li> complicates a lot of things needlessly, because the
<ol>/<ul> is visually part of the parent <ol>/<ul> and not the <li>.
I wound up aggressively normalizing list items so that if they contain
<ol> or <ul>, those are broken out to become siblings in any case
where it might cause problems:

http://aryeh.name/gitweb.cgi?p=editing;a=blob_plain;f=editing.html;hb=e4c523de#normalize-sublists

I don't see that this has any semantic problem.  We can simply define
the semantics of <ol><li>foo</li><ol><li>bar</ol></ol> as being the
same as those of <ol><li>foo<ol><li>bar</ol></ol>.

On Thu, Sep 3, 2009 at 8:29 PM, Ian Hickson <ian at hixie.ch> wrote:
> There are lots of bugs that need fixing with execCommand(); I don't see
> why this wouldn't be one of them.

I've considered the issue carefully and determined that it's HTML5's
authoring requirements that should change here, not browsers'
execCommand() behavior.  Basically, to avoid extra branching, we want
to ensure that all nested lists we deal with are consistent, either
all nested directly or all nested inside <li>'s.  Having them nested
directly makes things simpler.

For instance, suppose you have markup like
<ol><li>foo<ol><li>bar</ol>baz</ol> and the user outdents the middle
item.  This needs to be a special case: you have to notice that you're
a descendant of an <li>, break that into two, and stick the <ol> in
between.  If you first normalize and make the markup look like
<ol><li>foo</li><ol><li>bar</ol><li>baz</ol>, outdenting the middle
item can completely ignore the outer list with no need for a special
case.

Or take another case: consider the markup,
<ol><li>foo<li>bar<ol><li>baz</ol></ol>, and have the user select
"bar" and try to indent it.  It looks like "baz" is a separate item,
so the user will expect it not to get indented along with "bar".  This
means you need to do a bunch of complicated stuff: first you need to
look for a previous list item to move things into ("foo" in this
case), then check if there's already an <ol> at the end of it, merge
into that <ol> if so, otherwise create a new <ol>, move the whole <li>
containing "barbaz" into the new <ol>, move the "baz" <li> out of its
<ol>, remove that.  Or something like that.  If I first normalize to
<ol><li>foo<li>bar</li><ol><li>baz</ol></ol>, I can wrap the bar <li>
with no extra work at all, reusing my "wrap" algorithm that checks for
siblings that match given criteria and creates a new wrapper if none
are found.

There are lots of cases like this.  Often if a list is directly nested
inside another list without an intervening <li>, you can treat it
either like a non-nested list or like an <li>.  I found that not
normalizing lists to be directly nested just created pointless
headaches for no gain.  There's no obstacle to us defining new
semantics in this case and making it valid.

From Simetrical+w3c at gmail.com  Wed Jul 27 12:36:09 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 27 Jul 2011 15:36:09 -0400
Subject: [whatwg] [editing] Proposal: Undeletable elements within
	contentEditable
In-Reply-To: <490014A7-1BFC-4FD1-8737-9FDDF02EC741@elv1s.ru>
References: <490014A7-1BFC-4FD1-8737-9FDDF02EC741@elv1s.ru>
Message-ID: <CAKA+AxkjpvNt6VKPMVem2S3xkmEyy5vPXdS1JB2KbUTDhnxNWA@mail.gmail.com>

(Responding to some old feedback on editing from before I started work
on it, which Hixie sent me.)

On Thu, Jun 24, 2010 at 12:08 PM, Nikita Vasilyev <me at elv1s.ru> wrote:
> The current version of spec
> http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable
> does not define any way to make an element within contentEditable
> undeletable. I propose "undeletable" attribute:
>
> element.undeletable = "true" | "false"
>
> How should it work:
>
> <div contenteditable>
> ?<span undeletable>foo</span>
> </div>
>
> When I focus on the div, select all the text, and delete it, the span
> element MUST be empty, but MUST NOT be deleted.
>
> This behavior would be very useful while building code editors. I'm building
> CSS editor with syntax highlighting and auto-completion based on
> contentEditable. "undeletable" attribute would help me a lot.

I'm very reluctant to add such things, because it adds corner cases
that vastly complicate processing and allow tons more room for bugs.
It means every single algorithm related to editing needs to be aware
of the attribute and check for it before deleting anything.  This is
already a big headache for contenteditable=false, which has tons of
bugs in my algorithms and in browsers that I haven't even tried fixing
systematically yet.

Also, I don't know what use it would be to have the empty wrapper
element hanging around.  I've designed the editing algorithms to avoid
leaving such things: the user can never focus them, typically, so they
don't do much unless you're adding weird styles or such.

If you really wanted this effect, though, I think <span
contenteditable=true> should in theory do what you want.  I've been
designing my spec's algorithms based on the premise that an editing
host should never be deleted or have its attributes modified, but it
can be moved around if it's inside another editing host.  There are
probably loads of bugs in the spec, as I said, and browsers have a
very different view of how things should work in practice, but that's
my goal.

I haven't given a lot of thought to nested editing hosts or nested
non-editable content, though.  I'm not sure what the use-cases are.
It would help a lot if you could explain exactly what you want this
for.

2010/6/24 Joseph Thomas <jthoma12 at calpoly.edu>:
> It seems like the ideal way to handle this would be to handle the
> MutationEvent (and cancel it, but unfortunately they are
> non-cancelable. Perhaps a set of cancelable events, i.e.
> UserMutationEvent.
>
> ( see http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents
> )

Mutation events are a massive headache and we're trying to get rid of
them, so this isn't a feasible long-term suggestion.  See the very
long recent thread on the public-webapps list on this subject.

From ian at hixie.ch  Wed Jul 27 13:37:33 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 27 Jul 2011 20:37:33 +0000 (UTC)
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CABLsOLA0z-+Z4McW8LH2ziZm-o-x8CcPe=_95msWFGyVyiuvGA@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<CABLsOLA0z-+Z4McW8LH2ziZm-o-x8CcPe=_95msWFGyVyiuvGA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107272031190.2079@ps20323.dreamhostps.com>

On Tue, 19 Jul 2011, Takeshi Yoshino wrote:
> 
> Use of deflate-stream is now mandatory in API spec. I think this kind of 
> requirement is useless. How about leave it up to implementors' decision? 

Well we don't want optional features, so it's either in or out.


> I think this requirement doesn't really help us enforce endpoints
> initiate/accept WebSocket with the same configuration. Because
> 
> - non-browser UAs are free to be implemented without deflate-stream

Non-browser clients of Web Sockets are going to be comparatively rare and 
will not have the market power to affect de-facto requirements. So for 
the purpose of the API, they are irrelevant.


> - server developers would see/care only the wire protocol spec

Server developers are only going to care about what browsers need, not 
what specs say.


> So, server developers would simply make their implementation accept both 
> requests with and without deflate-stream, I think.

It's fine if they do.

We just need to make sure they don't require it to be supported, or 
require it to not be supported, and thus force us into one or the other. 
The simplest way to prevent that is to make sure all the browsers act the 
same.


> It's not likely that server implementors are influenced by "the 
> WebSocket API" and have their server check if a UA is browser or not and 
> reject requests w/o deflate-stream.

Not intentionally, maybe, but it is most definitely going to happen.


> The only people who benefit from this requirement is those who implement 
> a server only for their own use and are not interested in serving 
> non-browser clients.

That will likely be the majority of implementors.


On Wed, 20 Jul 2011, Bjoern Hoehrmann wrote:
> 
> The deflate-stream extension, when used for browser to server messages 
> allows an attacker to put whatever bytes he likes on the wire, after a 
> bit of unpredictable junk. Browser vendors were pretty opposed to that 
> for the normal protocol without extensions, and they were opposed to 
> having some way to make browsers send messages "unmasked"; so it would 
> be very odd for browser vendors to implement the extension. And by the 
> looks of it, the hybi Working Group may well drop deflate-stream now. 
> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html> 
> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.

I've changed the spec to make the extension disallowed rather than 
required.

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

From Simetrical+w3c at gmail.com  Wed Jul 27 13:47:43 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 27 Jul 2011 16:47:43 -0400
Subject: [whatwg] DOM Range Deletions
In-Reply-To: <4C175B5C.2050106@ado.is-a-geek.net>
References: <4C175B5C.2050106@ado.is-a-geek.net>
Message-ID: <CAKA+AxmEFbW8USpnvkyD+i5ZdJexskHVheg7w4976vpW7PG8Hg@mail.gmail.com>

(answering some old feedback on DOM Range that Hixie pointed me to)

On Tue, Jun 15, 2010 at 6:52 AM, Andrew Oakley <andrew at ado.is-a-geek.net> wrote:
> I've been trying to implement DOM Range but can't work out how ranges
> are supposed to work under mutation.

This should now be more or less fully defined in the DOM Range spec,
with a pretty decent test suite:

http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation

I wrote up the new definitions a couple of months ago.  They aim to be
both precise and compatible with browser behavior, which means they
mostly match DOM 2 Range but differ in some respects.

> In the following examples I use *this* to indicate a range being deleted
> and slashes to indicate another range.
>
>
> Section 2.6 - Deleting Content with a Range gives the example of
>
> <FOO>X*Y<BAR>Z*W</BAR>Q</FOO> -> <FOO>X^<BAR>W</BAR>Q</FOO>
>
>
> Section 2.12.2 - Deletions says:
>
> "If a boundary-point of the original Range is within the content being
> deleted, then after the deletion it will be at the same position as the
> resulting boundary-point of the (now collapsed) Range used to delete the
> contents."

This is not what browsers do, and not what the new DOM Range spec
requires.  DOM 2 Range treats deletions as deletions of ranges, but
browsers and DOM Range both treat deletions as node-by-node.
deleteContents() specially modifies the range you call it on so that
it's always collapsed, as is defined in detail:

http://html5.org/specs/dom-range.html#dom-range-deletecontents

Note how the last step is "Set the context object's start and end to
(new node, new offset)", so the range you call the method on is
changed differently from other ranges.

If you have a range <FOO>X[Y<BAR>Z]W</BAR>Q</FOO> (using [] to denote
the endpoints), then the algorithm works as follows:

* "If original start node is an ancestor container of original end
node, set new node to original start node and new offset to original
start offset."  Original start node here is the Text node "XY", and
original end node is the Text node "ZW".  The former is neither equal
to nor an ancestor of the latter, so this doesn't apply, and we go to
the other branch.

* "Let reference node equal original start node."  So reference node
is now the Text node "XY".

* "While reference node's parent is not null and is not an ancestor
container of original end node, set reference node to its parent."
Reference node's parent is <FOO>, which is not null, but is an
ancestor container of original end node.  Thus we do nothing in this
step.

* "Set new node to the parent of reference node, and new offset to one
plus the index of reference node."  Thus new node is <FOO>, and new
offset is 1.

So the Range you delete will eventually collapse to
<FOO>X{}<BAR>W</BAR>Q</FOO>.  Note that here I use curly braces
instead of brackets, to indicate that the endpoint of the Range is in
an Element node, not a Text node.  The old DOM 2 Range standard is
unclear on that point, but my spec matches what browsers do.

> We then have the example of:
>
> <P>ABCD *efgh The <EM>R*ange</EM> ijkl</P>
> ? ? ? ? ? ? ?/ ? ? ? ? ? ?\
>
> Goes to
>
> <P>ABCD <EM>ange</EM> ijkl</P>
> ? ? ? ? ? / ? ?\

In the syntax I'm using, that's: <P>ABCD [efgh T[[he <EM>R]ange]]</EM>
ijkl</P>, where I use single brackets for the range being deleted and
double brackets for the other, for lack of better syntax.

The new specification uses entirely different rules when the Range
being deleted is different from the one being modified, as I noted.
The deletion is treated as a sequence of separate mutations of
individual nodes.  In this case, deleteContents() will do the
following:

1) Call deleteData() on the Text node "ABCD efgh The ", with offset 5
and count 9.  This deletes "efgh The " and leaves only "ABCD ".
Current DOM Core defines this as replacing data with offset 5, count
9, and data "", so we look at the "When something replaces data of a
CharacterData node" case at
<http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation>.

The first boundary point of the [[ range has offset 11, and 5 < 11 <=
5 + 9, so we hit the case "For every boundary point whose node is
node, and whose offset is greater than offset but less than or equal
to offset plus count, set its offset to offset."  Thus the offset is
set to offset, i.e., 5.  This gives us:

<P>ABCD [[<EM>Range]]</EM> ijkl</P>

2) Call deleteData() on the Text node "Range", with offset 0 and count
1.  This deletes "R" and leaves "ange".  We're replacing data with
offset 0, count 1, and data "", and the second boundary point of the
]] range has offset 5, and 5 > 0 + 1, so we hit the case "For every
boundary point whose node is node, and whose offset is greater than
offset plus count, add the length of data to its offset, then subtract
count from it."  The length of data is 0 and count is 1, so we set the
new offset to 5 + 0 - 1 = 4.  This gives us:

<P>ABCD [[<EM>ange]]</EM> ijkl</P>

The example in DOM 2 Range implies something more like <P>ABCD
<EM>[[ange]]</EM> ijkl</P>.  I agree this is wrong according to DOM 2
Range itself.  DOM 2 Range is a decent spec for its time, but we've
moved to much greater levels of precision these days.  One thing it
often does is not clearly distinguishing boundary points that "look"
the same, in that no nodes or characters lie between them.

> I assume that the range indicated by the underline in the spec and like
> *this* here collapses to just before the <EM> tag as this document has
> the same structure as the other example I pulled out of the spec. ?This
> would mean that the start point of the other range should also be just
> before the <EM>, but that isn't what has happened in this example.

The example is buggy, yes.  The starting <EM> tag should be
highlighted according to both specs and according to browser behavior.

> Any idea what I've got wrong? ?Some browsers (e.g. Safari) seem to
> behave as in the example, others (e.g. Firefox) put the end point before
> the <EM> (as I would have expected).

Here's a test case:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1086

Firefox 7.0a2, Chrome 14 dev, and Opera 11.50 all log "ABCD", "5",
"ange", "4", which matches my spec.  IE10PP2 logs "ABCD", "5",
"undefined", "1".  The "undefined" winds up being because it puts the
new endpoint in the <em> with offset 1, instead of in the Text node
"ange" with offset 4.  IE might or might not be able to argue that
it's correct per DOM 2 Range, but it's not correct according to the
new spec.

I have a reasonably comprehensive test suite for range mutation
behavior, by the way:

http://aryeh.name/spec/dom-range/test/Range-mutations.html

It only tests what happens with basic DOM operations like replaceData,
though, it doesn't check if things like Range.deleteContents do any
additional magic.

From timdown at gmail.com  Wed Jul 27 15:55:04 2011
From: timdown at gmail.com (Tim Down)
Date: Wed, 27 Jul 2011 23:55:04 +0100
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
	<CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
	<CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>
Message-ID: <CAOYSAj0xN-ZnzSB0ogkks-NPM4-R4Y-XHV63ySkZBuoLVA8+hA@mail.gmail.com>

On 21 July 2011 20:59, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Wed, Jul 20, 2011 at 6:23 PM, Tim Down <timdown at gmail.com> wrote:
>> Yes, but it's significantly better than the alternative, which is to
>> write your own code to search for text that spans nodes.
>
> It shouldn't be *too* hard to write that code. ?First do the search in
> textContent and get a list of the offsets of all the results. ?Then
> get a list of Text nodes, and iterate through them. ?Record the sum of
> their lengths as you go, and when you get to the right place, store
> the result. ?I'd guess it would be 20 lines or so. ?Something like
> this (untested):
>
> function findStrings(root, search) {
> ? ?var offsets = [];
> ? ?for (var i = root.textContent.indexOf(search); i != -1; i =
> root.textContent.indexOf(search, i + 1)) {
> ? ? ? ?offsets.push(i);
> ? ?}
> ? ?var results = [];
> ? ?var treeWalker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT);
> ? ?var currentOffset = 0;
> ? ?while (treeWalker.nextNode()) {
> ? ? ? ?while (offsets.length
> ? ? ? ?&& currentOffset <= offsets[offsets.length - 1]
> ? ? ? ?&& offsets[offsets.length - 1] < currentOffset +
> treeWalker.currentNode.length) {
> ? ? ? ? ? ?results.push([treeWalker.currentNode,
> offsets[offsets.length - 1] - currentOffset]);
> ? ? ? ? ? ?offsets.pop();
> ? ? ? ?}
> ? ? ? ?currentOffset += treeWalker.currentNode.length;
> ? ?}
> ? ?return results;
> }
>
> Probably buggy, but something like that should work. ?(And hey, it's
> 19 lines, good guesswork.) ?Granted, if you wanted to do any kind of
> normalization it would be more complicated to author, but also more
> complicated to spec. ?So I don't see really a use-case here that's
> strong enough to justify this, if we can get rid of it.

There's also the perennial problem of dealing with non-visible text
(c.f. Selection.toString(), innerText), which some browsers handle (a
quick tests suggests WebKit searches non-visible text and Firefox
doesn't). Also, don't forget that you're in the habit of writing this
sort of code. Knocking that kind of code out quickly is beyond what a
large percentage of web developers are capable of.


>> Agreed. My number two feature (well, it would make the top 5, at
>> least) would be removing the restriction on execCommand() only working
>> on editable content. This very use case shows that its usefulness
>> extends beyond editable content. The temporarily-switch-designMode-on
>> workaround is ugly, and destroys the selection in some browsers.
>
> As I said elsewhere, I disagree. ?Wanting to only modify editable
> content is an important use-case. ?It's easy to emulate the behavior
> you want if that restriction is in place (temporarily turn on
> designMode), but nearly impossible to emulate the opposite behavior if
> it's not built in to start with. ?If execCommand() worked on any
> content at all, then text editors would be permanently forced to use
> iframes with designMode instead of being able to use contenteditable,
> just to avoid the user randomly bolding or deleting interface text.
> Also, it would mean that (for instance) execCommand("delete") works
> differently from the backspace key.
>
> If turning designMode on destroys the selection in some browsers,
> that's a bug that can easily be fixed, and doesn't justify a change to
> the spec. ?Changing specs to work around easily-fixed browser bugs
> makes much less sense than just fixing the bugs. ?The only
> disadvantage I see to requiring this is that it's error-prone: the
> obvious way to do it is to turn designMode on and then turn it off,
> which will have an unexpected side effect if it had already been on.
> But that's a minor issue, and I don't see a good way to avoid it.
>
> Why exactly do you not want to turn designMode on and off, other than
> easily-fixed browser bugs? ?What do you think is "ugly" about it?

I absolutely agree that restricting mutation to editable content is
important. My issues with using designMode are a combination of side
effects and implementation quirks in current and older browsers, which
I agree doesn't justify a change to the spec, and a gut feeling that
it's the wrong approach. There is no reason why your algorithms can't
work on non-editable nodes, so why require the user to change such a
fundamental property of the DOM (even temporarily)? I'd prefer an
alternative mechanism for specifying whether a command should apply to
only editable content that is part of the editing API. In my
execCommand implementation, it's specified as a property of an options
object passed to execCommand(). If that's not an option, another
command could be used, similar to the styleWithCSS command, to switch
between modes. applyToNonEditable, or something.

Tim

From ian at hixie.ch  Wed Jul 27 16:38:47 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 27 Jul 2011 23:38:47 +0000 (UTC)
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <BANLkTikmAr2GZZMYEXj3rjQfQS=1OuzwTA@mail.gmail.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>
	<4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
	<AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com>
	<4bf304a4.513dd80a.189a.1578@mx.google.com>
	<AANLkTimYMfwCc-FZqLSpIv2rqVD1Vvljazsh6Btobvzr@mail.gmail.com>
	<AANLkTim1o2OgWVyrIjQXcFpWSNe_2Rujf8SXSSq31H8S@mail.gmail.com>
	<4bf3ec37.e198d80a.29a8.380e@mx.google.com>
	<Pine.LNX.4.64.1008032356060.7470@ps20323.dreamhostps.com>
	<4c5a2147.d908e30a.2998.6700@mx.google.com>
	<Pine.LNX.4.64.1008261714270.3392@ps20323.dreamhostps.com>
	<AANLkTimxi8OwZ_Px1c-rFpXbvS36H3OTWxS2wKERdkNK@mail.gmail.com>
	<Pine.LNX.4.64.1012072350120.26618@ps20323.dreamhostps.com>
	<AANLkTi=WJa9vLK7k23ROFsRxfSZO1yYS_g7sUdECqJ58@mail.gmail.com>
	<Pine.LNX.4.64.1104282129150.19153@ps20323.dreamhostps.com>
	<BANLkTimk9_0GEyxaTTH5TTO1m_C5eLg5XA@mail.gmail.com>
	<Pine.LNX.4.64.1104282212170.25791@ps20323.dreamhostps.com>
	<BANLkTikmAr2GZZMYEXj3rjQfQS=1OuzwTA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107272332230.2079@ps20323.dreamhostps.com>

On Fri, 29 Apr 2011, Bjartur Thorlacius wrote:
> On 4/28/11, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 28 Apr 2011, Bjartur Thorlacius wrote:
> >> All current UAs would understand the link (and most probably present it
> >> to the user). Inline presentation is an optional luxury: the important
> >> thing is getting the media across. I, for one, can't find any sign of
> >> <source> support in wget, and a few other "non-mainstream" UAs.
> >
> > Well for <video> fallback people are likely to use <a> as well, but I
> > don't think it makes sense to force every <source> to be a link.
>
> Writing both <source> and <a> for every source seems like unnecessary
> duplication to me. The primary difference between the two is that the
> resource referenced by the former is to be displayed inline, but the
> resource referenced by the latter is to be accessible interactively.
> <a style="content: url(attr(href));" href="/usr/videos/lolcatz">Funny
> cats jumping around</a>.
> Ok, this isn't valid CSS, but you get my thinking (I hope).

While I can see where you're coming from, I don't think overloading one 
element for all hyperlink and resource link features makes sense. 
Different links have different needs. The incremental cost of adding new 
ways to get resources in wget(1) is much lower than the cost of 
overloading all the various linking mechanisms into one element, IMHO.

It is, in any case, too late for <video>. However, I will keep in mind 
what you have said for future features.

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

From rniwa at webkit.org  Wed Jul 27 16:51:31 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Wed, 27 Jul 2011 16:51:31 -0700
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
Message-ID: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>

Feedback on  sections 1 through 3:

   - WebKit treats any font-weight above or equal to 600 as bold because
   that's what user sees, and boldness is a binary concept in execCommand;
   Firefox 5 appears to do the same.
   - WebKit compares colors in rgb/rgba format; e.g. red is first parsed as
   rgb(255, 0, 0).  Firefox 5 seems to does the same as well.
   - WebKit compares font sizes in legacy font size used in font element;
   See CSSStyleSelector::legacyFontSize or legacyFontSizeFromCSSValue in
   EditingStyle.cpp
   - Throwing SYNTAX_ERR might cause a backward compatibility issue because
   the UAs don't throw an error now.  We can probably throwing console messages
   first to give authors some grace period to transition.
   - For font element vs. span with style issue, we could add another
   boolean flag that forces UAs to toggle font-element; i.e. add StyleWithFont
   command.
   - 3.2: Prefix "webkit-" doesn't seem natural given all editing commands
   use Camel case.  Maybe Ms, Gecko, WebKit and Opera?  e.g.
   WebKitFontSizeDelta.  But again this might cause a backward compatibility
   because we do implement few editing commands that are not in the spec and
   they are not prefixed.
   - 3.3: The return value of queryCommandEnable depends on beforecut,
   beforecopy, and beforepaste events and selection state in WebKit; WebKit
   returns false if default actions are prevented in those events or selection
   is not a range.  Firefox 5 appears to do the same for selection but doesn't
   seem to fire beforecut, beforecopy, and beforepaste.

- Ryosuke

On Tue, Jul 26, 2011 at 2:26 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> Since February, I've been working on writing a detailed specification
> for browser editing, primarily the document.execCommand() and
> document.queryCommand*() methods.  These were created by Microsoft in
> the 1990s and were subsequently adopted in some form by all other
> browsers, and today browsers have to implement them to be compatible
> with web content, but no detailed specification ever existed.
> Interoperability is practically nonexistent as a result, which has
> driven all major content editing frameworks away from using
> execCommand().  Hopefully we can start to fix that and make these APIs
> a part of the web platform that just works.
>
> The current version of the specification is at
> <http://aryeh.name/spec/editing/editing.html>.  It's about fifty pages
> printed, and supersedes the Editing APIs section of HTML
> <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis
> >
> (which is more like two pages).  In the style of modern web specs, it
> is phrased in terms of algorithms that attempt to cover all corner
> cases unambiguously and leave no behavior undefined, and it tries to
> match the behavior of existing browsers to the greatest extent
> possible.  At this point, it's stable and complete enough that I
> believe it's ready for serious review by implementers, and I would
> like as much detailed feedback as possible.
>
> There is a basically complete JavaScript implementation, which is used
> to produce expected results for a largely undocumented and entirely ad
> hoc test suite:
> <http://aryeh.name/spec/editing/autoimplementation.html>.  I used the
> tests as an aid to writing the spec, and they probably aren't well
> suited to aid implementers in implementing it.  I will probably get
> around to porting them to something like testharness.js at some point.
>  I haven't tried testing my implementation on real-world sites, only
> on artificial input, so I don't know at this point how implementable
> it really is, but the JS implementation means that it at least has
> large parts that make sense.
>
> Anyone reviewing the spec should be advised that I put extensive
> rationale in HTML comments.  If you want to know why the spec says
> what it does, check the HTML source.  I plan to change this to use
> <details> or such in the near future.  There are lots of minor known
> issues still left, but none that I thought was important enough that
> it needs to delay review.  Feedback can be sent to the whatwg list,
> CCing me, with [editing] in the subject.  (I'm also fine receiving
> feedback on public-html or public-webapps, but I don't know if the
> chairs would be okay with that, since it's off-topic.)  I should be
> available to respond to all feedback promptly at least through the end
> of August.  After that, I can't make specific guarantees about my
> availability, but I do plan to continue maintaining the spec in the
> long term.
>
> I've CCd or BCCd everyone who's commented on or contributed to this
> spec at some point.
>

From ian at hixie.ch  Wed Jul 27 17:21:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 28 Jul 2011 00:21:10 +0000 (UTC)
Subject: [whatwg] Form element invalid message
In-Reply-To: <BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>

On Fri, 29 Apr 2011, Jonas Sicking wrote:
> On Fri, Apr 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 29 Dec 2010, Mounir Lamouri wrote:
> >> On 12/29/2010 07:41 AM, Ian Hickson wrote:
> >> >>
> >> >> I actually think that the customerrormessage attribute that has 
> >> >> been suggested is a decent solution too. [...]
> 
> For example, if I go to www.google.com and click on the "sign in" link 
> at the top, then without entering anything press the "sign in" button. 
> At this point the page displays a error message in red that says "Enter 
> your email address." [...]
> 
> In general it makes a lot of sense to want to display a different 
> message when the user has failed to enter a valid value in a field. 
> Clearly the user failed to enter what was requested the first time, and 
> so the context around the field was not enough for the user to enter 
> what was requested. Hence a more detailed description is appropriate.
> >
> > I don't understand how such an attribute would work. Take <input 
> > type=number> for example, with an explicit min, max, step, etc. How 
> > would you know what value to put in the attribute? There are going to 
> > be different needs when the control's value is too low, too high, not 
> > aligned to a step, missing, etc.
> 
> Consider the example above from googles login page. Here there are two 
> possible errors:
> 
> 1. The field is empty
> 2. The field doesn't contain an email address
> 
> In both cases the message "Enter your email address." seems appropriate. 
> And it seems better than what we as a browser could generate.

A text input field could have a number of error conditions:

   <label> Offer code:
    <input type=text maxlength=8 pattern="[a-z1-9]+" required>
   </label>

Suppose the code is printed as two groups of four characters, for example 
something like "1A2B 3C4D".

The user could have entered the code with the space (the site doesn't want 
the space). Or the user could have read an O as a 0 (the code never has 
any zeroes to avoid that). Or the user could have forgotten to enter the 
code. In each of these cases, I think you'd want a different message.


Anyway. I guess we can have a dedicated attribute that user agents can use 
to provide a message, rather than the current solution of just using the 
title="" attribute for pattern=""'s error message. If it's present, user 
agents could use it to replace or augment their message, and authors could 
make the message more specific by dynamically changing the attribute when 
during the 'invalid' event handler.

   <label> Offer code:
    <input type=text maxlength=8 pattern="[a-z1-9]+" required
           oninput="setCustomValidity(input.match(/0/) ?
                    'Codes contain no zeroes, only Os.' : '')"
           validitymessage="Enter the code without spaces.">
   </label>


If we add this, do you think it should be displayed with, instead of, or 
replaced by the setCustomValidity() message, when both are given?

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

From ajvincent at gmail.com  Wed Jul 27 20:34:59 2011
From: ajvincent at gmail.com (Alex Vincent)
Date: Wed, 27 Jul 2011 20:34:59 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Message-ID: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>

>
> In the last couple of weeks, I've been working with developers of CKEditor,
> TinyMCE, and Google Docs to come up with *new API for undo and redo*.
>

I'd like to take a look at this and be very closely involved in this
specification.  About a month ago, I wrote this:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031191.html

I've been working on my own prototype editor project for years (it may
replace Duke Nukem Forever as king of vaporware at the rate I'm going, but
I'm still working on it), and I've had some definite thoughts on undo
management.  API's like this interest me quite a bit.

Also see https://bugzilla.mozilla.org/show_bug.cgi?id=617532 - where Mozilla
is considering their own API proposals.

One use case I've envisioned is an undo popup menu, where each item of the
undo stack has an actual label to go with it, describing the transaction.
Then you could easily see how many items you wanted to go back!

I'd be happy to take this off-list, or keep it on-list, whatever you prefer.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

From jkorpela at cs.tut.fi  Wed Jul 27 20:37:09 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 28 Jul 2011 06:37:09 +0300
Subject: [whatwg] Form element invalid message
In-Reply-To: <Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
Message-ID: <4E30D965.6000704@cs.tut.fi>

28.07.2011 03:21, Ian Hickson wrote:

> A text input field could have a number of error conditions:

Indeed. Therefore it would be essential to be able to set the error 
message for _each_ check that a browser is supposed to do on the basis 
of HTML markup alone. If this is not possible, it is easier to authors 
to code all data checking in JavaScript. Setting the error messages is 
important both for context dependency and for localization (using the 
language of the browser's UI would be odd when it differs from the 
language of the page - if the page is in Greek and the instructions 
there are in Greek, I would expect the messages of the data error to be 
Greek, even when my browser speaks Hebrew).

> I guess we can have a dedicated attribute that user agents can use
> to provide a message, rather than the current solution of just using the
> title="" attribute for pattern=""'s error message.

The title="" attribute is generally supposed to contain an advisory 
title for an element, and deviating from this that way is very odd and 
confusing - especially since user agents may show its value in a tooltip 
or speak it out when entering the field.

A dedicated attribute is much better. In particular, it does not 
interfere with the existing use of existing attributes.

> If it's present, user
> agents could use it to replace or augment their message, and authors could
> make the message more specific by dynamically changing the attribute when
> during the 'invalid' event handler.
>
>     <label>  Offer code:
>      <input type=text maxlength=8 pattern="[a-z1-9]+" required
>             oninput="setCustomValidity(input.match(/0/) ?
>                      'Codes contain no zeroes, only Os.' : '')"
>             validitymessage="Enter the code without spaces.">
>     </label>

It would be more logical and descriptive to call it errormessage rather 
than validitymessage.

But the main problem is that attributes like maxlength, pattern, and 
required are supposed to provide some data validation in a simple manner 
that does not need to involve JavaScript and works even when it is 
disabled. To make them useful, it should be possible to set the error 
message for each of them separately in HTML.

I have no better solution than to use separate attributes, like 
maxlengtherror, patternerror, requirederror. This doesn't sound cool, 
but it would work and would be useful.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From rniwa at webkit.org  Wed Jul 27 21:54:06 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Wed, 27 Jul 2011 21:54:06 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>
References: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>
Message-ID: <CABNRm609JSHpx-N_DyUg8J_0ak-boM5bk2U0mj6sCq__OaeAFQ@mail.gmail.com>

On Wed, Jul 27, 2011 at 8:34 PM, Alex Vincent <ajvincent at gmail.com> wrote:
>
> I'd like to take a look at this and be very closely involved in this
> specification.  About a month ago, I wrote this:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031191.html


Oh, yes.  I do remember your post!  I think my proposal address most of your
concerns.

Also see https://bugzilla.mozilla.org/show_bug.cgi?id=617532 - where Mozilla
> is considering their own API proposals.
>

Jonas' last proposal is very similar to the one I proposed except there are
two types of transactions in my proposal - ManualTransaction and
ManagedTransaction.  The rationale for having two types of transactions is
to let the Web app pick whether UA or script should implement undo/redo.

One use case I've envisioned is an undo popup menu, where each item of the
> undo stack has an actual label to go with it, describing the transaction.
> Then you could easily see how many items you wanted to go back!
>

My proposal addresses this use case.  See "label" property on
AbstractTransaction.

- Ryosuke

From rniwa at webkit.org  Wed Jul 27 22:32:49 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Wed, 27 Jul 2011 22:32:49 -0700
Subject: [whatwg] [editing] Proposal: Undeletable elements within
	contentEditable
In-Reply-To: <CAKA+AxkjpvNt6VKPMVem2S3xkmEyy5vPXdS1JB2KbUTDhnxNWA@mail.gmail.com>
References: <490014A7-1BFC-4FD1-8737-9FDDF02EC741@elv1s.ru>
	<CAKA+AxkjpvNt6VKPMVem2S3xkmEyy5vPXdS1JB2KbUTDhnxNWA@mail.gmail.com>
Message-ID: <CABNRm60Xfs_oNriuJwN_FGK6_HeGjyqGaywjE7r4jvNO=KzDzA@mail.gmail.com>

On Wed, Jul 27, 2011 at 12:36 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> I'm very reluctant to add such things, because it adds corner cases
> that vastly complicate processing and allow tons more room for bugs.
> It means every single algorithm related to editing needs to be aware
> of the attribute and check for it before deleting anything.  This is
> already a big headache for contenteditable=false, which has tons of
> bugs in my algorithms and in browsers that I haven't even tried fixing
> systematically yet.
>

I concur with Aryeh here.  I would be strongly against adding such a feature
unless it's absolutely required to address some use case.  User agents are
barely coping with nested editability now and adding another layer of
complexity is very undesirable.

- Ryosuke

From hsivonen at iki.fi  Wed Jul 27 23:37:56 2011
From: hsivonen at iki.fi (Henri Sivonen)
Date: Thu, 28 Jul 2011 09:37:56 +0300
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA547099.10D90%aykut.sensoy@bild.de>
References: <CA547099.10D90%aykut.sensoy@bild.de>
Message-ID: <1311835076.2473.15.camel@shuttle>

On Tue, 2011-07-26 at 11:27 +0000, aykut.sensoy at bild.de wrote:
> http://www.google.com/support/news_pub/bin/answer.py?answer=93994
> 
> See Link above, Google says, that they provide "DC.date.issued", but this
> is also not part auf the whatwg metaextensions list.

It's part of the list now.

I wonder what possessed the Google News team to use dc.date.issued
instead of dc.issued or dcterms.issued.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/


From stefan.lk.hakansson at ericsson.com  Wed Jul 27 23:59:42 2011
From: stefan.lk.hakansson at ericsson.com (=?iso-8859-1?Q?Stefan_H=E5kansson_LK?=)
Date: Thu, 28 Jul 2011 08:59:42 +0200
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D616C389F15E@ESESSCMS0362.eemea.ericsson.se>

>On Tue, Jul 26, 2011 at 07:30, Ian Hickson <ian at hixie.ch> wrote:
>>
>>
>> > If you send two MediaStream objects constructed from the same
>> > LocalMediaStream over a PeerConnection there needs to be a way to
>> > separate them on the receiving side.
>>
>> What's the use case for sending the same feed twice?
>>
>
>There's no proper use case as such but the spec allows this.
The question is how serious a problem this is. If you want to fork, and make both (all) versions available at the peer, would you not transmit the full stream and fork at the receiving end for efficiency reasons? And if you really want to fork at the sender, one way to separate them is to use one PeerConnection per fork.

Stefan

From rniwa at webkit.org  Thu Jul 28 00:38:46 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Thu, 28 Jul 2011 00:38:46 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CAEZ8442askS4tPSjfMwM9pScEjiffKSODAWAh5mCb7D1kfpHXg@mail.gmail.com>
References: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>
	<CABNRm60cFn6D1gQDpD5tWLwMG8drDe78CNLGx+f2jdDsePynvw@mail.gmail.com>
	<CAEZ8442askS4tPSjfMwM9pScEjiffKSODAWAh5mCb7D1kfpHXg@mail.gmail.com>
Message-ID: <CABNRm60ydYXQNQSPOWFdNfj3Tq1Khs5NBocak9oUyhNgmiNZEg@mail.gmail.com>

On Wed, Jul 27, 2011 at 11:44 PM, Alex Vincent <ajvincent at gmail.com> wrote:
>
> I'm seeing one major hole in your interface:  you don't clearly specify how
> to *end* a transaction group.  This really matters for when I want to
> start a group manually, do a bunch of little things, and then end the group.
>

You can end a transaction group if you call transact or replace with
merge=false.

Personally, I think Jonas's API is better than yours, for its simplicity,
> but it doesn't allow for adding manual transactions in the middle of a
> grouped transaction. With his model, one explicitly calls out when a
> transaction should happen - there's no ambiguity, and when I don't want a
> transaction, I don't get one.  With your model, it's harder to tell, and
> very much either implementation-dependent or specification-dependent when a
> transaction happens natively and when it doesn't.  That makes it prone to
> bugginess / inconsistent behavior.


I don't quite get what you mean here.  Could you elaborate a little?

I'd personally take elements of both API's, myself:  add your
> ManualTransaction interface and
> UndoManager.applyManualStep(ManualTransaction) to Jonas's last UndoManager
> interface.


That was my initial thinking as well.  However,


> I also like the tendency of your API to make each transaction its own
> object, where we can store properties besides just the title on each
> transaction.


making all transactions objects will allow authors and UAs to
provide arbitrary properties on them.  Also, I wanted the transaction
objects be provided during undo, redo, and hypothetical edit action or new
transaction events.

- Ryosuke

From scott.gonzalez at gmail.com  Thu Jul 28 02:16:16 2011
From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=)
Date: Thu, 28 Jul 2011 05:16:16 -0400
Subject: [whatwg] Form element invalid message
In-Reply-To: <4E30D965.6000704@cs.tut.fi>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
Message-ID: <CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>

On Wed, Jul 27, 2011 at 11:37 PM, Jukka K. Korpela <jkorpela at cs.tut.fi>wrote:

> 28.07.2011 03:21, Ian Hickson wrote:
>
>  A text input field could have a number of error conditions:
>>
>
> Indeed. Therefore it would be essential to be able to set the error message
> for _each_ check that a browser is supposed to do on the basis of HTML
> markup alone. If this is not possible, it is easier to authors to code all
> data checking in JavaScript. Setting the error messages is important both
> for context dependency and for localization (using the language of the
> browser's UI would be odd when it differs from the language of the page - if
> the page is in Greek and the instructions there are in Greek, I would expect
> the messages of the data error to be Greek, even when my browser speaks
> Hebrew).


I agree that it's extremely important to be able to define error messages
per error condition, but it's not necessary to code all data checking in
JavaScript to achieve that today. You can simply code the error message by
letting the browser do the validation, then using the validity flags to set
your own message with setCustomValidity. Since this is possible today, it's
probably worth building a prototype that reads the custom error messages out
of data- attributes, e.g., data-patternerror. I have a feeling you'll still
end up with a few shortcomings because you won't have control over the order
in which the checks are done, so you won't be able to specify which error
message to show when there are multiple errors. Perhaps the best you could
do is provide another option which allows multiple errors to be displayed at
once.


>  I guess we can have a dedicated attribute that user agents can use
>> to provide a message, rather than the current solution of just using the
>> title="" attribute for pattern=""'s error message.
>>
>
> The title="" attribute is generally supposed to contain an advisory title
> for an element, and deviating from this that way is very odd and confusing -
> especially since user agents may show its value in a tooltip or speak it out
> when entering the field.
>

I'd prefer not using the title attribute as well. In many cases where a
title attribute is already specified it won't make sense as an error
message. In cases where it will get specified specifically for pattern error
messages, authors will almost definitely use wording that doesn't make sense
for the title.

A dedicated attribute is much better. In particular, it does not interfere
> with the existing use of existing attributes.
>
>
>  If it's present, user
>> agents could use it to replace or augment their message, and authors could
>> make the message more specific by dynamically changing the attribute when
>> during the 'invalid' event handler.
>>
>>    <label>  Offer code:
>>     <input type=text maxlength=8 pattern="[a-z1-9]+" required
>>            oninput="setCustomValidity(**input.match(/0/) ?
>>                     'Codes contain no zeroes, only Os.' : '')"
>>            validitymessage="Enter the code without spaces.">
>>    </label>
>>
>
> It would be more logical and descriptive to call it errormessage rather
> than validitymessage.
>
> But the main problem is that attributes like maxlength, pattern, and
> required are supposed to provide some data validation in a simple manner
> that does not need to involve JavaScript and works even when it is disabled.
> To make them useful, it should be possible to set the error message for each
> of them separately in HTML.
>
> I have no better solution than to use separate attributes, like
> maxlengtherror, patternerror, requirederror. This doesn't sound cool, but it
> would work and would be useful.
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>

From jkorpela at cs.tut.fi  Thu Jul 28 03:25:40 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 28 Jul 2011 13:25:40 +0300
Subject: [whatwg] Form element invalid message
In-Reply-To: <CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
	<CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
Message-ID: <4E313924.7060507@cs.tut.fi>

28.07.2011 12:16, Scott Gonz?lez wrote:

> I agree that it's extremely important to be able to define error
> messages per error condition, but it's not necessary to code all data
> checking in JavaScript to achieve that today.

It's not, but if you cannot set the error messages in HTML, what's the 
point? Doing everything in JavaScript is simpler, especially because you 
should anyway duplicate the checks - for example, using JavaScript to 
get the pattern attribute value and run the check in it, to deal with 
the many situations where the user has JavaScript enabled and the 
browser does not support the pattern attribute (but still includes its 
value into the DOM).

> You can simply code the
> error message by letting the browser do the validation, then using the
> validity flags to set your own message with setCustomValidity.

Pardon? You would let the browser run the checks specified in HTML, then 
check the flags and turn an error to a custom error for which you can 
set the error message. This sounds like more complicated than doing it 
all in JavaScript, where you can directly do whatever error processing 
needs to be done. To make the HTML way a feasible option, the spec 
should define an easy way to set the error message(s) directly.

>  I have a feeling you'll still end up with a few
> shortcomings because you won't have control over the order in which the
> checks are done, so you won't be able to specify which error message to
> show when there are multiple errors.

Yes that would be a problem too, but a tolerable one. Besides, I guess 
the spec could say that the checks are carried out in the order in which 
the attributes are specified (though this admittedly deviates from the 
DOM-centric approach), and it could have yet another Boolean attribute 
that specifies whether all checks are carried out or the first failure 
aborts the processing. But more realistically, and more logically 
DOM-wise, the spec could simply define the order (e.g., required, 
maxlength, pattern) and specify that when a check fails, an error 
message is issued and further processing is suppressed.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From scott.gonzalez at gmail.com  Thu Jul 28 03:46:33 2011
From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=)
Date: Thu, 28 Jul 2011 06:46:33 -0400
Subject: [whatwg] Form element invalid message
In-Reply-To: <4E313924.7060507@cs.tut.fi>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
	<CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
	<4E313924.7060507@cs.tut.fi>
Message-ID: <CAO8i3idMLAZ37GK=U4+oVznDpasCGZ-55ioptdNQcD742W4xXw@mail.gmail.com>

2011/7/28 Jukka K. Korpela <jkorpela at cs.tut.fi>

> 28.07.2011 12:16, Scott Gonz?lez wrote:
>
>  I agree that it's extremely important to be able to define error
>> messages per error condition, but it's not necessary to code all data
>> checking in JavaScript to achieve that today.
>>
>
> It's not, but if you cannot set the error messages in HTML, what's the
> point? Doing everything in JavaScript is simpler, especially because you
> should anyway duplicate the checks - for example, using JavaScript to get
> the pattern attribute value and run the check in it, to deal with the many
> situations where the user has JavaScript enabled and the browser does not
> support the pattern attribute (but still includes its value into the DOM).


Doing everything in JavaScript is easier for developers, but an easily
configurable JavaScript plugin is easier for a very large percentage of web
content authors. A first pass might look something like:

$( "#age" ).validation({
    required: "You must enter an email address.",
    min: "You must be at least 13 to post nonsense on the web."
});

As for duplicating the checks anyway, I completely agree and I personally
just use JavaScript anyway. As one of the development leads for jQuery UI, I
can tell you that I have mixed feelings about all of the new features. As a
developer, I want to leverage as much of the semantics and information as I
can, but I also want complete control over the results of providing those
semantics and information. This generally means we want the attributes
without any of their actual functionality, which is a shame.


>  You can simply code the
>> error message by letting the browser do the validation, then using the
>> validity flags to set your own message with setCustomValidity.
>>
>
> Pardon? You would let the browser run the checks specified in HTML, then
> check the flags and turn an error to a custom error for which you can set
> the error message. This sounds like more complicated than doing it all in
> JavaScript, where you can directly do whatever error processing needs to be
> done. To make the HTML way a feasible option, the spec should define an easy
> way to set the error message(s) directly.


This is purely a suggestion of how to implement what I've described above.

There are essentially three choices (this applies to most new markup-driven
features):
1) Provide the information in the appropriate attributes and let the browser
do its thing.
2) Provide the information in a script and do everything via scripting.
3) Provide the information in the appropriate attributes, but handle them
via scripting.

#1 will never be as flexible as #3. #2 is a decent compromise and can be
made more flexible by allowing additional configuration via scripts. I think
the spec needs to make #1 as good as it can, but also do what it can to
encourage #2 over #3 where possible/reasonable.


>   I have a feeling you'll still end up with a few
>> shortcomings because you won't have control over the order in which the
>> checks are done, so you won't be able to specify which error message to
>> show when there are multiple errors.
>>
>
> Yes that would be a problem too, but a tolerable one. Besides, I guess the
> spec could say that the checks are carried out in the order in which the
> attributes are specified (though this admittedly deviates from the
> DOM-centric approach), and it could have yet another Boolean attribute that
> specifies whether all checks are carried out or the first failure aborts the
> processing. But more realistically, and more logically DOM-wise, the spec
> could simply define the order (e.g., required, maxlength, pattern) and
> specify that when a check fails, an error message is issued and further
> processing is suppressed.
>
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>

From shadow2531 at gmail.com  Thu Jul 28 04:06:25 2011
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Thu, 28 Jul 2011 07:06:25 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
 implementer feedback
In-Reply-To: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
Message-ID: <op.vzbs4rrf1ejg13@vertiform346>

Thanks for working on this. Much appreciated!

A few things so far:

At the end of section 4, there's:

> the state of insertOrderedList and insertOrderedList might be true both  
> before and after calling

Is one of those supposed to be insertUnorderedList?

At the beginning of section 5, there's:

> An editing host is a node that is either an Element with a  
> contenteditable attribute set to the true state, or the Element child of  
> a Document whose designMode is enabled.

What does "Element child" refer to specifically in the latter? Is it the  
HTML body element or is that implementation-specific?

Still in section 5:

> A collapsed line break is a br that begins a line box which has nothing  
> else in it, and therefore has zero height.
>
> An extraneous line break is a br that has no visual effect, in that  
> removing it from the DOM would not change layout, except that a br that  
> is the sole child of an li is not extraneous.
>Is this a good definition at all?

Don't really have much opinion on the names or the definition.

Which one refers to a <br> that acts like a placeholder for a line (so the  
line is selectable) where the <br> disappears once the user starts editing  
that line or closes the paragraph?

At the end of section 5:

> When the user agent is instructed to run a particular method, it must  
> follow the steps defined for that method in the appropriate  
> specification, not act as though the method had actually been called  
> from JavaScript. In particular, if the author has overridden the method  
> with a custom method, the standard method must be run rather than the  
> custom one.

Is this saying that doing something like:

HTMLDocument.prototype.execCommand = function(a, b, c) {
     // stuff
};

, will have no effect or should throw an error or something?

If so, is this just matching what browsers do now or just something you  
think is a good thing to prevent?

In section 6.1 with:

> To set the tag name of an Element element to new name:
>
> 1. If element is an HTML element with local name equal to new name,  
> return element.
>
> 2. If element's parent is null, return element.
>
> 3. Let replacement element be the result of calling createElement(new  
> name) on the ownerDocument of element.
>
> 4. Insert replacement element into element's parent immediately before  
> element.
>
> 5. Copy all attributes of element to replacement element, in order.
>
> 6. While element has children, append the first child of element as the  
> last child of replacement element, preserving ranges.
>
> 7. Remove element from its parent.
>
> 8. Return replacement element.

I pretty much translate that as:

var replacementElement = document.createElement("differentTagName");
parent.insertBefore(replacementElement, element);
for (var i = 0; i < element.attributes.length; ++i) {
     replacementElement.setAttribute(element.attributes[i].name,  
element.attributes[i].value);
}
while (element.hasChildNodes()) {
     replacementElement.appendChild(element.removeChild(element.lastChild));
}
parent.removeChild(element);

That seems to be removing attributes and nodes from one element and  
appending them to another while they're both being displayed in the parent.

Do you intend for that to be strictly done like that or is doing it a  
different way (like copying to the replacementElement in the DOM and then  
doing a replace) allowed as long as it gives the same end result? Or, will  
that mess up the range preservation?

-- 
Michael

From timeless at gmail.com  Thu Jul 28 06:48:39 2011
From: timeless at gmail.com (timeless)
Date: Thu, 28 Jul 2011 09:48:39 -0400
Subject: [whatwg] Form element invalid message
In-Reply-To: <CAO8i3idMLAZ37GK=U4+oVznDpasCGZ-55ioptdNQcD742W4xXw@mail.gmail.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
	<CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
	<4E313924.7060507@cs.tut.fi>
	<CAO8i3idMLAZ37GK=U4+oVznDpasCGZ-55ioptdNQcD742W4xXw@mail.gmail.com>
Message-ID: <CAACrNNf42uenUSruuOy7nZu9pOtFWBjBPOO+LA9hXo-CE+LWwQ@mail.gmail.com>

Your 13 example is a good argument against splitting between markup
and script. If the minimum value is updated in the html but not the
js, you get confused users. - I've seen the results of letting logic
get out of sync from error reporting, it isn't pretty.

On 7/28/11, Scott Gonz?lez <scott.gonzalez at gmail.com> wrote:
> 2011/7/28 Jukka K. Korpela <jkorpela at cs.tut.fi>
>
>> 28.07.2011 12:16, Scott Gonz?lez wrote:
>>
>>  I agree that it's extremely important to be able to define error
>>> messages per error condition, but it's not necessary to code all data
>>> checking in JavaScript to achieve that today.
>>>
>>
>> It's not, but if you cannot set the error messages in HTML, what's the
>> point? Doing everything in JavaScript is simpler, especially because you
>> should anyway duplicate the checks - for example, using JavaScript to get
>> the pattern attribute value and run the check in it, to deal with the many
>> situations where the user has JavaScript enabled and the browser does not
>> support the pattern attribute (but still includes its value into the DOM).
>
>
> Doing everything in JavaScript is easier for developers, but an easily
> configurable JavaScript plugin is easier for a very large percentage of web
> content authors. A first pass might look something like:
>
> $( "#age" ).validation({
>     required: "You must enter an email address.",
>     min: "You must be at least 13 to post nonsense on the web."
> });
>
> As for duplicating the checks anyway, I completely agree and I personally
> just use JavaScript anyway. As one of the development leads for jQuery UI, I
> can tell you that I have mixed feelings about all of the new features. As a
> developer, I want to leverage as much of the semantics and information as I
> can, but I also want complete control over the results of providing those
> semantics and information. This generally means we want the attributes
> without any of their actual functionality, which is a shame.
>
>
>>  You can simply code the
>>> error message by letting the browser do the validation, then using the
>>> validity flags to set your own message with setCustomValidity.
>>>
>>
>> Pardon? You would let the browser run the checks specified in HTML, then
>> check the flags and turn an error to a custom error for which you can set
>> the error message. This sounds like more complicated than doing it all in
>> JavaScript, where you can directly do whatever error processing needs to
>> be
>> done. To make the HTML way a feasible option, the spec should define an
>> easy
>> way to set the error message(s) directly.
>
>
> This is purely a suggestion of how to implement what I've described above.
>
> There are essentially three choices (this applies to most new markup-driven
> features):
> 1) Provide the information in the appropriate attributes and let the browser
> do its thing.
> 2) Provide the information in a script and do everything via scripting.
> 3) Provide the information in the appropriate attributes, but handle them
> via scripting.
>
> #1 will never be as flexible as #3. #2 is a decent compromise and can be
> made more flexible by allowing additional configuration via scripts. I think
> the spec needs to make #1 as good as it can, but also do what it can to
> encourage #2 over #3 where possible/reasonable.
>
>
>>   I have a feeling you'll still end up with a few
>>> shortcomings because you won't have control over the order in which the
>>> checks are done, so you won't be able to specify which error message to
>>> show when there are multiple errors.
>>>
>>
>> Yes that would be a problem too, but a tolerable one. Besides, I guess the
>> spec could say that the checks are carried out in the order in which the
>> attributes are specified (though this admittedly deviates from the
>> DOM-centric approach), and it could have yet another Boolean attribute
>> that
>> specifies whether all checks are carried out or the first failure aborts
>> the
>> processing. But more realistically, and more logically DOM-wise, the spec
>> could simply define the order (e.g., required, maxlength, pattern) and
>> specify that when a check fails, an error message is issued and further
>> processing is suppressed.
>>
>>
>> --
>> Yucca,
>> http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>>
>

-- 
Sent from my mobile device

From roblevin at hotmail.com  Thu Jul 28 09:25:02 2011
From: roblevin at hotmail.com (Rob Levin)
Date: Thu, 28 Jul 2011 17:25:02 +0100
Subject: [whatwg] CSP feedback
Message-ID: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>

Hello,

 

I posted this to the whatwg forums last week, and was advised to post to the
mailing list.  Here goes.

 

 

I've been thinking for some time about XSS attacks and ways to mitigate
them, and two observations struck me:

 

(1) XSS attacks nearly always occur in the <body> block of a html document,
and not the <head> block. This is because the attack surface of the <body>
is generally larger than the <head> block, and user-generated content is
usually (but not always) placed in the <body> of a document.

 

(2) With the rise of Javascript frameworks like JQuery, it is becoming best
practice to separate the code from the content. All legitimate code can be
placed in the <head> block without too much effort, for many sites.

 

So I came to the conclusion that adding a simple html mechanism to allow an
author to tell a user-agent that scripts should only be executed from the
<head> block would give a powerful weapon to authors to prevent XSS
exploits. Authors would write their own scripts, include them in their
<head> block, and instruct the user-agent that any scripts in the <body>
block should be ignored. This would be easy implement on the user-agent side
and easy to use on the author side. And it would degrade gracefully in older
user-agents.

 

Excited with this idea, I set out to find the right people to contact to get
this moving, which eventually led me to WHATWG. I did some research on the
mailing list archives, and realised that other people have had my ideas
first (many years ago), and are well on the way to implementing them. Oh
well, never mind! So I've read about sandboxing on IFrames, and the CSP
unofficial draft, and clearly these efforts are solving bigger problems in a
more comprehensive way, which largely encompass my ideas. Well done to all
involved on these major efforts.

 

But... there are a few things that strike me.

 

 

Firstly, whatever is done to mitigate XSS should be really really simple to
use and understand by authors. I'm not sure that CSP hits the sweet spot
between usability and security; I am worried it is going to be too difficult
to use for the mass market, and hence fail in part of its mission.

 

For me, the instruction to inform a user-agent that a script should be
ignored in the body should look something like:

 

<head>

<security request="NoBodyScripts"></security>

</head>

 

 

this would be intuitive to most authors, and would stop an awful lot of
attacks.

 

How can I achieve the same effect with CSP? I may have it wrong, but the
only way I can see to implement this with CSP would be to do something like:

 

<head>

<meta http-equiv="X-Content-Security-Policy" script-nonce="[a strong dynamic
random token]">

</head>

 

...and include this nonce with every script on the page.

 

 

Secondly, creating and implementing a protocol such as CSP is only part of
the story to really eliminate XSS in the wild. The social aspect needs to be
thought through. I think the best way to encourage authors to use it would
be to show some consistent visual feedback given to users that their site
has implemented "Web Security" and that the user-agent is enforcing it. This
would then start a virtuous feedback cycle where more sites implement the
security, putting pressure on more user-agents to implement it etc.

 

Users are already used to a padlock symbol showing a secure socket
connection; a similar common symbol could be recommended to user-agents to
display to users when CSP is invoked. This should be part of the spec, in my
opinion.

 

thanks,

-rob


From rob at drunkenfist.com  Thu Jul 28 09:32:57 2011
From: rob at drunkenfist.com (Rob Larsen)
Date: Thu, 28 Jul 2011 12:32:57 -0400
Subject: [whatwg] CSP feedback
In-Reply-To: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>
References: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>
Message-ID: <36419b00351c9485afcbdd1cc20dfb51.squirrel@QuestMail.FutureQuest.net>

> Hello,
> (2) With the rise of Javascript frameworks like JQuery, it is becoming
> best
> practice to separate the code from the content. All legitimate code can be
> placed in the <head> block without too much effort, for many sites.

In practice many developers prefer to place almost all script tags right
before the closing body tag

http://developer.yahoo.com/performance/rules.html#js_bottom


From Simetrical+w3c at gmail.com  Thu Jul 28 11:15:53 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 28 Jul 2011 14:15:53 -0400
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAOYSAj0xN-ZnzSB0ogkks-NPM4-R4Y-XHV63ySkZBuoLVA8+hA@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
	<CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
	<CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>
	<CAOYSAj0xN-ZnzSB0ogkks-NPM4-R4Y-XHV63ySkZBuoLVA8+hA@mail.gmail.com>
Message-ID: <CAKA+Ax=s_gYLu=7F1h5qt1epif-JObZJV4A4NocFGr0weRH+6Q@mail.gmail.com>

On Wed, Jul 27, 2011 at 6:55 PM, Tim Down <timdown at gmail.com> wrote:
> There's also the perennial problem of dealing with non-visible text
> (c.f. Selection.toString(), innerText), which some browsers handle (a
> quick tests suggests WebKit searches non-visible text and Firefox
> doesn't).

True.  Of course, that's a rabbit hole I've mostly managed to avoid
going down so far.

> Also, don't forget that you're in the habit of writing this
> sort of code. Knocking that kind of code out quickly is beyond what a
> large percentage of web developers are capable of.

Right, but that's why we have libraries like jQuery.  If it's in
demand and it can be done in JavaScript, libraries can do it, and then
we don't want to make browsers do it too unless either it's an
extremely common use-case or they can do it better somehow.  Or they
have to for compat.

> There is no reason why your algorithms can't
> work on non-editable nodes, so why require the user to change such a
> fundamental property of the DOM (even temporarily)? I'd prefer an
> alternative mechanism for specifying whether a command should apply to
> only editable content that is part of the editing API. In my
> execCommand implementation, it's specified as a property of an options
> object passed to execCommand(). If that's not an option, another
> command could be used, similar to the styleWithCSS command, to switch
> between modes. applyToNonEditable, or something.

Having a behavior switch like styleWithCSS is a possible option.  The
problem I have with that kind of switch is that it breaks down if two
scripts on the same page are both relying on the switch being a
particular value: you can't rely on the current state of the switch
unless you run it before every single command execution.  I saw at
least one execCommand()-using library that did exactly that, running
styleWithCSS *and* useCSS before every single command.

Defining an extra argument to execCommand() would be possible, but I'm
leery about it, because it already has one useless boolean argument
that no browser but IE supports.  What we could consider is
overloading it with a form like execCommand(command, options), where
options is an object, so you could do execCommand("forecolor", {value:
"red", styleWithCSS: false, restrictToEditable: true}) or something.
But it's awkward to have to specify the same options all the time, and
the syntax is incompatible and doesn't fall back gracefully.

It's definitely worth considering at some point, though.  I added a
TODO: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=aff4441e

From Simetrical+w3c at gmail.com  Thu Jul 28 13:17:34 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 28 Jul 2011 16:17:34 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
Message-ID: <CAKA+Axm4Ry1Ahp_mZE-86-6fKCha2pgBgP=pSw3Zgc5_dBFB6A@mail.gmail.com>

Thanks to both of you for the feedback!

On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> WebKit treats any font-weight above or equal to 600 as bold because that's
> what user sees, and boldness is a binary concept in execCommand; Firefox 5
> appears to do the same.

Yes, bold is not a big problem.  If you look at "the bold command"
section, it explicitly defines the values "bold", "600", "700", "800",
or "900" as corresponding to "on", so it's simple string comparison.
The bigger problem is things like colors and sizes, where there are
lots of units that are related in complicated ways.

What I'd really like to do is have CSSOM define a reliable way of
uniquely serializing CSS values, and then say that two values are
equal if they serialize to the same thing.  But I guess for now I
should just make up my own definition.  For most things it's pretty
straightforward in principle, but it still needs to be specced.

> WebKit compares colors in rgb/rgba format; e.g. red is first parsed as
> rgb(255, 0, 0). ?Firefox 5 seems to does the same as well.

Yeah, that's the obvious way to do it.  If I have to write the
definition for this, I guess I'll just say two CSS colors are equal if
their R/G/B/A channels are all equal.

> WebKit compares font sizes in legacy font size used in font element;
> See?CSSStyleSelector::legacyFontSize or?legacyFontSizeFromCSSValue in
> EditingStyle.cpp

I more or less reverse-engineered that to define
queryCommandValue("fontSize") -- translate the computed font-size to
pixels, then round to the nearest corresponding legacy font size.
Other browsers do different things that are less useful.  But there
are cases when I want to compare CSS values for equality more
precisely.  For instance, per spec, if you have

<span style=font-size:large>foo[bar]baz</span>

and run execCommand("fontSize", false, "4"), it does nothing.  WebKit
seems to break up the span and add a new span or font element, but
this adds extra clutter.  However, if you have

<span style=font-size:18px>foo[bar]baz</span>

then the spec says to break up the span, because 18px != large, even
though queryCommandValue() says the same thing for both.

> Throwing SYNTAX_ERR might cause a backward compatibility issue because the
> UAs don't throw an error now. ?We can probably throwing console messages
> first to give authors some grace period to transition.

Yeah, this was a bad idea.  The only case where anyone throws
exceptions for bad values is Opera with formatBlock.  I've removed
this:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=ff9f4629

Don't know why I added it in the first place.

> For font element vs. span with style issue, we could add another boolean
> flag that forces UAs to toggle font-element; i.e. add StyleWithFont command.

I guess.

> 3.2: Prefix "webkit-" doesn't seem natural given all editing commands use
> Camel case. ?Maybe Ms, Gecko, WebKit and Opera? ?e.g. WebKitFontSizeDelta.
> ?But again this might cause a backward compatibility because we do implement
> few editing commands that are not in the spec and they are not prefixed.

I copied this from HTML5, and I think at least Opera has some commands
with this syntax, but you're right it doesn't make much sense.  I've
changed it: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=e9369d6c

> 3.3: The return value of queryCommandEnable depends on beforecut,
> beforecopy, and beforepaste events and selection state in WebKit; WebKit
> returns false if default actions are prevented in those events or selection
> is not a range. ?Firefox 5 appears to do the same for selection but doesn't
> seem to fire beforecut, beforecopy, and beforepaste.

How does WebKit know if those events will be prevented or not, without
running the handlers?  If the page runs queryCommandEnabled(), nothing
actually happened, so surely WebKit doesn't fire any events?  Also,
are you only talking about the cut/copy/paste commands, or other
commands too?

On Thu, Jul 28, 2011 at 7:06 AM, Michael A. Puls II
<shadow2531 at gmail.com> wrote:
> At the end of section 4, there's:
>
>> the state of insertOrderedList and insertOrderedList might be true both
>> before and after calling
>
> Is one of those supposed to be insertUnorderedList?

Yeah, thanks.  Fixed:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=eb346d01

> At the beginning of section 5, there's:
>
>> An editing host is a node that is either an Element with a contenteditable
>> attribute set to the true state, or the Element child of a Document whose
>> designMode is enabled.
>
> What does "Element child" refer to specifically in the latter? Is it the
> HTML body element or is that implementation-specific?

It just means what the literal words imply: any Element that is the
child of a Document whose designMode is enabled.  The Nodes model
<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#nodes-model>
implies that any Document will always have either zero or one child
that's an Element.  If one exists, it will be returned by
document.documentElement.  For HTML documents, the Element child of a
Document is generally <html>, although you could change it with DOM
manipulation if you really wanted.

(I noticed that the word "child" wasn't linked here, and I fixed that,
although I don't think that's what caused your confusion.)

> Still in section 5:
>
>> A collapsed line break is a br that begins a line box which has nothing
>> else in it, and therefore has zero height.
>>
>> An extraneous line break is a br that has no visual effect, in that
>> removing it from the DOM would not change layout, except that a br that is
>> the sole child of an li is not extraneous.
>> Is this a good definition at all?
>
> Don't really have much opinion on the names or the definition.
>
> Which one refers to a <br> that acts like a placeholder for a line (so the
> line is selectable) where the <br> disappears once the user starts editing
> that line or closes the paragraph?

That would be "collapsed block prop", which is admittedly a terrible
term whose definition is confusing.  I added a note to clarify what
the intent is:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=6e16b641

> At the end of section 5:
>
>> When the user agent is instructed to run a particular method, it must
>> follow the steps defined for that method in the appropriate specification,
>> not act as though the method had actually been called from JavaScript. In
>> particular, if the author has overridden the method with a custom method,
>> the standard method must be run rather than the custom one.
>
> Is this saying that doing something like:
>
> HTMLDocument.prototype.execCommand = function(a, b, c) {
> ? ?// stuff
> };
>
> , will have no effect or should throw an error or something?

It's saying that even if the author does that, when the spec says to
do execCommand("foo"), it has to use the real implementation and not
the author-overridden one.  For instance, I often say things like "Let
replacement element be the result of calling createElement(new name)
on the ownerDocument of element", so this means that even if you
replace createElement(), it will still act like it called the original
unreplaced one.  DOM Range uses similar terminology.  An alternative
approach would be to make sure there are unambiguous ways of saying
the same thing in prose, but that doesn't scale well in my experience.

I tried to clarify:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=2ddd02d2

Does that seem better?

> If so, is this just matching what browsers do now or just something you
> think is a good thing to prevent?

This is what browsers do now.  I'm just clarifying what the spec
means, not requiring specific author-visible behavior.

> I pretty much translate that as:
>
> var replacementElement = document.createElement("differentTagName");
> parent.insertBefore(replacementElement, element);
> for (var i = 0; i < element.attributes.length; ++i) {
> ? ?replacementElement.setAttribute(element.attributes[i].name,
> element.attributes[i].value);
> }
> while (element.hasChildNodes()) {
> ? ?replacementElement.appendChild(element.removeChild(element.lastChild));
> }
> parent.removeChild(element);
>
> That seems to be removing attributes and nodes from one element and
> appending them to another while they're both being displayed in the parent.

Essentially, yes, but you missed the "preserving ranges" part.  You
can see my implementation here:

http://aryeh.name/gitweb.cgi?p=editing;a=blob;f=implementation.js;h=8d3a9856

Note that browsers don't repaint until the event loop spins, so the
intermediate state here should never be visible to the user.  Opera
currently repaints sometimes event between event loop spins, but
that's probably a bug, and anyway I doubt they'll repaint in the
middle of an execCommand() execution.

> Do you intend for that to be strictly done like that or is doing it a
> different way (like copying to the replacementElement in the DOM and then
> doing a replace) allowed as long as it gives the same end result? Or, will
> that mess up the range preservation?

The way I've currently specced it, it has to be done in that order or
else the "preserving ranges" part won't work.  It would be possible
for me to rework that if necessary.  UAs can always do whatever they
want as long as the results are black-box identical, of course.

From rniwa at webkit.org  Thu Jul 28 13:31:55 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Thu, 28 Jul 2011 13:31:55 -0700
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CAKA+Axm4Ry1Ahp_mZE-86-6fKCha2pgBgP=pSw3Zgc5_dBFB6A@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
	<CAKA+Axm4Ry1Ahp_mZE-86-6fKCha2pgBgP=pSw3Zgc5_dBFB6A@mail.gmail.com>
Message-ID: <CABNRm62uCT5KrkwzLT5aXX5V4WdAjG6hLyiyqVnkVRP6fuD+mw@mail.gmail.com>

On Thu, Jul 28, 2011 at 1:17 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:
>
>  > 3.3: The return value of queryCommandEnable depends on beforecut,
> > beforecopy, and beforepaste events and selection state in WebKit; WebKit
> > returns false if default actions are prevented in those events or
> selection
> > is not a range.  Firefox 5 appears to do the same for selection but
> doesn't
> > seem to fire beforecut, beforecopy, and beforepaste.
>
> How does WebKit know if those events will be prevented or not, without
> running the handlers?  If the page runs queryCommandEnabled(), nothing
> actually happened, so surely WebKit doesn't fire any events?  Also,
> are you only talking about the cut/copy/paste commands, or other
> commands too?
>

WebKit fires those events :(  I don't know why we do that.  I think it's a
WebKit bug but I'm just pointing that out in the case there are some
websites out there that depends on this quirky behavior.  Just
cut/copy/paste for now as far as I know.

- Ryosuke

From roblevin at hotmail.com  Thu Jul 28 14:51:19 2011
From: roblevin at hotmail.com (Rob Levin)
Date: Thu, 28 Jul 2011 22:51:19 +0100
Subject: [whatwg] CSP feedback
In-Reply-To: <36419b00351c9485afcbdd1cc20dfb51.squirrel@QuestMail.FutureQuest.net>
References: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>
	<36419b00351c9485afcbdd1cc20dfb51.squirrel@QuestMail.FutureQuest.net>
Message-ID: <COL122-DS254673C4DE52C23AB0959BC8340@phx.gbl>

> > (2) With the rise of Javascript frameworks like JQuery, it is becoming 
> > best practice to separate the code from the content. All legitimate 
> > code can be placed in the <head> block without too much effort, for 
> > many sites.

> In practice many developers prefer to place almost all script tags right
before the closing body tag
>
> http://developer.yahoo.com/performance/rules.html#js_bottom

Yes, I agree.  There can be a performance optimisation from placing scripts
at the bottom of the page.  In the absence of any other factors, this has
been the primary driver of advice where to place the scripts.  

But from a security point of view, mixing the scripts and the content is
quite dangerous - it gives malicious content more opportunities to sneak in
a live malicious script.  If placing scripts only in the head block could
give a simple and significant security enhancement, then the best-practice
advice could quickly change.  And hopefully with modern browsers the same
performance benefits can now be realised using scripts in the head block,
with the defer and/or async attribute

http://stackoverflow.com/questions/3952009/defer-attribute-chrome



From annevk at opera.com  Thu Jul 28 15:05:37 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 28 Jul 2011 15:05:37 -0700
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
References: <4DDFF77F.9050605@mit.edu>
	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>
	<4DFB8783.7070802@mit.edu> <4DFB8C23.7070808@mit.edu>
	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>
	<4DFB9F2D.3070404@mit.edu>
	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
Message-ID: <op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>

On Fri, 17 Jun 2011 11:57:20 -0700, Ian Hickson <ian at hixie.ch> wrote:
> I'm all in favour of making this generic across all vocabularies. I'm
> happy to work with Anne and Ms2ger to move all the HTML and SVG event
> handler attributes (does MathML have any?) to Element. It would not be an
> uncontroversial change.

So the SVG WG discussed this and they would like this as well. (They  
basically want the same behavior as HTML has here and converge as much as  
possible.) The change to the current mechanism required for SVG is to  
expose an "evt" variable somehow in scope of the Function.

Now does it make sense to have the IDL attributes on Element but not have  
the content attributes on all elements? That would mean it still depends  
on the markup language what you can use as on* attributes which is not  
very straightforward.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From ian at hixie.ch  Thu Jul 28 15:22:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 28 Jul 2011 22:22:10 +0000 (UTC)
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
References: <4DDFF77F.9050605@mit.edu>
	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>
	<4DFB8783.7070802@mit.edu> <4DFB8C23.7070808@mit.edu>
	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>
	<4DFB9F2D.3070404@mit.edu>
	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
Message-ID: <Pine.LNX.4.64.1107282221080.3775@ps20323.dreamhostps.com>

On Thu, 28 Jul 2011, Anne van Kesteren wrote:
> On Fri, 17 Jun 2011 11:57:20 -0700, Ian Hickson <ian at hixie.ch> wrote:
> > I'm all in favour of making this generic across all vocabularies. I'm 
> > happy to work with Anne and Ms2ger to move all the HTML and SVG event 
> > handler attributes (does MathML have any?) to Element. It would not be 
> > an uncontroversial change.
> 
> So the SVG WG discussed this and they would like this as well. (They 
> basically want the same behavior as HTML has here and converge as much 
> as possible.) The change to the current mechanism required for SVG is to 
> expose an "evt" variable somehow in scope of the Function.
> 
> Now does it make sense to have the IDL attributes on Element but not 
> have the content attributes on all elements? That would mean it still 
> depends on the markup language what you can use as on* attributes which 
> is not very straightforward.

As far as HTML goes, I'd suggest that we'd have a 1:1 mapping of IDL to 
content attribute, and have them be the same for every element (except 
<body>, <frameset>, and <marquee>).

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

From chuck at jumis.com  Thu Jul 28 16:06:50 2011
From: chuck at jumis.com (Charles Pritchard)
Date: Thu, 28 Jul 2011 16:06:50 -0700
Subject: [whatwg] Canvas fallback content: IAccessible accLocation
Message-ID: <4E31EB8A.5030205@jumis.com>

Tab,

I do understand your position when you recommend SVG for UI and the 
vendor-level support that will/can evolve from markup
as well as [standard] retained-mode semantics.
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0184.html


My position evolved from experience.
I need a method for canvas to share path data with the browser 
accessibility API:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0187.html

I'd prefer to call it setClickableRegion(element); and I'd prefer that 
it delegates mouse events
to the canvas subdom, as well as sharing region info with the AT. I 
require it to fill out IAccessible accLocation,
the rest is just up to the editor / WG and good practices.

You have opposed the addition of such a method -- the method would 
essentially bring image map-level accessibility data to canvas uis;
currently, there is no way to inform the accessibility tree with such 
information -- image maps were ruled out, and focus management
only applies to the actively focused element.


I'm approaching this issue having put into practice, in as many ways as 
I could approach,
the WHATWG specs in building a "Web Application". The WHATWG picked up 
Canvas early,
and I feel an obligation to contribute: SVG implementations in 2007 were 
not workable;
nor was VML -- work by the WHATWG truly helped us move forward.

Thanks to large investments, RIM and Microsoft pushed SVG support 
forward in two
major browser families.  Thanks to other investments, ARIA support was 
also greatly
enhanced across browser families and ATs. Mozilla has had brought, 
though uneven,
support for SVG for some time.

So, in 2011, we have a much improved landscape for SVG, as well as a full
landscape for Canvas. And yes, I started code bases prior to 2011, when 
Canvas
was the sole interface I could use to target the market; VML too slow 
and inflexible,
SVG mostly unimplemented.

The formalism required by SVG is expensive; just as the formalism 
required by ARIA
is costly. We're supporting both, because SVG output ensures a 
standards-based
interoperable file format serialization and ARIA ensures standards-based 
interoperable
ui serialization and interaction.

The costs of building an SVG 1.x implementation are expensive, relative 
to Canvas. In the order
of a magnitude. SVG Tiny is less costly, though still more so than 
Canvas; and the
design decisions made by an SVG Tiny vendor are not something that can 
be worked-around
by additional javascript coding. As such, we are much more beholden to 
vendors
with SVG than we are with Canvas. That catches us up to present.

Presently, SVG implementations are not performant for InkML use cases. 
We are
still left with Canvas as a solution for that issue. I believe that 
Doug's proposal
to investigate a new graphics API to encompass the functionality of 
SVG+Canvas
should also integrate WebGL+InkML as well as ARIA; that's the stack we have
had to use in practice to deliver a desktop quality application 
experience with Web Apps apis.

As for general UI: CSS3 serves most of the use cases we initially used
Canvas for; and CSS3 support has really caught on in 2010/2011. Just as
with SVG, we certainly work with CSS3 -- round rectangles and gradients 
are super.
Many CSS extensions are still vendor specific.

Canvas serves most of the existing market; and while CSS3 naming and 
semantics
are fantastically useful, Canvas output gives us a level of visual 
control and compatibility
that CSS-only solutions do not. We're also able to stay away from 
vendor-specific prefixes;
using them on a case-by-case basis as a progressive enhancement.

While stand-by, eager to engage in features put forward by CSS4 and 
SVG2, we need
to complete our ARIA support of our Canvas-based UIs. The alternative,
of supporting a completely different, stripped down interface, for 
AT-users, is not
palatable. It does not fit with the concept of "universal design", nor 
of fallback content.

WHATWG has supported every accessibility interface we need, except 
accLocation.
The focus event handling of canvas fallback content, and 
scrollPathIntoView, are
immensely helpful in allowing us to meet WCAG principles. I've personally
tested NVDA, Window-Eyes, JAWS, ZoomText, Windows UI Automation and MSAA 
trees,
and the packaged support in OS X and iOS for accessibility in the browsers.

I've tested the full spectrum of HTML forms as well as some of the new 
input elements
put forward by the WHATWG. I've tested the spectrum of SVG, as well as 
off-loading
filters onto the GPU via WebGL.

And I've done all of this, because writing web apps, on the belief that 
browsers can
deliver a "native-application level" experience, is my livelihood. I'm 
writing applications,
and just as with every other API/stack, writing applications requires a 
lot of work.

I'm invested, because my income is built on my ability to deliver usable 
applications.

I'm very much invested into the Web stack, in any form that is supported;
at this point, I'm one blocking issue away from clearing up my 
accessibility testing bug list.
And so I'm putting in a great deal of effort into confronting that issue.

The proposal put forward is internally consistent, it's cost effective, it's
understandable by existing authors, there are hundreds of existing 
applications
that could use the method, and it completes the IAccessible obligations 
that vendors have to accessibility APIs.

While I understand your position on Canvas UI uses, I appeal to you, to  
understand my obligation to WCAG,
to end users, and the limits of what existing Canvas applications can 
support in practice.

Please consider the merits of allowing Canvas developers to send path 
data to assistive technology,
on their own. I believe they are worthwhile; we are talking simply, 
about setClickableRegion(element) sending
an event, with current method, and the element parameter, to the browser 
vendor's accessibility API.

That's what I've been pushing hard for, for the past few months, and 
that completes the list of issues
I've encountered, from the past four years.


-Charles

From ian at hixie.ch  Thu Jul 28 17:24:49 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:24:49 +0000 (UTC)
Subject: [whatwg] questions regarding submit event timing
In-Reply-To: <BANLkTikSfhtx+aAPKNpiOUu7vUD727TCPQ@mail.gmail.com>
References: <BANLkTi=2egZS7RmJG8ds0VEjczaUTwVZwQ@mail.gmail.com>
	<BANLkTinoev9GyBdzftvwJiz9pZ9XeOq=8Q@mail.gmail.com>
	<BANLkTikfNU_15fWORuhmKmzN+9TiUQ+RtA@mail.gmail.com>
	<BANLkTikSfhtx+aAPKNpiOUu7vUD727TCPQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107280132320.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Hallvord R M Steen wrote:
>
> Some questions related to possibly clarifying this section: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit
> 
> 1) What methods exactly cause the "scripted submit" flag to be set? It's 
> obviously set if you call form.submit(), but will it be set in these two 
> cases:
> 
> HTML: <form><input type="submit"></form>
> JS: form.elements[0].click()
> 
> or
> HTML: <form><input type="submit"></form>
> JS: form.elements[0].dispatchEvent( evt ) /* where evt is a 'click'
> event object  */
> 
> I believe the answer should be yes in both cases but I'm not sure if 
> it's clear from the spec.

On Mon, 2 May 2011, Glenn Maynard wrote:
> 
> The only place in the HTML5 spec itself that sets this flag is submit() 
> (http://www.whatwg.org/specs/web-apps/current-work/#dom-form-submit), 
> although other specs could also use that flag.

Indeed.


On Mon, 2 May 2011, Jonas Sicking wrote:
> 
> Isn't the purpose of this flag mostly backwards compatibility, but 
> otherwise a fairly awkward feature. If so, it seems like we should limit 
> its scope as much as possible, both to make implementation easier, and 
> to make the forms API otherwise as simple as we can.

On Thu, 5 May 2011, Hallvord R M Steen wrote:
> 
> It seems to have two purposes:
> 1) avoid doing form validation on form.submit()
> Definitely a backwards compatibility feature, and one that yours truly 
> probably caused by complaining when form.submit() was specified to throw 
> an exception when the form didn't validate. This broke websites left, 
> right and center when implemented in Opera.
> 
> 2) Avoid firing a submit event.
> What is more intuitive for button.click() or a synthetic click event on 
> the button - submit event firing? I guess so, in that case the spec 
> as-is is OK though it's a bit counter-intuitive that other scripted ways 
> to submit a form than .submit() don't set the scripted-submit flag.

On Thu, 5 May 2011, Jonas Sicking wrote:
> 
> From a behavioral perspective I think it's most intuitive that the 
> events fire and that validation occurs. That way calling .click() 
> behaves as if the user clicked.
> 
> However I agree that a name like "scripted-submit" could be interpreted 
> to mean that it should include other things than calls to .submit.
> 
> Maybe renaming the flag would make the spec more intuitive?

I've renamed it to "submitted from submit() method".


On Mon, 2 May 2011, Hallvord R M Steen wrote:
>
> 2) Is the event fired synchronously? (And is it fired synchronously for 
> all three cases of scripted submits mentioned above?) Again, I think the 
> answer is yes but I couldn't find this information in the spec when 
> looking for it.

On Mon, 2 May 2011, Glenn Maynard wrote:
> 
> All events in the HTML5 spec are effectively synchronous; it uses tasks 
> to get the effect of what DOM Events calls an "asynchronous event".  
> Step 6 says "fire a simple event that is cancelable named submit, at 
> form", which is strictly synchronous; if it was firing it asynchronously 
> it'd say "queue a task to fire a simple event".
> 
> (It's also possible for an entire algorithm to be running from a task, 
> in which case the event is synchronous with respect to the algorithm, 
> but the algorithm itself, including the event, is asynchronous with 
> respect to any script that triggered it.  Handling these common but more 
> complicated interactions is why this method is much clearer and more 
> powerful than the overgeneric "asynchronous event" concept.)

Indeed.

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

From ian at hixie.ch  Thu Jul 28 17:36:26 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:36:26 +0000 (UTC)
Subject: [whatwg] Spec references in multipage
In-Reply-To: <BANLkTinzZ==FhG5FZ4bJuEt+rxYAHST0Fw@mail.gmail.com>
References: <BANLkTinzZ==FhG5FZ4bJuEt+rxYAHST0Fw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107290035321.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Glenn Maynard wrote:
>
> This is probably a known issue, but the reference lists in the multipage 
> version of the specs only list references within the same section of the 
> spec.  Clicking "submitted" in [1] shows only two references.  Clicking 
> the same thing in the single-page version shows nine.  It would be very 
> helpful if external references were included.
> 
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit

Yeah, this is the result of the dfn.js script only looking in the current 
document. If anyone is interested in fixing this, let me know and I can 
try to explain the problem space. (One solution is to change the spec 
splitter to output data that a new dfn.js can use.)

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

From ian at hixie.ch  Thu Jul 28 17:43:34 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:43:34 +0000 (UTC)
Subject: [whatwg] Browser inconsistencies in rendering <optgroup> and
 <option>
In-Reply-To: <4DBF4571.1060109@mit.edu>
References: <4CBF2FEB.5010903@mit.edu>
	<Pine.LNX.4.64.1101050143390.29066@ps20323.dreamhostps.com>
	<4D23EBEC.9030503@mit.edu>
	<Pine.LNX.4.64.1105022323000.19153@ps20323.dreamhostps.com>
	<4DBF4571.1060109@mit.edu>
Message-ID: <Pine.LNX.4.64.1107290040260.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Boris Zbarsky wrote:
> On 5/2/11 7:26 PM, Ian Hickson wrote:
> >
> > I think it'd be better for [the rendering of <option>s in a <select> 
> > being one to a line] to be a style scoped to the binding that defines 
> > the <select>, personally.
> 
> OK, but more on this below.
> 
> > > I would clearly prefer that the behavior be defined in terms of CSS; 
> > > UAs that under the hood want to ignore the styles and just do 
> > > something magic can still do that, of course.
> > 
> > The behaviour is defined in terms of CSS and a hypothetical binding 
> > language similar to XBL; in theory that should be sufficient for your 
> > needs, no?
> 
> I don't think so; we need to define at least some details of the 
> binding. That's what I meant by sites depending on the details.  For 
> example, width calculations for <select> need to work in a particular 
> way (or rather small range of ways)....
> 
> > If not, I guess we have to work out what we can get browser vendors to 
> > converge on. I am concerned that this might not end up being exactly 
> > what you need, though, which would be of no more help to you than the 
> > status quo, but with more complicated rules.
> 
> That's entirely possible, yes.  At the moment we're getting bug reports 
> because people write their HTML+CSS, test in only WebKit or only IE, and 
> then it breaks in Gecko.  I would assume that there are others who only 
> test in Gecko and then it breaks in other browsers....

That makes sense.

My intent at this point is to continue to define this in terms of abstract 
bindings. However, that doesn't mean we can't define the constraints that 
those bindings should work under. If you would like particular constraints 
specified, e.g. the width of a <select>, please do raise them.

Given this model, though, I don't think the initial request (having a 
UA-level rule for <option> that sets display:block outside the context of 
a binding) makes sense.

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

From ian at hixie.ch  Thu Jul 28 17:54:40 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:54:40 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <4DC7C90F.4080405@gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
Message-ID: <Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 3:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 31 Dec 2010, Jonas Sicking wrote:
> >> >
> >> > The thing that makes this different than "Google suggest"-style UI 
> >> > is that in the latter case you need a script that continually polls 
> >> > for more appropriate suggestions and updates the list -- for this 
> >> > kind of thing we'd probably want to use a direct API, we wouldn't 
> >> > want to have scripts have to poke at the <datalist> DOM in real 
> >> > time.
> >>
> >> Why not?
> >>
> >> The firefox implementation should allow this (though I haven't tried 
> >> this myself). Feel free to try it out and let us know how well/poorly 
> >> it works.
> >
> > I just meant that it would be a poor authoring experience. I agree 
> > that it should in theory be possible with the current API; it just 
> > seems that if that's the use case we want to address, we should 
> > instead just have people point to a URL and be done with it:
> >
> >   <input type=text autosuggest="/cgi-bin/autocomplete.pl">
> >
> > ...or some such.
> 
> Sure, but that seems like a significantly more complex solution to 
> design. We'd likely have to add features like deciding how many 
> milliseconds to wait for another keystroke before sending the request. 
> We'd also have to come up with a file-format for the response, and a 
> definition of how the typed value is supposed to be sent with the 
> request.

Yes. Doing the hard work to make it easier for authors is our job. :-)


> I'd also be worried about making it possible to write keyloggers on 
> sites that filter out scripts, but do allow form controls to be 
> inserted.

These would presumably be forms that cannot be submitted? I'm not sure I 
understand how this attack scenario would work in practice.


On Tue, 3 May 2011, Aryeh Gregor wrote:
> On Mon, May 2, 2011 at 6:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I just meant that it would be a poor authoring experience. I agree 
> > that it should in theory be possible with the current API; it just 
> > seems that if that's the use case we want to address, we should 
> > instead just have people point to a URL and be done with it:
> >
> > ? <input type=text autosuggest="/cgi-bin/autocomplete.pl">
> >
> > ...or some such.
> 
> This is too inflexible.  It splits the logic between the browser and 
> server in a rigid way, and doesn't allow client-side script to have any 
> say.  It would be much more useful to have a script API that lets you 
> assign a list of suggestions to an input.  Basically the same 
> functionality as datalist, just easier to script.  This way, the author 
> has control over when and how the results are fetched and displayed, can 
> use any format on the server side, can retrieve results from the client 
> side if they like, etc.
> 
> There's no need to use the subjunctive here, by the way.  As I said, I 
> did actually write such a search-suggestion thing for MediaWiki using 
> the datalist API, and it works great in Firefox 4 as far as I can tell.  
> It was just complicated unnecessarily by the need to add datalist 
> elements to the DOM instead of plugging a list directly into the input.

We could certainly also support scripted delivery of the suggestions.


On Tue, 3 May 2011, Jonas Sicking wrote:
> >>
> >> It seems to me that a simple boolean attribute and a few lines of 
> >> script solves 80% of the use cases.
> >
> > What boolean attribute would that be?
> 
> The mozNoFilter attribute we added in Firefox 4.

On Wed, 4 May 2011, Aryeh Gregor wrote:
>
> I don't see any use-case where you wouldn't want to use mozNoFilter. Why 
> doesn't it just work that way always?

On Mon, 9 May 2011, Mounir Lamouri wrote:
> 
> Basically, when you want to use the datalist to suggest a few things you 
> might not want to filter and when the list is long, you very likely want 
> to filter.
> 
> You might not want to filter when the list is a real set of suggestions 
> and you can type anything else. For example, a field in a support form 
> can ask you "What is your problem?" and you could type a brief summary 
> but some pre-written issues will be available. It's equivalent to a 
> select element followed by an input field that you can use if you select 
> "other" in the list. As I see it, when you filter, you have a very long 
> list and you very likely want the user to select something in the list 
> like a list of bugzilla emails, a list o metro stations, etc. Writing 
> anything not in the list might not work.

So why don't you just automatically filter if the list is long, and not 
filter if the list is short?

I don't really understand the reason for this attribute.



I haven't added anything to the spec yet.

I think mozNoFilter is unnecessary; UAs should be clever enough to 
determine when the UI would be better with filtering and when it would be 
better without. This seems rather trivial as it is (just filter when the 
list is greater than seven, and don't filter the list to zero unless 
you're confident that none of the suggestions apply at all).

I think there is a use case for script- or server-driven suggestions for 
which we could do a more targetted feature, distinct from the current 
feature which is optimised for the static autocomplete combo box case. 
However, I think we should wait a while to get the implementations 
solidified and to see how people use the current feature before adding 
more stuff here.

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

From ian at hixie.ch  Thu Jul 28 18:07:03 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 01:07:03 +0000 (UTC)
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > <select> in a <datalist> is completely ignored for form submission. In 
> > fact, any form element at all in <datalist> is ignored for form 
> > submission. See the "construct the form data set" algorithm:
> >
> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
> >
> > It's so that you can do things like:
> >
> > ? <input ... list=options>
> > ? <datalist id=options>
> > ? ? <select ...>
> > ? ? ? <option>...</option>
> > ? ? </select>
> > ? ? ...maybe other form controls here...
> > ? </datalist>
> >
> > Basically everything in the <datalist> except the <option> elements is 
> > for fallback in legacy UAs and is ignored in new UAs.
> 
> Couldn't this be accomplished using a few lines of javascript?

Not when scripts are disabled, no.


> That seems like a better solution than one that for all eternity adds 
> browser code complexity both to do a deep search for <option> elements 
> when building the list for <datalist>, and that requires walking the 
> parent chain whenever submitting form controls.

It doesn't seem that bad. Surely code for both of those is so widely used 
in a browser that both of those operations are basically one-liners.

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

From ian at hixie.ch  Thu Jul 28 18:15:51 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 01:15:51 +0000 (UTC)
Subject: [whatwg] link.sizes and [PutForwards=value]
In-Reply-To: <BANLkTin_kiRTHBZ5zHyLRQECHq5QVSoXbQ@mail.gmail.com>
References: <4CB709B6.5040706@helsinki.fi>
	<op.vkl8act164w2qv@anne-van-kesterens-macbook-pro.local>
	<4CB88535.9070007@helsinki.fi>
	<Pine.LNX.4.64.1101050126330.29066@ps20323.dreamhostps.com>
	<4D2444C8.8040502@gmail.com>
	<Pine.LNX.4.64.1105022326190.19153@ps20323.dreamhostps.com>
	<BANLkTi=me4SCesFWo-QM8tc2J8whmO=jmA@mail.gmail.com>
	<BANLkTin_kiRTHBZ5zHyLRQECHq5QVSoXbQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107290107420.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 4:37 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 5 Jan 2011, Mounir Lamouri wrote:
> >> On 01/05/2011 02:29 AM, Ian Hickson wrote:
> >> > On Thu, 14 Oct 2010, Olli Pettay wrote:
> >> >>
> >> >> may I wonder why on earth any new API, like link.sizes uses 
> >> >> PutForwards? IMHO, PutForwards should be limited to the awkward 
> >> >> DOM0 APIs like window.location.
> >> >
> >> > On Fri, 15 Oct 2010, Olli Pettay wrote:
> >> >>
> >> >> It makes getters and setters work in a very different way. 
> >> >> Inconsistency in APIs isn't a good thing.
> >> >
> >> > The idea is to make the attribute appear to work like a DOMString 
> >> > for most purposes, but to allow methods to be invoked on it. (All 
> >> > the attributes that have [PutForwards] set also have a stringifier 
> >> > on their object's interface.)
> >>
> >> Is there a use case for [PutForwards] (except saving a few characters 
> >> for the authors) that could justify the inconsistency?
> >
> > The idea is to be consistent with all the other reflecting attributes, 
> > which can mostly all be treated as either strings or numbers. Contrast 
> > this with the way attributes are reflected in SVG, where there's a 
> > step of indirection to get to the string value due to the animation 
> > API. I think this is a case where [PutForwards] and stringification 
> > makes sense.
> 
> It's inconsistent in that all other objects in javascript stringify to 
> "[Object Foo]", whereas this object doesn't.

[PutForwards] doesn't affect that, that's the stringifier. Location, <a>, 
and <area> all already have stringifiers, as do lots of objects in JS.

Are we really concerned about objects stringifying to "[Object Foo]"?

It seems that the usefulness of such stringification is far outweighed by 
the usefulness of being able to treat the attribute as a string attribute 
like any other reflecting attribute while also being able to use methods 
on it. In fact, it is consistent with every DOMString attribute: they 
don't stringify to "[Object String]", yet you can call methods on them. 
What's the difference?


> If the concern is that link.sizes should be consistent with other 
> attribute-mapping properties then you're only half-way there since 
> typeof tests still behaves differently.

I'm not particularly concerned about such edge cases (who does typeof on 
reflecting attributes in a way where the difference here would matter?). 
It's the common use that I'm concerned about.


> I definitely agree that the way SVG does it is not ideal. How about 
> simply creating a second property, like link.parsedSizes which returns 
> the tokenlist?

That's what we're doing (for legacy reasons) with className/classList and 
rel/relList, but I consider that an ugly and unfortunate wart on the API. 
As much as possible, attributes that take space-separated lists are using 
DOMSettableTokenList to avoid this (including a few legacy ones that 
aren't as high-profile as class and rel).


On Mon, 2 May 2011, Jonas Sicking wrote:
> 
> Of course, an even simpler solution is to remove access to a 
> DOMTokenList representing link.sizes entirely. What is the use case? Is 
> it really that common to modify link.sizes that we need syntax sugar for 
> it?

All the space-separated lists are exposed this way. It would be rather odd 
to exclude just one on the basis that we couldn't think of a reason why 
this particular one would get changed much.

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

From bzbarsky at MIT.EDU  Thu Jul 28 18:59:07 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 28 Jul 2011 21:59:07 -0400
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
References: <4DDFF77F.9050605@mit.edu>	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>	<4DFB8783.7070802@mit.edu>
	<4DFB8C23.7070808@mit.edu>	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>	<4DFB9F2D.3070404@mit.edu>	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
Message-ID: <4E3213EB.8020508@mit.edu>

On 7/28/11 6:05 PM, Anne van Kesteren wrote:
> So the SVG WG discussed this and they would like this as well. (They
> basically want the same behavior as HTML has here and converge as much
> as possible.) The change to the current mechanism required for SVG is to
> expose an "evt" variable somehow in scope of the Function.

Why, exactly?  I thought for SVG the "evt" thing was only relevant for 
content attributes, not IDL attributes.

> Now does it make sense to have the IDL attributes on Element but not
> have the content attributes on all elements? That would mean it still
> depends on the markup language what you can use as on* attributes which
> is not very straightforward.

It might make sense to look into that too; I did not propose it because 
that's not what UAs do right now.  At least Gecko doesn't; I didn't look 
at others.

-Boris


From jonas at sicking.cc  Thu Jul 28 19:34:17 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 28 Jul 2011 19:34:17 -0700
Subject: [whatwg] Form element invalid message
In-Reply-To: <Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei8Xw_PkKRVKbH482mJ+v=14x_p6GOyqFTwitorH3ZO=Cg@mail.gmail.com>

On Wed, Jul 27, 2011 at 5:21 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Apr 2011, Jonas Sicking wrote:
>> On Fri, Apr 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Wed, 29 Dec 2010, Mounir Lamouri wrote:
>> >> On 12/29/2010 07:41 AM, Ian Hickson wrote:
>> >> >>
>> >> >> I actually think that the customerrormessage attribute that has
>> >> >> been suggested is a decent solution too. [...]
>>
>> For example, if I go to www.google.com and click on the "sign in" link
>> at the top, then without entering anything press the "sign in" button.
>> At this point the page displays a error message in red that says "Enter
>> your email address." [...]
>>
>> In general it makes a lot of sense to want to display a different
>> message when the user has failed to enter a valid value in a field.
>> Clearly the user failed to enter what was requested the first time, and
>> so the context around the field was not enough for the user to enter
>> what was requested. Hence a more detailed description is appropriate.
>> >
>> > I don't understand how such an attribute would work. Take <input
>> > type=number> for example, with an explicit min, max, step, etc. How
>> > would you know what value to put in the attribute? There are going to
>> > be different needs when the control's value is too low, too high, not
>> > aligned to a step, missing, etc.
>>
>> Consider the example above from googles login page. Here there are two
>> possible errors:
>>
>> 1. The field is empty
>> 2. The field doesn't contain an email address
>>
>> In both cases the message "Enter your email address." seems appropriate.
>> And it seems better than what we as a browser could generate.
>
> A text input field could have a number of error conditions:
>
> ? <label> Offer code:
> ? ?<input type=text maxlength=8 pattern="[a-z1-9]+" required>
> ? </label>
>
> Suppose the code is printed as two groups of four characters, for example
> something like "1A2B 3C4D".
>
> The user could have entered the code with the space (the site doesn't want
> the space). Or the user could have read an O as a 0 (the code never has
> any zeroes to avoid that). Or the user could have forgotten to enter the
> code. In each of these cases, I think you'd want a different message.
>
>
> Anyway. I guess we can have a dedicated attribute that user agents can use
> to provide a message, rather than the current solution of just using the
> title="" attribute for pattern=""'s error message. If it's present, user
> agents could use it to replace or augment their message, and authors could
> make the message more specific by dynamically changing the attribute when
> during the 'invalid' event handler.
>
> ? <label> Offer code:
> ? ?<input type=text maxlength=8 pattern="[a-z1-9]+" required
> ? ? ? ? ? oninput="setCustomValidity(input.match(/0/) ?
> ? ? ? ? ? ? ? ? ? ?'Codes contain no zeroes, only Os.' : '')"
> ? ? ? ? ? validitymessage="Enter the code without spaces.">
> ? </label>
>
>
> If we add this, do you think it should be displayed with, instead of, or
> replaced by the setCustomValidity() message, when both are given?

I don't feel strongly which would be given precedence. On one hand it
seems simpler and more consistent to *always* use the attribute, and
thus give it precedence over setCustomValidity. On the other hand it
seems weird to make setCustomValidity ignore its argument. On the
third hand, it seems likely that people would end up having to
duplicate the same string in the attribute as in the argument to
setCustomValidity. On the fourth hand it would be easy to do
elem.setCustomValidity(elem.customerror).

/ Jonas

From cmhjones at gmail.com  Fri Jul 29 04:32:44 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 12:32:44 +0100
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CALmvxBf3+3g5eH1CG3yFEeF8sfOjJM05hp+X184iFaq5zyOT=A@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>
	<CALmvxBf3+3g5eH1CG3yFEeF8sfOjJM05hp+X184iFaq5zyOT=A@mail.gmail.com>
Message-ID: <2E5F42EB-F195-4583-ADD0-29B5705DD55D@gmail.com>

This kind of permission may be synonymous with that of geolocation privileges and their explcit management requirements.

See this thread for discussion on this:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032631.html

Thanks,
Cameron Jones

On 26/07/2011, at 4:31 AM, James Kozianski wrote:

> Hi Ian,
> 
> Here are the use cases I had in mind:
> 
> 1. Allow sites to conditionally show UI to promote the advantages of
> registering the site as a handler.
>   (requires isRegistered)
> 
> 2. Allow sites to provide settings screens which allow users to register
> / deregister handlers from within the site.
>   (requires isRegistered, and deregisterProtocolHandler)
> 
> The presence of an ignored list - sites who don't have permission to use
> registerProtocolHandler - necessitates Michael Davidson's suggestion that
> isRegistered() should return a tri-state value (REGISTERED, DECLINED,
> NOTASKED). Otherwise sites that have been 'ignored' by a user won't be able
> to tell if they should show their promotional UI or not.
> 
> Cheers,
> James
> 
> 
> On Sat, Jul 23, 2011 at 8:33 AM, Ian Hickson <ian at hixie.ch> wrote:
> 
>> On Thu, 21 Apr 2011, James Kozianski wrote:
>>> 
>>> I'd like to propose the following changes to the registerProtocolHandler
>>> spec. [...]
>> 
>> Before I study the proposals in detail, is there a description of the
>> kind of experience we're trying to enable here?
>> 
>> What are the UIs we expect to see page use wih registerProtocolHandler()?
>> 
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> 


From cmhjones at gmail.com  Fri Jul 29 05:10:10 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 13:10:10 +0100
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <BANLkTi=LG=k0xQ+PZZSN8e=ot1t9p5hpgg@mail.gmail.com>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<op.vtxacccbo84pey@pc36.virtualebrana>
	<BANLkTi=LG=k0xQ+PZZSN8e=ot1t9p5hpgg@mail.gmail.com>
Message-ID: <DED83CC8-3719-4945-8F8F-273BB7B15981@gmail.com>


On 15/04/2011, at 10:56 PM, Aryeh Gregor wrote:
> Trying to add more features to the
> new form stuff is premature when we only have one really good
> implementation (IMO: Gecko's), and that implementation is partial.
> The time to talk about new features is when we have some amount of
> stability and interoperability in existing features.

However, features resulting from new, or more clarified, requirements would seem to require immediate attention in order to avoid such 'complete' implementations and their expectation of validity and continuance.

Thanks,
Cameron Jones

From cmhjones at gmail.com  Fri Jul 29 05:11:03 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 13:11:03 +0100
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <4E211923.1080608@cs.tut.fi>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<21B04E943C1341F0A867C1234DB30723@JukanPC>
	<BANLkTi=_8R2CRbTcXSFtSVAsD66682rznQ@mail.gmail.com>
	<A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
	<Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>
	<4E211923.1080608@cs.tut.fi>
Message-ID: <EC14C220-7ADB-4317-9409-4851532A2C4F@gmail.com>


On 16/07/2011, at 5:52 AM, Jukka K. Korpela wrote:

> 16.07.2011 00:01, Ian Hickson wrote:
> 
>> Much discussion on this topic happened when we started on this work in
>> 2004 and 2005, I highly recommend perusing the archives around that time.
> 
> Authors and implementors will need to be able to understand the topic without checking discussions archives, so the specs should say at least a little about the issue that the rules for user?s input may be quite different from the rules for the as stored and forwared. And users will be confused anyway, when user interfaces work oddly.

Yes, or if you have the knowledge of these discussions perhaps some additional assistance in locating any specific items would be helpful? 

>> On Thu, 14 Apr 2011, John Tamplin wrote:
>>> 
>>> The entire web application, which includes both client and server-side
>>> code, must have the same idea about what locale the user is using.  If
>>> the app provides a drop-down box or preference setting to choose a
>>> different locale, as most localized apps do, the web browser has to be
>>> using the same locale for any native locale processing it uses.
>>> Otherwise, you run a serious risk of having incorrect data -- if a user
>>> types "10,000" in a field when they think they are using a locale with a
>>> comma as the decimal separator, does the app receive that as 10000 or
>>> 10.000?  If the app is running in en-US because the user requested it or
>>> their system locale isn't supported by the app, and the browser sends
>>> "10.000" as the value because the system locale is "de", then that is a
>>> problem.
>> 
>> Indeed. To solve this, we need help from CSS. That's one of the reasons we
>> created<output>  in HTML.
> 

Concerned about <output>.

> This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. It will probably cause _further_ confusion.
> 
> I?m afraid the new input types for numeric data and for dates and times, even when implemented in browsers, will be of very limited usefulness and will cause more damage than good, unless the localization issues will be properly addressed.
> 
> It is part of the risk that they often _seemingly_ work. For example, an author would use <input type=number> and test the software thoroughly by his own standards, but the standards don?t include testing with the system?s UI language being other than English. So things seem to work until someone tries to put a bid of 10,000 dollars but gets it turned to 10 dollars and loses, or makes a date for 7/4/2012 and gets it interpreted as April 7 when he meant July 4, or vice versa.
> 
> I?m afraid many authors will start using the new types eagerly when browser support comes sufficiently widespread. It looks so much better, cooler, and easier than parsing data yourself or requiring the user to type data in specifically instructed format. But it?s a dangerous illusion.
> 
> -- 
> Yucca, http://www.cs.tut.fi/~jkorpela/


Yes, i agree. I've opened a bug about the handling of i18n by user agents:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13408

In response to the question of how to manage the formatting and encoding of i18n data values, the element's declared or derived lang should be used. the form element also contains a lang attribute and it is this which should be used to encode the data for submission and processing, as the author has declared they expect to accept. ie:

<form lang="en-US">
	<input type="number" lang="fi"/>
	<input type="submit"/>
</form>

This input should parse and format the number in the Finish locale, and the form should encode the number in en-US locale.

Thanks,
Cameron Jones




From cmhjones at gmail.com  Fri Jul 29 05:30:30 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 13:30:30 +0100
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
Message-ID: <AD1C2FBA-C958-42FE-9105-BA9474096BBE@gmail.com>


On 14/07/2011, at 10:36 PM, Ian Hickson wrote:
> I haven't studied the above yet, but I just wanted to bring up a trial 
> balloon for a possible alternative solution: drop <time> and replace it 
> with a generic solution.
> 
> There are several use cases for <time>:
> 
> A. Easier styling of dates and times from CSS.

This may be a case of a disconnect between what a programmer thinks of style compared to what a user thinks of style.

A localized user thinks that 1/1/01 is a date, whereas this is just a style of formatting to a programmer who thinks of date's in the non-ambigous serialization of 2001-01-01

The question: is i18n formatting stylistic or semantic? 

> 
> B. A way to mark up the publication date/time for an article (e.g. for 
> conversion to Atom).

I have concerns about the granularity of such an attribute as pubdate. 

> 
> C. A way to mark up machine-readable times and dates for use in 
> Microformats or microdata.
> 
> Use cases A and B do not seem to have much traction.
> 
> Use case C applies to more than just dates, and the lack of solution for 
> stuff outside dates and times is being problematic to many communities.
> 
> Proposal: we dump use cases A and B, and pivot <time> on use case C, 
> changing it to <data> and making it like the <abbr> for machine-readable 
> data, primarily for use by Microformats and HTML's microdata feature.
> 

This sounds like a great area of research in hope of a simpler, yet more flexible and generic solution.

The inclusion of date\time\etc may amount to a similar situation as encountered in HTML4 with it's stylistic attributes and their resulting obsoletion when a better solution is found, in that case it was CSS.

> 
> (I've also filed this as a bug here:
>   http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240
> I generally prefer to only have issues discussed either in e-mail or in a 
> bug, but Tantek informs me that for technical reasons he can't discuss 
> this on the bug and his input is more important to me than convention, 
> thus my bringing this up here again!)
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Thanks,
Cameron Jones

From gisolfi at us.ibm.com  Fri Jul 29 08:13:32 2011
From: gisolfi at us.ibm.com (Dan Gisolfi)
Date: Fri, 29 Jul 2011 11:13:32 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
Message-ID: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>

On behalf of the Open Cooperative Web Framework Project (
http://opencoweb.org), with respect to the HTML Editing APIs specification 
(http://aryeh.name/spec/editing/editing.html), it would seem the current 
version of the spec lacks APIs for getting / setting the caret
position.

An example scenario for such a requirement (addition of such methods) 
would be the following:
When developing an cooperative web enabled rich-text-editor, whereby 
multiple simultaneous users can co-author shared content, the editor must 
be able to allow each participant to get/set caret/cursor position in 
order to reflect the multiple positions of each active author in a 
cooperative web session.

Dan Gisolfi

From jonas at sicking.cc  Fri Jul 29 08:29:44 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 08:29:44 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>

On Thu, Jul 28, 2011 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 3 May 2011, Jonas Sicking wrote:
>> >>
>> >> It seems to me that a simple boolean attribute and a few lines of
>> >> script solves 80% of the use cases.
>> >
>> > What boolean attribute would that be?
>>
>> The mozNoFilter attribute we added in Firefox 4.
>
> On Wed, 4 May 2011, Aryeh Gregor wrote:
>>
>> I don't see any use-case where you wouldn't want to use mozNoFilter. Why
>> doesn't it just work that way always?
>
> On Mon, 9 May 2011, Mounir Lamouri wrote:
>>
>> Basically, when you want to use the datalist to suggest a few things you
>> might not want to filter and when the list is long, you very likely want
>> to filter.
>>
>> You might not want to filter when the list is a real set of suggestions
>> and you can type anything else. For example, a field in a support form
>> can ask you "What is your problem?" and you could type a brief summary
>> but some pre-written issues will be available. It's equivalent to a
>> select element followed by an input field that you can use if you select
>> "other" in the list. As I see it, when you filter, you have a very long
>> list and you very likely want the user to select something in the list
>> like a list of bugzilla emails, a list o metro stations, etc. Writing
>> anything not in the list might not work.
>
> So why don't you just automatically filter if the list is long, and not
> filter if the list is short?

I'm not a big fan of try-to-guess-what-the-author-wants-to-do
solutions like that. Guessing will likely be as often wrong and
annoying as it will be correct and helpful.

/ Jonas

From jonas at sicking.cc  Fri Jul 29 08:39:01 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 08:39:01 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>

On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 2 May 2011, Jonas Sicking wrote:
>> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >
>> > <select> in a <datalist> is completely ignored for form submission. In
>> > fact, any form element at all in <datalist> is ignored for form
>> > submission. See the "construct the form data set" algorithm:
>> >
>> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
>> >
>> > It's so that you can do things like:
>> >
>> > ? <input ... list=options>
>> > ? <datalist id=options>
>> > ? ? <select ...>
>> > ? ? ? <option>...</option>
>> > ? ? </select>
>> > ? ? ...maybe other form controls here...
>> > ? </datalist>
>> >
>> > Basically everything in the <datalist> except the <option> elements is
>> > for fallback in legacy UAs and is ignored in new UAs.
>>
>> Couldn't this be accomplished using a few lines of javascript?
>
> Not when scripts are disabled, no.

The number of cases when a site can use this solution to get an
acceptable UI *and* care about supporting users with scripts disabled
*and* is planning to roll out support within the timeframe when
there's some support for HTML5 forms, but not enough to rely on it, is
extremely small.

My experience is that it's much more likely that people will use other
solutions until there is wide enough browser support to reliably use
it, and then use javascript as a fallback and not care about users
with JS disabled. And that goes even if we add this feature or not.

>> That seems like a better solution than one that for all eternity adds
>> browser code complexity both to do a deep search for <option> elements
>> when building the list for <datalist>, and that requires walking the
>> parent chain whenever submitting form controls.
>
> It doesn't seem that bad. Surely code for both of those is so widely used
> in a browser that both of those operations are basically one-liners.

"It's easy to implement" is the worst reason ever to add a feature.

/ Jonas

From jonas at sicking.cc  Fri Jul 29 08:43:07 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 08:43:07 -0700
Subject: [whatwg] Form element invalid message
In-Reply-To: <4E30D965.6000704@cs.tut.fi>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
Message-ID: <CA+c2ei_oGfVx5tzEuwP6SeoHGb9jN6iOBFKEtBefthECWoSLLg@mail.gmail.com>

On Wed, Jul 27, 2011 at 8:37 PM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 28.07.2011 03:21, Ian Hickson wrote:
>
>> A text input field could have a number of error conditions:
>
> Indeed. Therefore it would be essential to be able to set the error message
> for _each_ check that a browser is supposed to do on the basis of HTML
> markup alone.

That would require not just a message for each check, but a message
for all combinations of checks. That is for most practical purposes
not going to be a workable solution. This is why I think it's better
to let the page deal with checking the different combinations that it
desires and choose a message based on that.

> If this is not possible, it is easier to authors to code all
> data checking in JavaScript.

Yup, I think that's basically the situation.

>> I guess we can have a dedicated attribute that user agents can use
>> to provide a message, rather than the current solution of just using the
>> title="" attribute for pattern=""'s error message.
>
> The title="" attribute is generally supposed to contain an advisory title
> for an element, and deviating from this that way is very odd and confusing -
> especially since user agents may show its value in a tooltip or speak it out
> when entering the field.

Indeed. I think the extra use for @title is a bad idea and should be removed.

/ Jonas

From ian at hixie.ch  Fri Jul 29 09:28:15 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:28:15 +0000 (UTC)
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
Message-ID: <Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Dan Gisolfi wrote:
>
> On behalf of the Open Cooperative Web Framework Project ( 
> http://opencoweb.org), with respect to the HTML Editing APIs 
> specification (http://aryeh.name/spec/editing/editing.html), it would 
> seem the current version of the spec lacks APIs for getting / setting 
> the caret position.
> 
> An example scenario for such a requirement (addition of such methods) 
> would be the following: When developing an cooperative web enabled 
> rich-text-editor, whereby multiple simultaneous users can co-author 
> shared content, the editor must be able to allow each participant to 
> get/set caret/cursor position in order to reflect the multiple positions 
> of each active author in a cooperative web session.

Surely all but the local one would not be real carets?

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

From ian at hixie.ch  Fri Jul 29 09:29:27 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:29:27 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> > On Mon, 9 May 2011, Mounir Lamouri wrote:
> >>
> >> Basically, when you want to use the datalist to suggest a few things 
> >> you might not want to filter and when the list is long, you very 
> >> likely want to filter.
> >>
> >> You might not want to filter when the list is a real set of 
> >> suggestions and you can type anything else. For example, a field in a 
> >> support form can ask you "What is your problem?" and you could type a 
> >> brief summary but some pre-written issues will be available. It's 
> >> equivalent to a select element followed by an input field that you 
> >> can use if you select "other" in the list. As I see it, when you 
> >> filter, you have a very long list and you very likely want the user 
> >> to select something in the list like a list of bugzilla emails, a 
> >> list o metro stations, etc. Writing anything not in the list might 
> >> not work.
> >
> > So why don't you just automatically filter if the list is long, and 
> > not filter if the list is short?
> 
> I'm not a big fan of try-to-guess-what-the-author-wants-to-do solutions 
> like that. Guessing will likely be as often wrong and annoying as it 
> will be correct and helpful.

Showing the user an autocomplete list with hundreds of entries is going to 
be far more annoying.

This to me seems to be entirely a UI issue.

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

From gisolfi at us.ibm.com  Fri Jul 29 09:38:35 2011
From: gisolfi at us.ibm.com (Dan Gisolfi)
Date: Fri, 29 Jul 2011 12:38:35 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
Message-ID: <OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>

Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:28:15 PM:

> From: Ian Hickson <ian at hixie.ch>
> To: Dan Gisolfi/Somers/IBM at IBMUS
> Cc: whatwg at lists.whatwg.org, ayg at aryeh.name
> Date: 07/29/2011 12:28 PM
> Subject: Re: [whatwg] [editing] Caret Position Access Methods
> 
> On Fri, 29 Jul 2011, Dan Gisolfi wrote:
> >
> > On behalf of the Open Cooperative Web Framework Project ( 
> > http://opencoweb.org), with respect to the HTML Editing APIs 
> > specification (http://aryeh.name/spec/editing/editing.html), it would 
> > seem the current version of the spec lacks APIs for getting / setting 
> > the caret position.
> > 
> > An example scenario for such a requirement (addition of such methods) 
> > would be the following: When developing an cooperative web enabled 
> > rich-text-editor, whereby multiple simultaneous users can co-author 
> > shared content, the editor must be able to allow each participant to 
> > get/set caret/cursor position in order to reflect the multiple 
positions 
> > of each active author in a cooperative web session.
> 
> Surely all but the local one would not be real carets?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Not sure what you mean by "real caret", but the scenario implies that each 
co-authoring conference(session) participant would have a corresponding 
cursor (caret) position depicting their associated reference point for 
edits. 

From ian at hixie.ch  Fri Jul 29 09:43:47 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:43:47 +0000 (UTC)
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 2 May 2011, Jonas Sicking wrote:
> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> >
> >> > <select> in a <datalist> is completely ignored for form submission. In
> >> > fact, any form element at all in <datalist> is ignored for form
> >> > submission. See the "construct the form data set" algorithm:
> >> >
> >> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
> >> >
> >> > It's so that you can do things like:
> >> >
> >> > ? <input ... list=options>
> >> > ? <datalist id=options>
> >> > ? ? <select ...>
> >> > ? ? ? <option>...</option>
> >> > ? ? </select>
> >> > ? ? ...maybe other form controls here...
> >> > ? </datalist>
> >> >
> >> > Basically everything in the <datalist> except the <option> elements is
> >> > for fallback in legacy UAs and is ignored in new UAs.
> >>
> >> Couldn't this be accomplished using a few lines of javascript?
> >
> > Not when scripts are disabled, no.
> 
> The number of cases when a site can use this solution to get an 
> acceptable UI *and* care about supporting users with scripts disabled 
> *and* is planning to roll out support within the timeframe when there's 
> some support for HTML5 forms, but not enough to rely on it, is extremely 
> small.

That's possible. The entire Web Forms 2 feature set is designed with this 
kind of fallback in mind, though.


> My experience is that it's much more likely that people will use other 
> solutions until there is wide enough browser support to reliably use it, 
> and then use javascript as a fallback and not care about users with JS 
> disabled. And that goes even if we add this feature or not.

If that's the case, we should probably rethink the entire design of the 
WF2 features, because maybe there's better ways to do things.

Looking specifically at <datagrid>'s ability to fall back to <select>, I 
agree that it's not necessarily doing to be widely used, but given that 
it's so simple to support and provides such a clean way to do fallback, I 
really don't see the harm in supporting it.


> >> That seems like a better solution than one that for all eternity adds 
> >> browser code complexity both to do a deep search for <option> 
> >> elements when building the list for <datalist>, and that requires 
> >> walking the parent chain whenever submitting form controls.
> >
> > It doesn't seem that bad. Surely code for both of those is so widely 
> > used in a browser that both of those operations are basically 
> > one-liners.
> 
> "It's easy to implement" is the worst reason ever to add a feature.

It's not the reason to add the feature. I'm just saying that browser 
complexity in this case isn't a reason to _remove_ the feature.

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

From ian at hixie.ch  Fri Jul 29 09:47:08 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:47:08 +0000 (UTC)
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
	<OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
Message-ID: <Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Dan Gisolfi wrote:
> Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:28:15 PM:
> > >
> > > An example scenario for such a requirement (addition of such 
> > > methods) would be the following: When developing an cooperative web 
> > > enabled rich-text-editor, whereby multiple simultaneous users can 
> > > co-author shared content, the editor must be able to allow each 
> > > participant to get/set caret/cursor position in order to reflect the 
> > > multiple positions of each active author in a cooperative web 
> > > session.
> > 
> > Surely all but the local one would not be real carets?
> 
> Not sure what you mean by "real caret"

By "real caret" I mean a caret that supports all the complexity of the 
system caret: relationship to the system selection, being movable by the 
user, effect on execCommand() APIs, effect on local system focus, etc.


> but the scenario implies that each co-authoring conference(session) 
> participant would have a corresponding cursor (caret) position depicting 
> their associated reference point for edits.

I don't think those are system carets. Why wouldn't using a <span> element 
be sufficient for this?

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

From ian at hixie.ch  Fri Jul 29 10:05:12 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 17:05:12 +0000 (UTC)
Subject: [whatwg] sic element
In-Reply-To: <51294D8114214B45AF44C1F847FA8E94@Vodka6000>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
Message-ID: <Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Jukka K. Korpela wrote:
> 
> But I'm afraid we cannot completely put aside the issue. The reason is 
> that recently the <u> element was promoted from obsolete physical markup 
> to conforming semantic markup, though with semantics that really 
> confuses me: "The u element represents a span of text with an 
> unarticulated, though explicitly rendered, non-textual annotation, such 
> as labeling the text as being a proper name in Chinese text (a Chinese 
> proper name mark), or labeling the text as being misspelt."
> 
> So the question "which markup should I use to indicate a word as 
> intentionally misspelt?" is currently "the <u> element".

You may use the <u> element to mark up an element that is misspelt. I 
wouldn't say "should", and the intention is orthogonal to the element's 
definition. In fact, given the element's definition, you equally use it to 
mark up words that are intentionally spelt _correctly_. The point is just 
that <u> is used to explicitly annotate some text without saying why in a 
textual manner. This makes it quite distinct from [sic], which is an 
explicitly articulated annotation.


> This sounds somewhat unnatural, though, since in the absence of 
> stylesheet rules for <u>, and when styles are disabled, <u> is rendered 
> as underlined in visual presentation. This tends to draw attention more 
> than is desirable in most situations.

I would not expect authors to use <u> where [sic] is appropriate.

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

From ian at hixie.ch  Fri Jul 29 10:08:17 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 17:08:17 +0000 (UTC)
Subject: [whatwg] Submit controls should be barred from constraint
 validation in favor of a new pseudo-class
In-Reply-To: <4DBFE155.40008@gmail.com>
References: <4C9BD80F.9000806@gmail.com>
	<Pine.LNX.4.64.1012310114340.28593@ps20323.dreamhostps.com>
	<4D1DB69A.1060902@gmail.com>
	<Pine.LNX.4.64.1105022241460.19153@ps20323.dreamhostps.com>
	<4DBFE155.40008@gmail.com>
Message-ID: <Pine.LNX.4.64.1107291707000.1701@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Mounir Lamouri wrote:
> On 05/02/2011 10:44 PM, Ian Hickson wrote:
> > On Fri, 31 Dec 2010, Mounir Lamouri wrote:
> > > On 12/31/2010 02:20 AM, Ian Hickson wrote:
> > > > far as I can tell. Anything that's visible and submitted is a candidate
> > > > for constraint validation.
> > > 
> > > Except<keygen>  and<object>.
> > > But do we agree that "it's visible and submittable so it should be able
> > > to be invalid" is not a sane rule? At least, we should not include
> > > non-editable but visible submittable controls like submit controls.
> > 
> > This only affects people who go out of their way to make submit controls
> > invalid, right? I guess I don't really care one way or the other, but it
> > seems easier all around to just make things as consistent as possible and
> > just allow it.
> > 
> > At the end of the day, on this, I'll spec whatever gets implemented. Do we
> > have multiple implementations one way or the other yet?
> 
> Opera 11.20 allows submit controls to be invalid and Gecko (since 2.0) 
> does not. I haven't check Webkit but IIRC, it has the same behavior as 
> Opera.

Indeed.

In fact, in testing this I found that the resulting UI would actually be 
kind of useful in certain scenarios. For example, an EULA "decline" button 
could be marked invalid with the message "If you decline this license 
agreement, you cannot use this site" or some such.

I've left the spec as is for now. I don't see much value in preventing 
submit buttons from being able to participate in this mechanism.

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

From ian at hixie.ch  Fri Jul 29 10:34:18 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 17:34:18 +0000 (UTC)
Subject: [whatwg] self-closing tags in html5
In-Reply-To: <31617157.post@talk.nabble.com>
References: <i7vd5ss1r3.fsf@hilbert.math.albany.edu> <4C9FAA89.3010400@mit.edu>
	<Pine.LNX.4.64.1012310303140.28593@ps20323.dreamhostps.com>
	<op.vok6yfgyte2ec8@aimac.local> <31617157.post@talk.nabble.com>
Message-ID: <Pine.LNX.4.64.1107291726280.1701@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Roger H?gensen wrote:
> 
> Is there a need for say a <pbr> ? (short for paragraph break) default 
> behavior being the same as two <br>.

Isn't that just two paragraphs separate from each other?


  <p> ... </p> <p> ... </p>


> Then again getting folks to change would be hard, so maybe a <cp> and 
> </cp> would make more sense. (closed paragraph)

How is that different from <p>?


> Myself I always tend to use <br><br> for readability when I don't feel 
> like the text should be split into different paragraphs. And I use <p> 
> and </p> for it's intended purpose, to markup actual paragraphs.
> 
> Now if <p> was turned into a synonym for <br><br> and </p> simply 
> ignored, I'd be happy to move to using say <cp> and </cp> for 
> paragraphs.

I'm pretty sure that's a non-starter from a compatibility persepective.


On Sat, 14 May 2011, yuhong wrote:
>
> FYI, the reason is that IE5 supported mixing foreign XML content into 
> HTML long before HTML5 added this support. It is used for VML for 
> example.

Note that this support has been removed from IE10.

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

From gisolfi at us.ibm.com  Fri Jul 29 11:07:57 2011
From: gisolfi at us.ibm.com (Dan Gisolfi)
Date: Fri, 29 Jul 2011 14:07:57 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
	<OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
	<Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>
Message-ID: <OF3175D5B4.23130152-ON852578DC.00628044-852578DC.00639B8D@us.ibm.com>

Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:47:08 PM:

> From: Ian Hickson <ian at hixie.ch>
> To: Dan Gisolfi/Somers/IBM at IBMUS
> Cc: whatwg at lists.whatwg.org, ayg at aryeh.name
> Date: 07/29/2011 12:47 PM
> Subject: Re: [whatwg] [editing] Caret Position Access Methods
> 
> On Fri, 29 Jul 2011, Dan Gisolfi wrote:
> > Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:28:15 PM:
> > > >
> > > > An example scenario for such a requirement (addition of such 
> > > > methods) would be the following: When developing an cooperative 
web 
> > > > enabled rich-text-editor, whereby multiple simultaneous users can 
> > > > co-author shared content, the editor must be able to allow each 
> > > > participant to get/set caret/cursor position in order to reflect 
the 
> > > > multiple positions of each active author in a cooperative web 
> > > > session.
> > > 
> > > Surely all but the local one would not be real carets?
> > 
> > Not sure what you mean by "real caret"
> 
> By "real caret" I mean a caret that supports all the complexity of the 
> system caret: relationship to the system selection, being movable by the 

> user, effect on execCommand() APIs, effect on local system focus, etc.
> 
> 
> > but the scenario implies that each co-authoring conference(session) 
> > participant would have a corresponding cursor (caret) position 
depicting 
> > their associated reference point for edits.
> 
> I don't think those are system carets. Why wouldn't using a <span> 
element 
> be sufficient for this?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

My example use case is pertinent to a collaboration environment. In such a 
case the web developer would handle the remote vs. local caret issues 
using our framework.

My point herein and motivation for the suggestion is that this 
functionality (get/set caret) is available in the textarea element. Using 
a textarea element you can get/set caret position via 
get/setSelectionRange(). These two methods should be implemented for a 
contentEditable div or the likes. Within a contentEditable div, there is 
no way to [a] tell where the caret is in relation to the text, such as the 
index; [b] direct the caret to a specific position within the text.

My assumptions is that such a request would be within the scope of the 
HTML Edit API spec. If I am mistaken, my apologies.

Dan Gisolfi

From rniwa at webkit.org  Fri Jul 29 11:14:40 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Fri, 29 Jul 2011 11:14:40 -0700
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF3175D5B4.23130152-ON852578DC.00628044-852578DC.00639B8D@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
	<OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
	<Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>
	<OF3175D5B4.23130152-ON852578DC.00628044-852578DC.00639B8D@us.ibm.com>
Message-ID: <CABNRm62hPRf6FDTBiGx1eTq9rmr+jdbs-_E22V0ZnX70h1wJ3A@mail.gmail.com>

On Fri, Jul 29, 2011 at 11:07 AM, Dan Gisolfi <gisolfi at us.ibm.com> wrote:
>
> My point herein and motivation for the suggestion is that this
> functionality (get/set caret) is available in the textarea element. Using
> a textarea element you can get/set caret position via
> get/setSelectionRange(). These two methods should be implemented for a
> contentEditable div or the likes. Within a contentEditable div, there is
> no way to [a] tell where the caret is in relation to the text, such as the
> index; [b] direct the caret to a specific position within the text.
>

So what you want is Range/Selection <-> TextIndex API?  I think that makes a
sense.  Ideally such an API provide an index of selection/range within the
textContent of the editing host.  WebKit already implements very similar
mechanism internally and use it extensively in editing, spell checking, and
IME code.

- Ryosuke

From Simetrical+w3c at gmail.com  Fri Jul 29 11:24:12 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 29 Jul 2011 14:24:12 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
Message-ID: <CAKA+AxnOuEro=bp3uR36=xcHMjT-ZwSRvZZgop89GqLBP7bLEw@mail.gmail.com>

On Fri, Jul 29, 2011 at 11:13 AM, Dan Gisolfi <gisolfi at us.ibm.com> wrote:
> On behalf of the Open Cooperative Web Framework Project
> (http://opencoweb.org), with respect to the HTML Editing APIs specification
> (http://aryeh.name/spec/editing/editing.html), it would seem the current
> version of the spec lacks APIs for getting / setting the caret
> position.

As far as I can tell, this is covered by the Selection interface in DOM Range:

http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface

Anne van Kesteren, Ms2ger, and I have agreed that it probably makes
sense to move the Selection part of DOM Range into the editing spec
and the Range part into DOM Core at some point, but for now it's in a
separate specification.

> An example scenario for such a requirement (addition of such methods) would
> be the following:
> When developing an cooperative web enabled rich-text-editor, whereby
> multiple simultaneous users can co-author shared content, the editor must be
> able to allow each participant to get/set caret/cursor position in order to
> reflect the multiple positions of each active author in a cooperative web
> session.

The Selection interface and getSelection() will allow you to inspect
and modify the selection (and cursor position, which is just one side
or other of the selection) of the current user, meaning the place that
will be affected when the user types or such.  Is this all you need,
or is there something missing from it?

On Fri, Jul 29, 2011 at 2:07 PM, Dan Gisolfi <gisolfi at us.ibm.com> wrote:
> My point herein and motivation for the suggestion is that this functionality
> (get/set caret) is available in the textarea element. Using a textarea
> element you can get/set caret position via get/setSelectionRange(). These
> two methods should be implemented for a contentEditable div or the likes.
> Within a contentEditable div, there is no way to [a] tell where the caret is
> in relation to the text, such as the index; [b] direct the caret to a
> specific position within the text.

getSelection() is very similar to the selectionStart, selectionEnd,
and setSelectionRange() properties on textareas.  It's more
complicated, though, because rich text is more complicated than plain
text.  Examples:

Collapse the selection and set the cursor to the beginning of a specific node:

  getSelection().collapse(node, 0)

Select characters three through five in a Text node, that's the first
child of a specific element:

  var range = document.createRange();
  range.setStart(element.firstChild, 3);
  range.setEnd(element.firstChild, 5);
  getSelection().removeAllRanges();
  getSelection().addRange(range);

Alternatively (simpler but does not work in some browsers):

  getSelection().collapse(element.firstChild, 3);
  getSelection().extend(element.firstChild, 5);

Retrieve the first range in the current selection:

  var range;
  if (getSelection().rangeCount) {
    // There is some cursor or selection
    range = getSelection().getRangeAt(0);
    // range is now a Range object that you can look at
  } else {
    // Nothing is selected and there is no cursor position
  }

If you see something missing from the Selection APIs that would be
useful to you, please say so.  This list is fine for feedback on DOM
Range.

From jkorpela at cs.tut.fi  Fri Jul 29 11:57:06 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Fri, 29 Jul 2011 21:57:06 +0300
Subject: [whatwg] sic element
In-Reply-To: <Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
Message-ID: <4E330282.2030404@cs.tut.fi>

29.07.2011 20:05, Ian Hickson wrote:

> The point is just
> that <u>  is used to explicitly annotate some text without saying why in a
> textual manner. This makes it quite distinct from [sic], which is an
> explicitly articulated annotation.

I fail to see how [sic] would be more explicit than underlining.

Anyway, aren't you saying that <u> says "this text is annotated but no 
annotation is given"? In that case, saying that <u> draws attention to 
its content might be more appropriate.

But the whole idea of transmogrifying the old <u> element, one of the 
simplest elements of traditional HTML, to some purportedly semantic 
element without saying what it _really_ means, is just doomed. Of 
course, it's not compatible with existing practice where <u> means 
underlining (and is therefore physical markup). But it also makes 
people's minds dizzy (to no avail) if they try to take the specs seriously.

I wonder what speech-based user agents are supposed to make out of <u>. 
The good old <u> is simple: you can either ignore it (saying that 
underlining has no recognizable meaning that could be conveyed in 
speech), or you can interpret it as some kind of emphasis, expressed by 
a change of voice somehow. But if the new <u> is supposed to be 
semantic, can it be ignored in speech? How do you express an explicit 
but completely unspecified "annotation"?

This really sounds like an odd game where HTML specs are meant to say to 
authors and to vendors of authoring software that they can keep using 
<u> as before (and pass validation), but when interrogated, they are 
supposed to tell that it does not mean underlining but... eh... explicit 
annotation without explicitly articulated annotation.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From chuck at jumis.com  Fri Jul 29 13:44:07 2011
From: chuck at jumis.com (Charles Pritchard)
Date: Fri, 29 Jul 2011 13:44:07 -0700
Subject: [whatwg] Canvas 2d: proposal to add path(DOMString)
Message-ID: <4E331B97.4010907@jumis.com>

Having spoken to several developers, I think that we're clear to add a 
new method to the canvas 2d api;
though there is some question about how it should be added.

The method would take a DOMString using SVG path semantics.

I'm not certain which route is better:
ctx.path('M....z')
or
ctx.fillPath('M ..z'), ctx.strokePath('M...z');

This usually takes ~80 lines of JavaScript to support,
we're eager to see it added to native implementations.

All browser vendors have SVG support now, and could easily re-use
code from their SVG implementations to implement this canvas 2d 
supplemental.


-Charles

From ayg at aryeh.name  Fri Jul 29 13:47:53 2011
From: ayg at aryeh.name (Aryeh Gregor)
Date: Fri, 29 Jul 2011 16:47:53 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
Message-ID: <CAKA+AxmVPg5yXV=Lo958ScZLX0pvKOLPVLWczyG7w5gNBnCMXA@mail.gmail.com>

On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> WebKit treats any font-weight above or equal to 600 as bold because that's
> what user sees, and boldness is a binary concept in execCommand; Firefox 5
> appears to do the same.
> WebKit compares colors in rgb/rgba format; e.g. red is first parsed as
> rgb(255, 0, 0). ?Firefox 5 seems to does the same as well.
> WebKit compares font sizes in legacy font size used in font element;
> See?CSSStyleSelector::legacyFontSize or?legacyFontSizeFromCSSValue in
> EditingStyle.cpp

Okay, I've now defined precisely how values have to be compared (in
two different ways), and painstakingly used them everywhere they're
necessary:

http://aryeh.name/tmp/editing/editing.html#equivalent-values

This should be well-defined now.

On Thu, Jul 28, 2011 at 4:31 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> WebKit fires those events :( ?I don't know why we do that. ?I think it's a
> WebKit bug but I'm just pointing that out in the case there are some
> websites out there that depends on this quirky behavior. ?Just
> cut/copy/paste for now as far as I know.

How do the cut/copy/paste commands work at all in WebKit?  I tried
using them but they did nothing.  queryCommandSupported() returns
false for all three.  Is there some special switch?

From ian at hixie.ch  Fri Jul 29 13:56:55 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 20:56:55 +0000 (UTC)
Subject: [whatwg] sic element
In-Reply-To: <4E330282.2030404@cs.tut.fi>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
Message-ID: <Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jukka K. Korpela wrote:
> 29.07.2011 20:05, Ian Hickson wrote:
> >
> > The point is just that <u> is used to explicitly annotate some text 
> > without saying why in a textual manner. This makes it quite distinct 
> > from [sic], which is an explicitly articulated annotation.
> 
> I fail to see how [sic] would be more explicit than underlining.

[sic] has an explicitly articulated meaning. Underlining, on the other 
hand, does not; it is an annotation but the reader cannot know, without 
context, what its meaning is.


> Anyway, aren't you saying that <u> says "this text is annotated but no 
> annotation is given"? In that case, saying that <u> draws attention to 
> its content might be more appropriate.

The physical line is an annotation. It's just not articulated.


> But the whole idea of transmogrifying the old <u> element, one of the 
> simplest elements of traditional HTML, to some purportedly semantic 
> element without saying what it _really_ means, is just doomed.

Doomed in what sense? If you are concerned that people are going to use it 
for a different meaning that it has, then the whole language suffers from 
this problem and so calling this one out specifically as "doomed" seems to 
be a case of missing the wood for the trees.


> I wonder what speech-based user agents are supposed to make out of <u>. 
> The good old <u> is simple: you can either ignore it (saying that 
> underlining has no recognizable meaning that could be conveyed in 
> speech), or you can interpret it as some kind of emphasis, expressed by 
> a change of voice somehow. But if the new <u> is supposed to be 
> semantic, can it be ignored in speech? How do you express an explicit 
> but completely unspecified "annotation"?

If it's ok if it's entirely ignored, then it's presentational, and not 
conveying any useful information.

If it isn't ignored, then clearly it doesn't mean "underline". Indeed, it 
means pretty much what HTML now says it does, and always has. A different 
voice, inflexion, auditory icons -- there are lots of ways of conveying 
this kind of thing in speech, just like there is in the visual medium.


> This really sounds like an odd game where HTML specs are meant to say to 
> authors and to vendors of authoring software that they can keep using 
> <u> as before (and pass validation), but when interrogated, they are 
> supposed to tell that it does not mean underlining but... eh... explicit 
> annotation without explicitly articulated annotation.

If you interpret the spec as saying that <u> is underline and it's fine to 
use it as before then you are misreading the spec.

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

From jkorpela at cs.tut.fi  Fri Jul 29 14:26:02 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sat, 30 Jul 2011 00:26:02 +0300
Subject: [whatwg] sic element
In-Reply-To: <Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
	<Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
Message-ID: <4E33256A.3030609@cs.tut.fi>

29.07.2011 23:56, Ian Hickson wrote:

>> Anyway, aren't you saying that <u>  says "this text is annotated but no
>> annotation is given"? In that case, saying that <u>  draws attention to
>> its content might be more appropriate.
>
> The physical line is an annotation. It's just not articulated.

I think you are using the word "annotation" to mean something different 
from "a note added by way of comment or explanation" 
(http://www.merriam-webster.com/dictionary/annotation). What would an 
annotation be without a note - without a comment or explanation?

>> But the whole idea of transmogrifying the old <u>  element, one of the
>> simplest elements of traditional HTML, to some purportedly semantic
>> element without saying what it _really_ means, is just doomed.
>
> Doomed in what sense?

People won't take it seriously or, perhaps worse still, some people 
think they understand it and will start using <u> for something they 
regard as annotations. This implies that the default rendering is 
underlined, creating confusion with links.

There's nothing to be gained from adopting this new semantics for <u>. 
The suggested semantics has no solid ground on which browsers or search 
engines or other software could build their actions on.

> If you are concerned that people are going to use it
> for a different meaning that it has, then the whole language suffers from
> this problem

I'm not really concerned that way - rather, redefinition of <u> is an 
unnecessary complication to the language. I'm more concerned that some 
people may actually try to use <u> by the spec and cause confusion.

> If it's ok if it's entirely ignored, then it's presentational, and not
> conveying any useful information.

Presentational markup may convey useful information, for example that a 
quotation from printed matter contains an underlined word. Underlining 
also has specialized usage e.g. in some transliteration systems.

> A different
> voice, inflexion, auditory icons -- there are lots of ways of conveying
> this kind of thing in speech, just like there is in the visual medium.

I can't imagine how e.g. different voice would convey the meaning of an 
"annotation" that does not attach any note to anything.

> If you interpret the spec as saying that <u> is underline and it's fine to
> use it as before then you are misreading the spec.

I'm saying that people will keep treating it as underline, except for 
some souls that will get confused and won't know what it is.

It would be _so_ much simpler to keep <u>, <i>, <b> as physical markup, 
like they have always been and will actually be used. If you wish to say 
that authors must not use them, then say so (but it won't have much 
effect). It seems that there's the issue of wanting to disallow them 
(because they're physical markup) and wanting to allow them (because 
programs generate them). That might be a tricky situation, but trying to 
rescue them by artificial redefinitions can't possibly be the right way.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From jonas at sicking.cc  Fri Jul 29 14:47:56 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 14:47:56 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>

On Fri, Jul 29, 2011 at 9:29 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> > On Mon, 9 May 2011, Mounir Lamouri wrote:
>> >>
>> >> Basically, when you want to use the datalist to suggest a few things
>> >> you might not want to filter and when the list is long, you very
>> >> likely want to filter.
>> >>
>> >> You might not want to filter when the list is a real set of
>> >> suggestions and you can type anything else. For example, a field in a
>> >> support form can ask you "What is your problem?" and you could type a
>> >> brief summary but some pre-written issues will be available. It's
>> >> equivalent to a select element followed by an input field that you
>> >> can use if you select "other" in the list. As I see it, when you
>> >> filter, you have a very long list and you very likely want the user
>> >> to select something in the list like a list of bugzilla emails, a
>> >> list o metro stations, etc. Writing anything not in the list might
>> >> not work.
>> >
>> > So why don't you just automatically filter if the list is long, and
>> > not filter if the list is short?
>>
>> I'm not a big fan of try-to-guess-what-the-author-wants-to-do solutions
>> like that. Guessing will likely be as often wrong and annoying as it
>> will be correct and helpful.
>
> Showing the user an autocomplete list with hundreds of entries is going to
> be far more annoying.
>
> This to me seems to be entirely a UI issue.

The problem is the other way around. When wanting to show a short list
that should be filtered based on user input.

/ Jonas

From jonas at sicking.cc  Fri Jul 29 14:51:44 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 14:51:44 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>

On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Mon, 2 May 2011, Jonas Sicking wrote:
>> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >> >
>> >> > <select> in a <datalist> is completely ignored for form submission. In
>> >> > fact, any form element at all in <datalist> is ignored for form
>> >> > submission. See the "construct the form data set" algorithm:
>> >> >
>> >> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
>> >> >
>> >> > It's so that you can do things like:
>> >> >
>> >> > ? <input ... list=options>
>> >> > ? <datalist id=options>
>> >> > ? ? <select ...>
>> >> > ? ? ? <option>...</option>
>> >> > ? ? </select>
>> >> > ? ? ...maybe other form controls here...
>> >> > ? </datalist>
>> >> >
>> >> > Basically everything in the <datalist> except the <option> elements is
>> >> > for fallback in legacy UAs and is ignored in new UAs.
>> >>
>> >> Couldn't this be accomplished using a few lines of javascript?
>> >
>> > Not when scripts are disabled, no.
>>
>> The number of cases when a site can use this solution to get an
>> acceptable UI *and* care about supporting users with scripts disabled
>> *and* is planning to roll out support within the timeframe when there's
>> some support for HTML5 forms, but not enough to rely on it, is extremely
>> small.
>
> That's possible. The entire Web Forms 2 feature set is designed with this
> kind of fallback in mind, though.
>
>
>> My experience is that it's much more likely that people will use other
>> solutions until there is wide enough browser support to reliably use it,
>> and then use javascript as a fallback and not care about users with JS
>> disabled. And that goes even if we add this feature or not.
>
> If that's the case, we should probably rethink the entire design of the
> WF2 features, because maybe there's better ways to do things.

I'd be very interested to hear how we would have designed things
differently under those constraints.

> Looking specifically at <datagrid>'s ability to fall back to <select>, I
> agree that it's not necessarily doing to be widely used, but given that
> it's so simple to support and provides such a clean way to do fallback, I
> really don't see the harm in supporting it.

I haven't looked at <datagrid> yet, so I can't comment.

/ Jonas

From Simetrical+w3c at gmail.com  Fri Jul 29 14:59:57 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 29 Jul 2011 17:59:57 -0400
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
Message-ID: <CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>

On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
>> Looking specifically at <datagrid>'s ability to fall back to <select>, I
>> agree that it's not necessarily doing to be widely used, but given that
>> it's so simple to support and provides such a clean way to do fallback, I
>> really don't see the harm in supporting it.
>
> I haven't looked at <datagrid> yet, so I can't comment.

I think he meant <datalist>.  <datagrid> was axed quite some time ago
and hasn't made a reappearance that I know of.

From jonas at sicking.cc  Fri Jul 29 15:20:59 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 15:20:59 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
Message-ID: <CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>

On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> Looking specifically at <datagrid>'s ability to fall back to <select>, I
>>> agree that it's not necessarily doing to be widely used, but given that
>>> it's so simple to support and provides such a clean way to do fallback, I
>>> really don't see the harm in supporting it.
>>
>> I haven't looked at <datagrid> yet, so I can't comment.
>
> I think he meant <datalist>. ?<datagrid> was axed quite some time ago
> and hasn't made a reappearance that I know of.

Ah, well, then it definitely seems like we should get rid of this
feature. The harm is definitely there in that it's adding a feature
without solving any problem.

For what it's worth, I'm not even convinced there is a problem. The
website can always let the <select> be submitted and ignore it on the
server if it contains a empty value, and then make the first <option>
in the <select> look something like <option value="">You can select a
prefilled value here</option>

/ Jonas

From ian at hixie.ch  Fri Jul 29 15:22:41 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 22:22:41 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> 
> The problem is the other way around. When wanting to show a short list 
> that should be filtered based on user input.

Why would it matter if the list is filtered or not when it's short?

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

From jonas at sicking.cc  Fri Jul 29 15:31:07 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 15:31:07 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>

On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>>
>> The problem is the other way around. When wanting to show a short list
>> that should be filtered based on user input.
>
> Why would it matter if the list is filtered or not when it's short?

Choosing something at the bottom of a 10 item list is likely about as
annoying as simply writing the whole email address manually and
ignoring the <datalist> feature completely.

Has any browsers implemented the UI you are suggesting? Is any planning to?

/ Jonas

From ian at hixie.ch  Fri Jul 29 15:39:09 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 22:39:09 +0000 (UTC)
Subject: [whatwg] sic element
In-Reply-To: <4E33256A.3030609@cs.tut.fi>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
	<Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
	<4E33256A.3030609@cs.tut.fi>
Message-ID: <Pine.LNX.4.64.1107292224070.18680@ps20323.dreamhostps.com>

On Sat, 30 Jul 2011, Jukka K. Korpela wrote:
> 29.07.2011 23:56, Ian Hickson wrote:
> > > 
> > > Anyway, aren't you saying that <u> says "this text is annotated but 
> > > no annotation is given"? In that case, saying that <u> draws 
> > > attention to its content might be more appropriate.
> > 
> > The physical line is an annotation. It's just not articulated.
> 
> I think you are using the word "annotation" to mean something different 
> from "a note added by way of comment or explanation" 
> (http://www.merriam-webster.com/dictionary/annotation). What would an 
> annotation be without a note - without a comment or explanation?

I was using it in the sense used in Wikipedia:

   "An annotation is a note that is made while reading any form of text. 
   This can be as simple as underlined or highlighted passages."
    -- http://en.wikipedia.org/wiki/Annotation

If you have a word that better conveys this meaning, I'd be happy to 
use that instead.


> > > But the whole idea of transmogrifying the old <u> element, one of 
> > > the simplest elements of traditional HTML, to some purportedly 
> > > semantic element without saying what it _really_ means, is just 
> > > doomed.
> > 
> > Doomed in what sense?
> 
> People won't take it seriously or, perhaps worse still, some people 
> think they understand it and will start using <u> for something they 
> regard as annotations. This implies that the default rendering is 
> underlined, creating confusion with links.

I don't think what you describe here is a big deal. People fail to take 
specs seriously all the time, or use things in confusing ways all the 
time. I don't think this particular example is any more or less egregious 
than anything else in the spec.


> There's nothing to be gained from adopting this new semantics for <u>.

Sure there is. Device independence, for one.


> The suggested semantics has no solid ground on which browsers or search 
> engines or other software could build their actions on.

The ground seems as solid here as for the vast majority of other elements 
in the specification.


> > If you are concerned that people are going to use it for a different 
> > meaning that it has, then the whole language suffers from this problem
> 
> I'm not really concerned that way - rather, redefinition of <u> is an 
> unnecessary complication to the language.

I disagree with the premise of that concern.


> I'm more concerned that some people may actually try to use <u> by the 
> spec and cause confusion.

I would be overjoyed if people followed the spec!

In this particular case, the redefinition is nothing of the sort. The 
definition is explicitly intended to actually match common practice and to 
match the only non-presentational use cases people could come up with for 
having the element be valid at all.


> > If it's ok if it's entirely ignored, then it's presentational, and not 
> > conveying any useful information.
> 
> Presentational markup may convey useful information, for example that a 
> quotation from printed matter contains an underlined word.

HTML is the wrong language for this kind of thing.


> Underlining also has specialized usage e.g. in some transliteration 
> systems.

Could you elaborate on this?


> > A different voice, inflexion, auditory icons -- there are lots of ways 
> > of conveying this kind of thing in speech, just like there is in the 
> > visual medium.
> 
> I can't imagine how e.g. different voice would convey the meaning of an 
> "annotation" that does not attach any note to anything.

Inflexion changes, pauses, changes in timbre, pitch, speed, and other 
aspects of one's voice, are the ways all meaning is conveyed in aural 
conversations. I don't see why it would be different for this case than 
for any other case.


> > If you interpret the spec as saying that <u> is underline and it's 
> > fine to use it as before then you are misreading the spec.
> 
> I'm saying that people will keep treating it as underline, except for 
> some souls that will get confused and won't know what it is.

Well sure, just like some people will keep treating <blockquote> as 
meaning "indent" and just like how some people will persist in failing to 
understand how scripting APIs work.

Personally I have more faith in authors.


> It would be _so_ much simpler to keep <u>, <i>, <b> as physical markup, 
> like they have always been and will actually be used. If you wish to say 
> that authors must not use them, then say so (but it won't have much 
> effect). It seems that there's the issue of wanting to disallow them 
> (because they're physical markup) and wanting to allow them (because 
> programs generate them). That might be a tricky situation, but trying to 
> rescue them by artificial redefinitions can't possibly be the right way.

I think you are confused as to the goals here. The presentational markup 
that was <u>, <i>, <b>, <font>, <small>, etc, is gone. However, there are 
certain use cases that did not yet have elements yet were important enough 
to warrant us supporting them. By reusing existing elements, we are able 
to support them without having to wait for new elements to be implemented. 
By doing so in a way that closely matches how those elements were actually 
used in practice (at least to the same extent as other elements have been 
correctly used in practice) we can not only have older UAs support these 
new elements automatically, but we can do so in a way that does not 
introduce an undue volume of invalid pages.

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

From ian at hixie.ch  Fri Jul 29 15:42:27 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 22:42:27 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
> >>
> >> The problem is the other way around. When wanting to show a short 
> >> list that should be filtered based on user input.
> >
> > Why would it matter if the list is filtered or not when it's short?
> 
> Choosing something at the bottom of a 10 item list is likely about as 
> annoying as simply writing the whole email address manually and ignoring 
> the <datalist> feature completely.

If 10 items is annoying, then it's not short.


> Has any browsers implemented the UI you are suggesting? Is any planning 
> to?

I've no idea. It's incredibly early days in terms of implementations of 
these features. We are still looking for better ways of implementing 
maxlength="", which is something like 15 years old now. It'd be a little 
premature to dismiss something so early on.

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

From jonas at sicking.cc  Fri Jul 29 16:08:32 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 16:08:32 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>

On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >>
>> >> The problem is the other way around. When wanting to show a short
>> >> list that should be filtered based on user input.
>> >
>> > Why would it matter if the list is filtered or not when it's short?
>>
>> Choosing something at the bottom of a 10 item list is likely about as
>> annoying as simply writing the whole email address manually and ignoring
>> the <datalist> feature completely.
>
> If 10 items is annoying, then it's not short.

You mean "long", right?

>> Has any browsers implemented the UI you are suggesting? Is any planning
>> to?
>
> I've no idea. It's incredibly early days in terms of implementations of
> these features. We are still looking for better ways of implementing
> maxlength="", which is something like 15 years old now. It'd be a little
> premature to dismiss something so early on.

The ability to configure UI has been one of the big problems with the
existing set of forms, and is one of the biggest concerns with the new
set of forms (in particular the complex widgets like date/time
pickers), so your argument that this particular aspect does not need
to be configurable from the page seems like something that needs some
backing up with more than opinions.

/ Jonas

From ian at hixie.ch  Fri Jul 29 16:24:23 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 23:24:23 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
> >> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
> >> >>
> >> >> The problem is the other way around. When wanting to show a short
> >> >> list that should be filtered based on user input.
> >> >
> >> > Why would it matter if the list is filtered or not when it's short?
> >>
> >> Choosing something at the bottom of a 10 item list is likely about as
> >> annoying as simply writing the whole email address manually and ignoring
> >> the <datalist> feature completely.
> >
> > If 10 items is annoying, then it's not short.
> 
> You mean "long", right?

No, I mean "short". I said that it shouldn't matter if you filter or not 
when the list is short. You said that a list with ten items was annoying. 
I'm arguing that that means the list is long, and thus not short, and 
thus should be filtered.

My overarching point, however, is that this is a UI issue, and not an 
authoring issue. Authors should be able to provide either a complete 
static list of autocomplete suggestions, or a shorter list of relevant 
suggestions based on the current user input. In both cases, the user agent 
should be able to prioritise and/or filter the given suggestions in 
whatever manner makes the lists most helpful to the user. Giving the 
author the ability to prevent the filtering altogether makes sense if the 
UA's filtering is not ideal, but it doesn't make sense to put in the 
standard, since it's not yet at all clear that an ideal filtering is 
simply impossible.

If, in the future, we find that it is in fact impossible for a UA to be 
clever enough to have good UI whether the list is static or dynamic, short 
or long, prefiltered or not, then it would make sense to study what 
further controls we can give authors. It would make a lot of sense to look 
at this at the same time as we look at other suggested augmentations here, 
such as the ability for script to provide prefiltered suggestions directly 
rather than having to manipulate DOM nodes to do so.


> >> Has any browsers implemented the UI you are suggesting? Is any 
> >> planning to?
> >
> > I've no idea. It's incredibly early days in terms of implementations 
> > of these features. We are still looking for better ways of 
> > implementing maxlength="", which is something like 15 years old now. 
> > It'd be a little premature to dismiss something so early on.
> 
> The ability to configure UI has been one of the big problems with the 
> existing set of forms, and is one of the biggest concerns with the new 
> set of forms (in particular the complex widgets like date/time pickers), 
> so your argument that this particular aspect does not need to be 
> configurable from the page seems like something that needs some backing 
> up with more than opinions.

I do not think the premise of this argument is correct.

Styling form controls has certainly been something we have failed to 
provide hooks for, but that's an orthogonal issue, IMHO, and should be 
resolved using some sort of widget binding solution, not more attributes 
in the language itself.

If we had a widget binding solution then authors with especially 
complicated needs could just override <input> and provide an 
implementation of the widget that did exactly what they wanted.

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

From jonas at sicking.cc  Fri Jul 29 17:08:37 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 17:08:37 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>
References: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>
Message-ID: <CA+c2ei_7Xt_HBba1iZ8hAXdW1tyqBpnbxmfB1PfZKiMR7qi6Uw@mail.gmail.com>

On Tue, Jul 26, 2011 at 11:34 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Hi all,
> In the last couple of weeks, I've been working with developers of CKEditor,
> TinyMCE, and Google Docs to come up with new API for undo and redo.
> Why? Because undo and redo are broken on the Web today. Whenever Web apps
> try to add a custom editing operation without using execCommand or do a "fix
> up" after browser executes a user editing action, user agents get confused
> by DOM mutations made by the apps and won't be able to undo or redo user
> editing actions and execCommand. This forces Web apps to re-implement undo
> and redo themselves, and in fact, many rich text editors store innerHTML of
> a contenteditable element as a string in their internal undo transaction
> history (a.k.a undo stack).
> Also, there's no way for Web apps to add new undo item and populate undo and
> redo menus on user agent's native UI. ?In addition, if an editor app has a
> widget with input/textarea, then the undo stack of the editor gets confused
> when the widget goes away because the undo transaction history exists only
> per document.
> In order to solve above and numerous other problems, we've come to a
> conclusion that we need to?add UndoManager and Transaction.
> UndoManager is an interface for managing undo transaction history. ?It
> exists on a document and an element with the undoscope content attribute.
> ?UndoManager applies new transaction (i.e. make undoable DOM changes) and
> manage them. ?The main purpose of UndoManager is to communicate the list of
> undoable items with the user agent so that the user agent can provide a
> native UI (e.g. populating menu items with them).
> A transaction is a collection of DOM mutations that can be applied,
> unapplied, or reapplied. UndoManager manages transactions and execute
> unapply and reapply upon undo and redo respectively.
> There are two types of DOM transactions:
>
> Managed transaction - the app supplies apply() and the user agent
> automatically takes care of undo and redo. It is compatible with user
> editing actions and editing commands, and allows Web apps to easily add new
> editing operations or fix up DOM after user editing actions or editing
> commands and still have the user agent manage the undo and redo.
> Manual transaction - the app supplies apply(), unapply(), and reapply()
> and?the app takes the full control of undo and redo. However, it is NOT
> compatible with user editing actions, editing commands, or managed
> transactions, meaning that, the user agents won't be able to undo or redo
> them. This transaction is useful for apps such as a?collaborative editor
> that implements domain-specific undo or redo.
>
> You can see more concrete definitions of UndoManager and Transaction at:
> https://rniwa.com/editing/undomanager.html and see a list of uses cases
> at?https://rniwa.com/editing/undomanager-usecases.html. ?The documents are
> incomplete and I need your feedback in order to refine details.

This is awesome and much more thought through than my proposal!

I really do like the undoscope attribute, that is something that is
definitely needed. But I think it should simply be a boolean
attribute, a'la disabled for example. It does seem undefined how it
interacts with the contenteditable attribute? I was thinking that
contenteditable would create a undoscope, unless there's an element
higher up in the tree which has an explicit undoscope attribute.

It does however seem to me that the proposal is unnecessarily complex
in a few areas:

Why is there a need for a 'reapply' action? How is it different from
the 'apply' action?

What is the purpose of the UndoManager.replace function and it's
replaceGroup argument? In general I'm not sure I fully understand
"transaction groups". Are they different from simply a set of
transactions which have been merged together such that they are
done/undone together?

Why expose explicit Transaction objects. What value does that provide?

Here is my updated proposal, which will surely need to be revised once
I understand the questions above better:

interface UndoManager {
  transaction(Function callback, optional in DOMString label, optional
in Boolean merge);
  manualTransaction(Function apply, Function unapply, optional in
DOMString label, optional in boolean merge);

  readonly attribute unsigned long position;
  readonly attribute unsigned long length;
  DOMString? labelAt(in unsigned long index);

  void undo();
  void redo();

  void clearUndo();
  void clearRedo();

  readonly Node host;
};

/ Jonas

From annevk at opera.com  Fri Jul 29 17:17:08 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 29 Jul 2011 17:17:08 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
	<CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
Message-ID: <op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>

On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking <jonas at sicking.cc> wrote:
> Ah, well, then it definitely seems like we should get rid of this
> feature. The harm is definitely there in that it's adding a feature
> without solving any problem.
>
> For what it's worth, I'm not even convinced there is a problem. The
> website can always let the <select> be submitted and ignore it on the
> server if it contains a empty value, and then make the first <option>
> in the <select> look something like <option value="">You can select a
> prefilled value here</option>

If we are removing the <select> fallback feature we should also change the  
way you find <option> elements for a <datalist> element I think. That  
should be aligned with <select>: A child element search rather than a  
descendant element search.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From jonas at sicking.cc  Fri Jul 29 17:19:52 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 17:19:52 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
	<CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
	<op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>
Message-ID: <CA+c2ei-5jxE+QCAWQfrcqW4_r7vQpJbcJpz80D=aHHuT2Lj_gA@mail.gmail.com>

On Fri, Jul 29, 2011 at 5:17 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> Ah, well, then it definitely seems like we should get rid of this
>> feature. The harm is definitely there in that it's adding a feature
>> without solving any problem.
>>
>> For what it's worth, I'm not even convinced there is a problem. The
>> website can always let the <select> be submitted and ignore it on the
>> server if it contains a empty value, and then make the first <option>
>> in the <select> look something like <option value="">You can select a
>> prefilled value here</option>
>
> If we are removing the <select> fallback feature we should also change the
> way you find <option> elements for a <datalist> element I think. That should
> be aligned with <select>: A child element search rather than a descendant
> element search.

Indeed!

/ Jonas

From rniwa at webkit.org  Fri Jul 29 17:40:05 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Fri, 29 Jul 2011 17:40:05 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CA+c2ei_7Xt_HBba1iZ8hAXdW1tyqBpnbxmfB1PfZKiMR7qi6Uw@mail.gmail.com>
References: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>
	<CA+c2ei_7Xt_HBba1iZ8hAXdW1tyqBpnbxmfB1PfZKiMR7qi6Uw@mail.gmail.com>
Message-ID: <CABNRm61PMikepKeuGH-nV9-SjKGunPQkrAf5i6Nuw685Wya2bQ@mail.gmail.com>

On Fri, Jul 29, 2011 at 5:08 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> I really do like the undoscope attribute, that is something that is
> definitely needed.


Yes. I've considered other possibilities such as letting scripts to manually
instantiate UndoManager objects, etc... but that turned out to require too
much work just to separate undo transaction histories of two editable
regions.


> It does seem undefined how it
> interacts with the contenteditable attribute? I was thinking that
> contenteditable would create a undoscope, unless there's an element
> higher up in the tree which has an explicit undoscope attribute.
>

I've thought this approach as well but this would break the backward
compatibility as the major browsers currently provide one undo transaction
history per document.  My proposal tries to decouple contenteditable and
undoscope so that if the apps were so desired, they can share the same undo
transaction history between multiple contenteditable regions.

My proposal, however, mentions the editing host when I define a "proper
sequence of managed transactions" in order to support co-existance of
managed and manual transactions.

 Why is there a need for a 'reapply' action? How is it different from
> the 'apply' action?
>

In the case of collaborative editing apps, reapply is different from apply
because the backend server may have a tree of transaction history and may
need to consult on demand in order to determine exactly what mutations have
to happen.

What is the purpose of the UndoManager.replace function and it's
> replaceGroup argument? In general I'm not sure I fully understand
> "transaction groups". Are they different from simply a set of
> transactions which have been merged together such that they are
> done/undone together?
>

Yeah, sorry about that.  I should clarify that part of the design.

*UndoManager.replace*
The key observation is that ManagedTransaction is constrained to work only
with a "proper sequence of managed transactions".  Whenever an app inserts a
manual transaction or directly mutates the DOM under the same editing host,
the UA won't be able to unapply/reapply the existing ManagedTransaction
created by user editing actions; i.e. inserting a manual transaction breaks
the existing managed transactions.  Without this constraint, however, the UA
is required to keep track of all DOM mutations happening in the undo scope
:(

Given this constraint, the apps that do use managed transactions such as
collaborative editing apps need to replace the managed transactions inserted
by the UA by the corresponding manual transaction when user types text.

*Transaction Group*
When a user types "hello", he isn't really typing all of "hello" at once but
rather inserting character "h", "e", "l", "l", and "o", letting the UA
insert each letter as a separate managed transaction in the order.  However,
when the user undoes or redoes this typing command, the entire "hello" needs
to removed.  This is accomplished as grouping 5 managed transactions for
inserting "h", "e", "l", "l", and "o" as a transaction group.

Why expose explicit Transaction objects. What value does that provide?
>

I admit this is more of stylistic issue rather than the technical limitation
but given a transaction already has label and apply "properties", it seemed
more natural for it to be an object.  That'll allow us to add more
properties in the future.

In particular, I really wanted to provide a mutation list as discussed on
the mutation events replacement thread on public-webapps.  This allows apps
to determine which transaction did what without having to listening to each
mutation event, and makes it easier to replace managed transactions by
manual transactions as described above.

- Ryosuke

From svartman95 at gmail.com  Fri Jul 29 18:53:52 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sat, 30 Jul 2011 01:53:52 +0000
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
	<CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
Message-ID: <CAOKKrgNc1KKfkdDn33shwz4Qxrx=hG1hfmkVSPxc0Gdgh89eTA@mail.gmail.com>

On 7/11/11, Sean Connelly <sean at pbwhere.com> wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the <input type="password"> field, and create my own field that reads
> characters (perhaps via onkeyup), and fakes a password field visually.
>
Fair point. I also worry about attackers removing a form and inserting
their own, or even positioning their own over the old one - if they
manage to gather enough information about the victim's UA or if the
form of a password input is consistently positioned.

> I also think it's a bad idea to change the behavior of <input
> type="password"> because it will break websites that assumed they could read
> the value.  Perhaps a website checks against a user's past 10 passwords to
> see if they are using the same one, via XHR.  Or perhaps the entire login
> process is XHR.  Who knows.
>
So there are two use cases for reading user passwords:
 * client side password strength indicators
 ** telling users if their passwords conform to site specific password
restrictions
  - arguably bad practice
  - IMO better achieved with declared regular expressions
 ** generally informing users of the computing needed to brute force
their password open, and if it's in a dictionary
  -- fetching a dictionary from each site is impractical (and thus
only implementable by UAs)
  -- can be implemented by UAs without "braking" sites that work if
laid out in the same way as the author's UA with floating overlays
that appear only while the password input is focused and has input
 * XHR submit
  - Could forms be targeted to a new browsing context and the server
return a HTTP 204 response instead?
  - Are implementors willing to display a more prominent notice of the
status of the submit (e.g. the text "Submitting" under a spin-wheel,
and then the Reason-Phrase of the request colored or on a background
colored to convey the status code)?

> I think there is definite room for improvements in security when it comes to
> <input type="password">, and I've also been trying to make it more secure by
> designing some sort of client-side hashing.  But I don't think restricting
> JavaScript from reading the value is a security benefit... in my opinion, it
> would just be a hassle for developers who need to read the value, and force
> them to use another means of password entry where they can read the value.
>
I don't think anyone but the receiving server should be able to read
my password. This is one of the reasons some people disable
JavaScript. Most don't, as they don't want to stop JavaScripts from
doing other more useful things. If we disable just stuff like this we
can bring some security to the folks that have JavaScript enabled
(such as me).

> On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor
> <Simetrical+w3c at gmail.com>wrote:
>
>> On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
>> > with a XHR I can send that password somewhere it shouldn't go... (well,
>> with
>> > cross-domain security code, maybe not, but that's not the point.)
Are XHR submits of passwords common and important enough to outweigh
the security cost of scripts having access to all passwords in their
document(s)?

>>
>> You can send it anyway by changing the action attribute on the form
>> and calling submit().  So what attack scenario are you actually
>> avoiding here?  You'd need a really strong security benefit for it to
>> be possible to even contemplate breaking so many websites.
>>
I propose disallowing changing the action attribute of forms with
password inputs. That is, if we manage to squash all the other obvious
ways a script can compromise the security of a typed password. This
seems to involve a lot of tedious allowance of this and that to be
done to forms, except if you throw in a password input. I'm not to
judge if it's worth it.

From jonas at sicking.cc  Fri Jul 29 19:08:57 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 19:08:57 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
	<Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>

On Fri, Jul 29, 2011 at 4:24 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >> >>
>> >> >> The problem is the other way around. When wanting to show a short
>> >> >> list that should be filtered based on user input.
>> >> >
>> >> > Why would it matter if the list is filtered or not when it's short?
>> >>
>> >> Choosing something at the bottom of a 10 item list is likely about as
>> >> annoying as simply writing the whole email address manually and ignoring
>> >> the <datalist> feature completely.
>> >
>> > If 10 items is annoying, then it's not short.
>>
>> You mean "long", right?
>
> No, I mean "short". I said that it shouldn't matter if you filter or not
> when the list is short. You said that a list with ten items was annoying.
> I'm arguing that that means the list is long, and thus not short, and
> thus should be filtered.
>
> My overarching point, however, is that this is a UI issue, and not an
> authoring issue. Authors should be able to provide either a complete
> static list of autocomplete suggestions, or a shorter list of relevant
> suggestions based on the current user input. In both cases, the user agent
> should be able to prioritise and/or filter the given suggestions in
> whatever manner makes the lists most helpful to the user. Giving the
> author the ability to prevent the filtering altogether makes sense if the
> UA's filtering is not ideal, but it doesn't make sense to put in the
> standard, since it's not yet at all clear that an ideal filtering is
> simply impossible.
>
> If, in the future, we find that it is in fact impossible for a UA to be
> clever enough to have good UI whether the list is static or dynamic, short
> or long, prefiltered or not, then it would make sense to study what
> further controls we can give authors. It would make a lot of sense to look
> at this at the same time as we look at other suggested augmentations here,
> such as the ability for script to provide prefiltered suggestions directly
> rather than having to manipulate DOM nodes to do so.

I have no idea how the UA would be smart enough to figure out if
filtering makes sense or not based on the set of suggestions. As far
as I can see this requires very complex AI which is able to analyze
the set of suggestions and see if they are contextual to the entered
value or not. Granted, the recent IBM computer Watson did a pretty
good job at this on Jeopardy a few months ago, but I think that we're
decades from having that amount of computational complexity at our
disposal when filtering autocomplete suggestions. I'd be nice if
<datalist> was a viable solution before then.

>> >> Has any browsers implemented the UI you are suggesting? Is any
>> >> planning to?
>> >
>> > I've no idea. It's incredibly early days in terms of implementations
>> > of these features. We are still looking for better ways of
>> > implementing maxlength="", which is something like 15 years old now.
>> > It'd be a little premature to dismiss something so early on.
>>
>> The ability to configure UI has been one of the big problems with the
>> existing set of forms, and is one of the biggest concerns with the new
>> set of forms (in particular the complex widgets like date/time pickers),
>> so your argument that this particular aspect does not need to be
>> configurable from the page seems like something that needs some backing
>> up with more than opinions.
>
> I do not think the premise of this argument is correct.
>
> Styling form controls has certainly been something we have failed to
> provide hooks for, but that's an orthogonal issue, IMHO, and should be
> resolved using some sort of widget binding solution, not more attributes
> in the language itself.
>
> If we had a widget binding solution then authors with especially
> complicated needs could just override <input> and provide an
> implementation of the widget that did exactly what they wanted.

Are you suggesting that filter/no-filter should be selected using CSS?
That seems outside of what CSS currently does anywhere.

/ Jonas

From ian at hixie.ch  Fri Jul 29 20:32:12 2011
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 30 Jul 2011 03:32:12 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
	<Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
	<CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107300327010.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> 
> I have no idea how the UA would be smart enough to figure out if 
> filtering makes sense or not based on the set of suggestions.

You could do something like:

 - if there are 7 or fewer suggestions, show them all.
 - if filtering reduces the list to 1 to 7 suggestions, show those.
 - if there's some way to prioritise the filtered list, show the 7 best 
   results from the filtered list.
 - otherwise, show everything.

Exactly how the filtering is done can vary, in a way similar to how 
autocomplete dropdowns in browser location bars have pretty involved 
heuristics for figuring out how to filter to a few results.


> Are you suggesting that filter/no-filter should be selected using CSS? 
> That seems outside of what CSS currently does anywhere.

No, I'm saying it should be done using XBL or its successor.

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

From jonas at sicking.cc  Fri Jul 29 20:48:32 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 20:48:32 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107300327010.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
	<Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
	<CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>
	<Pine.LNX.4.64.1107300327010.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei-f1Om=Nr0BLXdWV8PHkqVopL+wf_daroTFR8C7mjc-9Q@mail.gmail.com>

On Fri, Jul 29, 2011 at 8:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>>
>> I have no idea how the UA would be smart enough to figure out if
>> filtering makes sense or not based on the set of suggestions.
>
> You could do something like:
>
> ?- if there are 7 or fewer suggestions, show them all.
> ?- if filtering reduces the list to 1 to 7 suggestions, show those.
> ?- if there's some way to prioritise the filtered list, show the 7 best
> ? results from the filtered list.
> ?- otherwise, show everything.

I assume it's a bug in the above suggestion that if filtering results
in more than 7 results, we'd show everything, rather than just the
filtered result?

If so, this basically comes down to "filter if it's more than 7,
otherwise don't filter". These sort of magic limits is exactly the
type of things that authors are going to end up butting up against and
are going to want to configure.

I don't see a way that HTML5 currently provides enough data to do any
useful prioritization.

> Exactly how the filtering is done can vary, in a way similar to how
> autocomplete dropdowns in browser location bars have pretty involved
> heuristics for figuring out how to filter to a few results.

Yes, but we have a *lot* more data available to do that filtering and
sorting, compared to just the plain value that we have available for
<datalist>.

/ Jonas

From cam at mcc.id.au  Sat Jul 30 00:51:15 2011
From: cam at mcc.id.au (Cameron McCormack)
Date: Sat, 30 Jul 2011 00:51:15 -0700
Subject: [whatwg] link.sizes and [PutForwards=value]
In-Reply-To: <Pine.LNX.4.64.1107290107420.2079@ps20323.dreamhostps.com>
References: <4CB709B6.5040706@helsinki.fi>
	<op.vkl8act164w2qv@anne-van-kesterens-macbook-pro.local>
	<4CB88535.9070007@helsinki.fi>
	<Pine.LNX.4.64.1101050126330.29066@ps20323.dreamhostps.com>
	<4D2444C8.8040502@gmail.com>
	<Pine.LNX.4.64.1105022326190.19153@ps20323.dreamhostps.com>
	<BANLkTi=me4SCesFWo-QM8tc2J8whmO=jmA@mail.gmail.com>
	<BANLkTin_kiRTHBZ5zHyLRQECHq5QVSoXbQ@mail.gmail.com>
	<Pine.LNX.4.64.1107290107420.2079@ps20323.dreamhostps.com>
Message-ID: <4E33B7F3.8070006@mcc.id.au>

Jumping in the middle of this thread to pick up on one aspect...

On 28/07/11 6:15 PM, Ian Hickson wrote:
> Are we really concerned about objects stringifying to "[Object Foo]"?
>
> It seems that the usefulness of such stringification is far outweighed by
> the usefulness of being able to treat the attribute as a string attribute
> like any other reflecting attribute while also being able to use methods
> on it. In fact, it is consistent with every DOMString attribute: they
> don't stringify to "[Object String]", yet you can call methods on them.
> What's the difference?

There is a disadvantage.  In JS, doing a comparison between two objects, 
regardless of whether they have custom stringification behaviour, will 
compare based on object identity and not the string.

<!DOCTYPE html>
<iframe id=x src=b.html></iframe>
<iframe id=y src=b.html></iframe>
<script>
window.onload = function() {
   var xw = document.getElementById("x").contentWindow;
   var yw = document.getElementById("y").contentWindow;
   alert([xw.location, yw.location,
           xw.location == yw.location].join("\n"));
};
</script>

The two Location objects stringify to the same thing, but are not ==.  I 
think this can be confusing.

From cam at mcc.id.au  Sat Jul 30 00:58:22 2011
From: cam at mcc.id.au (Cameron McCormack)
Date: Sat, 30 Jul 2011 00:58:22 -0700
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <4E3213EB.8020508@mit.edu>
References: <4DDFF77F.9050605@mit.edu>	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>	<4DFB8783.7070802@mit.edu>
	<4DFB8C23.7070808@mit.edu>	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>	<4DFB9F2D.3070404@mit.edu>	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
	<4E3213EB.8020508@mit.edu>
Message-ID: <4E33B99E.4080100@mcc.id.au>

On 28/07/11 6:59 PM, Boris Zbarsky wrote:
> Why, exactly? I thought for SVG the "evt" thing was only relevant for
> content attributes, not IDL attributes.

That's right.  (Maybe Anne meant the Function used internally for the 
content attribute?)

From annevk at opera.com  Sat Jul 30 05:52:02 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Sat, 30 Jul 2011 14:52:02 +0200
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <4E33B99E.4080100@mcc.id.au>
References: <4DDFF77F.9050605@mit.edu>
	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>
	<4DFB8783.7070802@mit.edu> <4DFB8C23.7070808@mit.edu>
	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>
	<4DFB9F2D.3070404@mit.edu>
	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
	<4E3213EB.8020508@mit.edu> <4E33B99E.4080100@mcc.id.au>
Message-ID: <op.vzfnc0rw64w2qv@annevk-macbookpro.local>

On Sat, 30 Jul 2011 09:58:22 +0200, Cameron McCormack <cam at mcc.id.au>  
wrote:
> On 28/07/11 6:59 PM, Boris Zbarsky wrote:
>> Why, exactly? I thought for SVG the "evt" thing was only relevant for
>> content attributes, not IDL attributes.
>
> That's right.  (Maybe Anne meant the Function used internally for the  
> content attribute?)

I meant that this is something that needs addressing if content attributes  
apply to all elements, but it looks like we are not going to do that for  
now.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From annevk at opera.com  Sat Jul 30 06:08:31 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Sat, 30 Jul 2011 15:08:31 +0200
Subject: [whatwg] Reconcile document.URL and document.documentURI?
In-Reply-To: <op.vxr3nkca64w2qv@anne-van-kesterens-macbook-pro.local>
References: <op.vxr3nkca64w2qv@anne-van-kesterens-macbook-pro.local>
Message-ID: <op.vzfn4hev64w2qv@annevk-macbookpro.local>

On Tue, 28 Jun 2011 11:07:58 +0200, Anne van Kesteren <annevk at opera.com>  
wrote:
> Is there a way we can make these consistent somehow? Maybe move  
> document.documentURI to Web Applications 1.0? With createHTMLDocument()  
> I get these results:
>
>          document.URL         document.documentURI
> Gecko   "about:blank"        "about:blank"
> Chrome  ""                   null
> Opera   script document URL  null
> Safari  ""                   null
>
> Only Opera seems to conform here for document.URL which I think means  
> the specification should change. I kind of prefer what Gecko is doing  
> here. Not having the strange null-ability of attributes that take URLs  
> and simply (with apologies to hsivonen) use about:blank.
>
> I also found that both Opera and Gecko throw for setting  
> document.documentURI. Maybe we should take that opportunity and make it  
> readonly (or nuke it entirely, if that is feasible).
>
> For DOM Core this is http://www.w3.org/Bugs/Public/show_bug.cgi?id=13045

I moved document.URL to DOM Core, made document.documentURI readonly, and  
have them both return the same URL concept, which defaults to  
"about:blank".


-- 
Anne van Kesteren
http://annevankesteren.nl/

From jkorpela at cs.tut.fi  Sat Jul 30 06:58:19 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sat, 30 Jul 2011 16:58:19 +0300
Subject: [whatwg] sic element
In-Reply-To: <Pine.LNX.4.64.1107292224070.18680@ps20323.dreamhostps.com>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
	<Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
	<4E33256A.3030609@cs.tut.fi>
	<Pine.LNX.4.64.1107292224070.18680@ps20323.dreamhostps.com>
Message-ID: <4E340DFB.8010206@cs.tut.fi>

30.07.2011 01:39, Ian Hickson wrote:

> On Sat, 30 Jul 2011, Jukka K. Korpela wrote:
>> 29.07.2011 23:56, Ian Hickson wrote:
>>>>
>>>> Anyway, aren't you saying that<u>  says "this text is annotated but
>>>> no annotation is given"? In that case, saying that<u>  draws
>>>> attention to its content might be more appropriate.
>>>
>>> The physical line is an annotation. It's just not articulated.
>>
>> I think you are using the word "annotation" to mean something different
>> from "a note added by way of comment or explanation"
>> (http://www.merriam-webster.com/dictionary/annotation). What would an
>> annotation be without a note - without a comment or explanation?
>
> I was using it in the sense used in Wikipedia:
>
>     "An annotation is a note that is made while reading any form of text.
>     This can be as simple as underlined or highlighted passages."
>      -- http://en.wikipedia.org/wiki/Annotation
>
> If you have a word that better conveys this meaning, I'd be happy to
> use that instead.

I don't think Wikipedia can be relied on as indicative of meanings of 
words. International specifications should use English words in their 
meanings as described in dictionaries (or use them as technical terms 
for which exact definitions are given).

Since <u> as such lacks any comment or explanation, I think the wording 
"draws attention to" describes the intended meaning.

>> There's nothing to be gained from adopting this new semantics for <u>.
>
> Sure there is. Device independence, for one.

I mentioned that there is no obvious, intuitively understandable way of 
rendering <u>. This includes all devices. Maybe it's device independent, 
but only in the sense that there is no natural implementation for any 
device - but of course visual browsers will keep underlining it, but 
this just means that the real meaning is "underline".

>> Presentational markup may convey useful information, for example that a
>> quotation from printed matter contains an underlined word.
>
> HTML is the wrong language for this kind of thing.

Such things have been possible in HTML since the beginning. What's the 
tangible benefit of telling authors that they must not do so?

>> Underlining also has specialized usage e.g. in some transliteration
>> systems.
>
> Could you elaborate on this?

For example, a few transliteration systems use underlining of letters or 
letter pairs, see http://transliteration.eki.ee/pdf/Arabic_2.2.pdf
(and before saying that combining underline characters be used instead, 
please try to see whether it actually works and how convenient it is).

> Inflexion changes, pauses, changes in timbre, pitch, speed, and other
> aspects of one's voice, are the ways all meaning is conveyed in aural
> conversations.

All meaning? Hardly. Sounds matter, too. But the point is that no such 
method is intuitively recognized as meaning what you want <u> to mean. 
Besides, people who use speech browsers on a daily basis (as opposite to 
developers who use them for testing) have told me that nuances are 
inevitably lost - the speech rate is high (it takes time to learn to 
listen to it, but it's more or less necessary). So even if there is some 
subtle change, different from those already in established use (for a 
user base), it hardly gets noticed at all, still less understood as 
meaning something specific.

> Well sure, just like some people will keep treating <blockquote>  as
> meaning "indent" and just like how some people will persist in failing to
> understand how scripting APIs work.

Undoubtedly, and <blockquote> is effectively a lost cause. But the <u> 
issue (as well as <i> and <b>) is about creating new problems.

> I think you are confused as to the goals here. The presentational markup
> that was <u>,<i>,<b>,<font>,<small>, etc, is gone.

It hasn't gone anywhere and won't go anywhere, and specs cannot change 
this. The reason why <font> has become less common has little to do with 
its "deprecation" - rather, authors have moved to using CSS because it's 
more powerful and more convenient to use in most cases. The simple 
elements like <u> have clumsy CSS counterparts

> However, there are
> certain use cases that did not yet have elements yet were important enough
> to warrant us supporting them.

Was this based on an analysis of needs for semantic markup, or rather on 
trying to assign meanings that would be somehow compatible with the 
default rendering implications? I think the latter. And this means that 
some semantic needs were more or less _invented_ rather than recognized.

> By reusing existing elements, we are able
> to support them without having to wait for new elements to be implemented.

Several new elements have been added without such concerns. Any new 
semantic elements can be reasonable well used by authors if they add a 
few CSS rules and use the document.createElement() trick to make even IE 
style unknown elements.

> By doing so in a way that closely matches how those elements were actually
> used in practice (at least to the same extent as other elements have been
> correctly used in practice) we can not only have older UAs support these
> new elements automatically, but we can do so in a way that does not
> introduce an undue volume of invalid pages.

Either <u> means the same as before, or it means something else. You 
seem to be saying that it means almost the same, but is the difference 
between physical markup and semantic markup really that small?

Your last statement suggests that you really want to call existing usage 
of <b> as "valid" without really caring about how it is used (as 
physical markup or something else). All this "validity" issue is rather 
artificial, since the vast majority of web pages aren't valid even under 
the fairly trivial (pure-syntax, and even just the DTD-definable part 
thereof) meaning for "valid".

One does not need to be particularly pessimistic to predict that pages 
using <!doctype> won't generally meet even the syntactic requirements, 
still less the semantic definitions. This is something we can well live 
with, and the requirements on user agents and error processing are 
supposed to keep things that way. So why worry about some pages not 
being "valid" in the simple sense of using physical markup that has been 
defined in HTML (with requirements on browsers to keep supporting it) 
but declared forbidden?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

From jeremy at adactio.com  Sun Jul 31 11:45:14 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Sun, 31 Jul 2011 19:45:14 +0100
Subject: [whatwg] Why children of datalist elements are barred from
	constraint validation?
In-Reply-To: <CA+c2ei-5jxE+QCAWQfrcqW4_r7vQpJbcJpz80D=aHHuT2Lj_gA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
	<CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
	<op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>
	<CA+c2ei-5jxE+QCAWQfrcqW4_r7vQpJbcJpz80D=aHHuT2Lj_gA@mail.gmail.com>
Message-ID: <3656E9D6-2D07-412C-92AE-F499DCF0A7D3@adactio.com>

The way that datalist is currently designed (and implemented) is exemplary. The fact that (by design) it allows authors to nest a select element within it that shares the same option elements means that authors can safely begin to use this new feature.

I've written more about it here: http://adactio.com/journal/4272/

I'm trying (and failing) to understand why Jonas wants this feature removed.

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From kangax at gmail.com  Sun Jul 31 18:58:31 2011
From: kangax at gmail.com (Juriy Zaytsev)
Date: Sun, 31 Jul 2011 21:58:31 -0400
Subject: [whatwg] Canvas 2d: proposal to add path(DOMString)
In-Reply-To: <4E331B97.4010907@jumis.com>
References: <4E331B97.4010907@jumis.com>
Message-ID: <CAPdhPzmyBMUaj_Cia-PiKcMp48_NJ-czqXfLKV9GmsZTGqzWDQ@mail.gmail.com>

I'd love to see something like this as well.

In my experience this takes more than 80 lines. In Fabric.js [1], for
example, `fabric.Path#render` has ~180 LOC chunk [2] dedicated to doing
exactly this ? drawing translated-from-SVG path using a combination of
`lineTo`, `moveTo`, `bezierCurveTo`, etc. And that's not counting another
~100 lines of arc normalization [3] where arc command is translated to a
sequence of `bezierCurveTo` commands (due to SVG's a/A algorithms being so
different from canvas' `arc` one).

`HTMLRenderingContext::path` seems sufficient since it's always possible to
end it with `fill` or `stroke` (the same way you would do it with
combination of path commands followed by `fill` or `stroke`).

[1] http://kangax.github.com/fabric.js/demos/kitchensink/
[2]
https://github.com/kangax/fabric.js/blob/gh-pages/src/path.class.js#L247-433
[3]
https://github.com/kangax/fabric.js/blob/gh-pages/src/path.class.js#L17-121

-- 
kangax


On Fri, Jul 29, 2011 at 4:44 PM, Charles Pritchard <chuck at jumis.com> wrote:

> Having spoken to several developers, I think that we're clear to add a new
> method to the canvas 2d api;
> though there is some question about how it should be added.
>
> The method would take a DOMString using SVG path semantics.
>
> I'm not certain which route is better:
> ctx.path('M....z')
> or
> ctx.fillPath('M ..z'), ctx.strokePath('M...z');
>
> This usually takes ~80 lines of JavaScript to support,
> we're eager to see it added to native implementations.
>
> All browser vendors have SVG support now, and could easily re-use
> code from their SVG implementations to implement this canvas 2d
> supplemental.
>
>
> -Charles
>

From hallvord at opera.com  Sun Jul 31 23:29:27 2011
From: hallvord at opera.com (Hallvord R. M. Steen)
Date: Mon, 01 Aug 2011 08:29:27 +0200
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
 implementer feedback
In-Reply-To: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
Message-ID: <op.vziuzdqga3v5gv@hr-opera.oslo.opera.com>

On Thu, 28 Jul 2011 01:51:31 +0200, Ryosuke Niwa <rniwa at webkit.org> wrote:

> The return value of queryCommandEnable depends on beforecut, beforecopy,  
> and beforepaste events and selection state in WebKit;

This is actually a use case for before* events I wasn't aware of.  
Interesting. I guess you've taken this behaviour from IE? It seems a bit  
complicated though, in the sense that if the script knows some condition  
that means copy/cut/paste should not be available, listening for an event  
to cancel it is a bit of a convoluted way to make that logic available to  
other parts of the script. But then, I guess using same way to communicate  
state to the browser's UI and to other scripts is simplifying.

(I still haven't added anything about before* events to the CCnP spec,  
because I'm unsure if they are used and whether they are a nice way to  
solve the use case.)

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

From simonp at opera.com  Fri Jul  1 01:26:52 2011
From: simonp at opera.com (Simon Pieters)
Date: Fri, 01 Jul 2011 10:26:52 +0200
Subject: [whatwg] Using footer in blockquote for attribution
In-Reply-To: <BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>
	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
Message-ID: <op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>

On Thu, 30 Jun 2011 22:56:11 +0200, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> On Thu, Jun 30, 2011 at 11:50 AM, Oli Studholme <whatwg.org at boblet.net>  
> wrote:
>> <blockquote>
>>  <p>[block quote]</p>
>>  <footer>? <cite><a href="?">[title of work]</a></cite></footer>
>> </blockquote>
>
> This is incorrect according to the current definition of <footer>.
>
>> Footer definition:
>>  ?The footer element represents a footer for its nearest ancestor
>> sectioning content or sectioning root element. A footer typically
>> contains information about its section such as who wrote it, links to
>> related documents, copyright data, and the like.?
>
> This means it's tied to the nearest <section> or <article> or such.
> It's not supposed to be specifically related to any other type of
> ancestor, like <blockquote>.

<blockquote> is sectioning root.

>> Simon felt that ?Content inside a blockquote must be quoted from
>> another source? excludes footer.

s/footer/attribution/

Indeed since it's a conformance requirement, in valid documents the  
content inside blockquote is quoted from another source. If the spec were  
to allow attribution inside blockquote, the above conformance requirement  
would need to be changed to allow it.


>> However the footer definition reads
>> to me that footer is basically metadata *about* content (the
>> non-footer or -header content of the sectioning or sectioning root
>> element).
>
> Correct, but it's supposed to be metadata about the whole section, not
> about just its parent.
>
> However, I don't know if there's any specific way to mark this up.
> It's a common pattern, so it would be a good candidate for adding
> here:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#common-idioms-without-dedicated-elements
>
> It's useful to be able to put the author info in its own element so
> that you can style it differently.


-- 
Simon Pieters
Opera Software


From acolwell at google.com  Fri Jul  1 07:51:57 2011
From: acolwell at google.com (Aaron Colwell)
Date: Fri, 1 Jul 2011 07:51:57 -0700
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
Message-ID: <CAA0c1bBkbYh1dSbBQUWsRF1ChL_VBRkXfhjnwh72MkMAfTfMGg@mail.gmail.com>

Hi Robert,

comments inline.

On Thu, Jun 30, 2011 at 4:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Jul 1, 2011 at 4:59 AM, Aaron Colwell <acolwell at google.com> wrote:
>
>> I've also been looking at the WebRTC MediaStream API and was wondering if
>> it
>> makes more sense to create an object similar to the LocalMediaStream
>> object.
>> This has the benefits of unifying how media streams are handled
>> independent
>> of whether they come from a camera or a JavaScript based streaming
>> algorithm. This could also enable sending the media stream through a
>> Peer-to-peer connection instead of only allowing a camera as a source.
>> Here
>> is an example of the type of object I'm talking about.
>>
>
> I think MediaStreams should not be dealing with compressed data except as
> an optimization when access to decoded data is not required anywhere in the
> stream pipeline. If you want to do processing of decoded stream data (which
> I do --- see
> http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html),
> then introducing a decoder inside the stream processing graph creates all
> sorts of complications.
>
> Nice spec. If I understand correctly, your position is that MediaStreams
should only represent uncompressed media? In the case of camera/mic data
they represent the uncompressed bits before they go to the codec for
transmission over a PeerConnection or before they are rendered by a
<audio>/<video>. In the case of standard <audio>/<video> playback they would
represent the uncompressed audio before it is sent to the audio card and the
uncompressed video before it is blitted on the screen. From a stream
processing point of view I can see how this makes sense.  I was just
thinking that LocalMediaStream is just a wrapper around a source of media
data and all I was doing was providing a mechanism to provide media data
from JavaScript instead of from hardware.

I think the natural way to support the functionality you're looking for is
> to extend the concept of Blob URLs. Right now you can create a binary Blob,
> mint a URL for it and set that URL as the source for a media element. The
> only extension you need is the ability to append data to the Blob while
> retaining the same URL; you would need to initially mark the Blob as "open"
> to indicate to URL consumers that the data stream has not ended. That
> extension would be useful for all sorts of things because you can use those
> Blob URLs anywhere. An alternative would be to create a new kind of object
> representing an appendable sequence of Blobs and create an API to mint URLs
> for it.
>

> I thought about that, but I saw an earlier WHATWG thread<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032221.html> which
lead me down this MediaStream path. Using MediaStreams made more sense to me
because my use case felt similar to the live capture case except that I'm
using compressed media and it comes from JavaScript instead of hardware.
Also MediaStream already had a way to pass stream URLs to <audio> & <video>
for camera and remote peer stream data so I figured I could just leverage
that.


> Note that with my API proposal above, you can get a MediaStream from a
> media element that's using any URL and send that through a PeerConnection.
>
 I see that. Interactions with PeerConnection were not a primary concern for
me. I was only mentioning it as a side benefit of using MediaStream.

Thanks for your comments. I appreciate them.

Aaron


From acolwell at google.com  Fri Jul  1 07:58:11 2011
From: acolwell at google.com (Aaron Colwell)
Date: Fri, 1 Jul 2011 07:58:11 -0700
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <BANLkTikTj0uOXrDstnoLvfhgWz1jvSqffA@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
	<BANLkTikTj0uOXrDstnoLvfhgWz1jvSqffA@mail.gmail.com>
Message-ID: <CAA0c1bASr+WxTVVKT_kiP94avM-74nSTPuYCm_C43foJgc-gaw@mail.gmail.com>

Hi Adam,

On Thu, Jun 30, 2011 at 5:20 PM, Adam Malcontenti-Wilson <adman.com@
gmail.com> wrote:

> @acolwell:
> Is the appendData method one your suggesting or one already
> specified/existing?
>
> I'm suggesting it. It was a quick and dirty way to try out some ideas I had
while working on a prototype for Chromium. Now that I actually want to take
this out of the prototype stage, I'm trying to get a sense of whether
appendData() or a MediaStream based solution is more desirable.


> @robert:
> Some problems with concept of blobs being appended to, or as I have
> previously described as "Streaming Blobs" was mentioned at
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032221.html
> I'm not exactly sure what that meant - but I'd expect the ideas
> discussed are similar.
>
> I saw this thread as well which is why I went down the MediaStream path.
:)

Aaron


From B.Lund at CableLabs.com  Fri Jul  1 08:40:08 2011
From: B.Lund at CableLabs.com (Bob Lund)
Date: Fri, 1 Jul 2011 09:40:08 -0600
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D030170FBFD@srvxchg>

Hi Aaron,

Here are some other aspects of script controlled adaptive bit rate that occur to me, perhaps you have already considered these.

1) I guess script will be responsible for maintaining its own playback buffer, monitoring buffer behavior and selecting the appropriate bit rate for new fragments. Are there any other network related events/metrics script might need to determine which bit-rate to fetch for the next segment? Is there any other information from the user agent about playback performance that script might need?

2) If a media resource is a multi-track resource then it would seem script will also have to fetch fragments for those tracks which implies that the audio element would need the append method. Timed text tracks would also need to be processed and Cues appended.

There is a new media pipeline task force in the Web and TV IG (http://www.w3.org/2011/webtv/wiki/MPTF) that is also planning to examine this topic. You may want to participate.

Regards,
Bob Lund


> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
> bounces at lists.whatwg.org] On Behalf Of Aaron Colwell
> Sent: Thursday, June 30, 2011 10:59 AM
> To: whatwg at whatwg.org
> Subject: [whatwg] Extending HTML 5 video for adaptive streaming
> 
> Hi,
> 
> I've been working on an adaptive streaming prototype that uses
> JavaScript to fetch chunks of media and feeds them to the video tag for
> decoding. The idea is to let the adaptation algorithm and CDN
> interactions happen in JavaScript so that they can evolve without the
> need for browser changes. I'm looking for some guidance about the
> preferred method for adding this type of functionality. I'm new to this
> process so please bear with me.
> 
> My initial implementation is built around WebM, but I believe this could
> work for Ogg & MP4 as well. The basic idea is to initialize the video
> tag with stream initialization data (ie WebM info & tracks elements) via
> the <video> src attribute and then send media chunks (ie WebM clusters)
> to the tag via a new appendData() method on <video>. Here is a simple
> example of what I'm talking about.
> 
>   <video id="v" autoplay> </video>
>   <script>
>     function needMoreData(e) {
>       e.target.appendData(getNextCluster());
>     }
> 
>     function onSeeking(e) {
>       var video = e.target;
>       video.appendData(findClusterForTime(video.currentTime));
>     }
> 
>     var video = document.getElementById('v');
> 
>     video.addEventListener('loadstart', needMoreData);
>     video.addEventListener('stalled', needMoreData);
>     video.addEventListener('seeking', onSeeking);
> 
>     video.src = URL.createObjectURL(createStreamInitBlob());
>   </script>
> 
> AppendData() expects to recieve a Uint8Array that contains WebM cluster
> elements. The first cluster passed to appendData() initializes the
> starting playback position. Also after a seeking event fires the first
> appendData() updates the current position to the seek point.
> 
> I've also been looking at the WebRTC MediaStream API and was wondering
> if it makes more sense to create an object similar to the
> LocalMediaStream object.
> This has the benefits of unifying how media streams are handled
> independent of whether they come from a camera or a JavaScript based
> streaming algorithm. This could also enable sending the media stream
> through a Peer-to-peer connection instead of only allowing a camera as a
> source. Here is an example of the type of object I'm talking about.
> 
> interface GeneratedMediaStream : MediaStream {
>   void init(in DOMString type, in UInt8Array init_data);
>   void appendData(in DOMString trackId, in UInt8Array data);
>   void endOfStream();
> 
>   readonly attribute MultipleTrackList audioTracks;
>   readonly attribute ExclusiveTrackList videoTracks; };
> 
> type - identifies the type of stream we are generating(ie video/x-webm-
> cluster-stream or video/ogg-page-stream) init_data - Provides
> initialization data that indicates the number of tracks, codec configs,
> etc. (ie WebM info & tracks elements or Ogg header
> 
> pages)
> trackId - Indicates what track the data is for. If this is an empty
> string than multiplexed data is being passed in. If not empty trackId
> matches an id of a track in the TrackList objects.
> data - media data chunk (ie WebM cluster or Ogg page). Data is expected
> to have monotonically increasing timestamps, no gaps, etc.
> 
> Here are my questions:
> - Is there a preference for appendData() vs new MediaStream object?
> - If the MediaStream object is preferred, should this be constructed
> through Navigator.getUserMedia()? I'm unclear about what the criteria is
> for adding this to Navigator vs allowing direct object construction.
> - Are there existing efforts along these lines? If so, please point me
> to them.
> 
> Thanks for your help,
> 
> Aaron


From Simetrical+w3c at gmail.com  Fri Jul  1 10:30:39 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 1 Jul 2011 13:30:39 -0400
Subject: [whatwg] Using footer in blockquote for attribution
In-Reply-To: <op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>
	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
	<op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
Message-ID: <BANLkTimub7c-zdQW06oqR02FVNuRJs_mCg@mail.gmail.com>

On Fri, Jul 1, 2011 at 4:26 AM, Simon Pieters <simonp at opera.com> wrote:
> <blockquote> is sectioning root.

Oops.  I stand corrected, never mind me.


From acolwell at google.com  Fri Jul  1 12:06:47 2011
From: acolwell at google.com (Aaron Colwell)
Date: Fri, 1 Jul 2011 12:06:47 -0700
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D030170FBFD@srvxchg>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<114DAD31379DFA438C0A2E39B3B8AF5D030170FBFD@srvxchg>
Message-ID: <CAA0c1bDBZo2Lwk-eoniAcT2iz4dmC2JGfr5F_Dd7gYXDt20BnQ@mail.gmail.com>

Hi Bob,

Comments inline

On Fri, Jul 1, 2011 at 8:40 AM, Bob Lund <B.Lund at cablelabs.com> wrote:

> Hi Aaron,
>
> Here are some other aspects of script controlled adaptive bit rate that
> occur to me, perhaps you have already considered these.
>
> 1) I guess script will be responsible for maintaining its own playback
> buffer, monitoring buffer behavior and selecting the appropriate bit rate
> for new fragments. Are there any other network related events/metrics script
> might need to determine which bit-rate to fetch for the next segment? Is
> there any other information from the user agent about playback performance
> that script might need?
>
>
The script would be responsible for managing buffering. It can use the
currentTime & buffered attributes on the video tag to monitor the
consumption of the data passed in via appendData(). I believe the attributes
being proposed in the video metrics
proposal<http://wiki.whatwg.org/wiki/Video_Metrics#Proposal> could
also be helpful. Right now I'm just using XMLHttpRequest to fetch WebM
clusters and measuring how long it takes to fetch them to create a bandwidth
estimate. I haven't spent much time on the BW measurement & adaptation
algorithms yet. I'm just trying to nail down mechanism for passing the media
data to the browser first.


> 2) If a media resource is a multi-track resource then it would seem script
> will also have to fetch fragments for those tracks which implies that the
> audio element would need the append method. Timed text tracks would also
> need to be processed and Cues appended.
>
>
The idea is that appendData() can receive media for multiple tracks. In the
case of WebM each cluster can have blocks from different tracks multiplexed
together. The initial stream config information contains the the track
mappings necessary to demux the cluster. I was also planning to allow both
multiplexed and demultiplexed clusters. Cluster timecodes must be in
monotonically increasing order, but it would be possible to call
appendData() with an cluster with only audio data followed by a cluster with
only video data. This would allow straight forward support for deployments
where audio & video tracks for a single presentation are in separate WebM
files.


> There is a new media pipeline task force in the Web and TV IG (
> http://www.w3.org/2011/webtv/wiki/MPTF) that is also planning to examine
> this topic. You may want to participate.
>
>
I have signed up to the mailing list and will take some time to catch up
with the archives.

Thanks for your comments.

Aaron


From michaeln at google.com  Fri Jul  1 12:33:34 2011
From: michaeln at google.com (Michael Nordman)
Date: Fri, 1 Jul 2011 12:33:34 -0700
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
Message-ID: <CAHpoE=irx0MVLZwvJRCyB3Rc+qNOb6dTF=GJyPjmk__7Hz6VUg@mail.gmail.com>

A common request that maybe we can agree upon is the ability to list the
manifests that are cached and to delete them via script. Something like...
  String[] window.applicationCache.getManifests();  // returns appcache
manifest for the origin
  void window.applicationCache.deleteManifest(manifestUrl);

I think it's clear from this discussion (and others) that the overall
appcache feature set leaves something to be desired, but it's less clear how
to best satisfy the "desirements". Until there is some clarity, it's hard to
see how the community is going to make progress. Personally, I think whats
needed to move things forward is for browser vendors to do some independent
innovating to see what works and what doesn't work.

>> @Hixie... any idea when the appcache feature set will be up for a growth
>> spurt? I think there's an appetite for another round of features in the
>> offline app developers that i communicate with. There's been some recent
>> interest here in pursuing a means of programatically producing a
>> response instead of just returning static content.
>
> Who implements it currently? Is there a test suite? Those are the main
> things that would gate a dramatic addition of new features.

Well, nobody yet; but I have a roadmap in mind that builds up to that. Much
of the discussion in this thread has been on the second item. Mobile
developers are particularly interested 2 to avoid HTTP cache churn and the
cost of HTTP cache validation. In this roadmap, you can see that it would
also allow pages vended from servers to make use of "executable intercept
handlers".


-1. [DONE] Support for cross-origin HTTPS resources.
http://code.google.com/p/chromium/issues/detail?id=69594

0. [DONE] A means of not invoking the fallback resource for some error
responses that would generally result in the fallback resource being
returned. An additional response header would suite they're needs...
something like...
x-chromium-appcache-fallback-override: disallow-fallback
If a response header is present with that value, the fallback response would
not be returned.
http://code.google.com/p/chromium/issues/detail?id=82066

1. [UNDER CONFUSING DISCUSSION] Allow a syntax to associate a page with an
application cache, but does
not add that page to the cache. A common feature request also mentioned on
the whatwg list, but it's not getting any engagement from other browser
vendors or the spec writer (which is kind of frustrating). The premise is to
allow pages vended from a server to take advantage of the resources in an
application cache when loading subresources. A perfectly reasonable
request, <http useManifest='x'>.

2. Introduce a new manifest file section to INTERCEPT requests into a prefix
matched url namespace and satisfy them with a cached resource. The resulting
page would be free to interpret the location url and act accordingly based
on the path and query elements beyond the prefix matched url string. This
section would be similar to the FALLBACK section in that prefix matching is
involved, but different in that instead of being used only in the case of a
network/server error, the cached INTERCEPT resource would be used
immediately w/o first going to the server.
  INTERCEPT:
  urlprefix redirect newlocationurl
  urlprefix return cachedresourceurl

Here's where the INTERCEPT namespace could fit into the changes to the
network model.
   if (url is EXPLICITLY_CACHED)  // exact match
     return cached_response;
   if (url is in NETWORK namespace) // prefix match
     return network_response_as_usual;
   if (url is in INTERCEPT namespace) // prefix match <---- this is the new
section
     return handle_intercepted_request_accordingly
   if (url is in FALLBACK namespace) // prefix match
     return network_response_but_fallback_where_needed;
   if (ONLINE_WILDCARD)
     return network_response;
   otherwise
     return synthesized_error_response;

3. Allow an INTERCEPT cached resources to be "executable". Instead of simply
returning the cached resource or redirect in response to the request, load
it into a
background worker context (if not already loaded) and invoke a function in
that context to asynchronously compute response headers and body based on
the request headers (including cookie) and body. The background worker would
have access to various local storage facilities (fileSystem, indexed/sqlDBs)
as well as the ability to make network requests via XHR.
  INTERCEPT:
  urlprefix execute cachedexecutableresourceurl

4. Create a syntax to allow FALLBACK resources to be similarly executable in
a background worker context.

5. Some kind of auto-update policy where the appcache is refreshed w/o the
app running.

There are a couple of features that are not on this list that I want to call
out:

* The ability to add(url) and remove(url) the appcache is not on the list.
FileSystem urls cover a lot of this already, and the ability to cache adhoc
resources and later load them via http urls could be composed out of the
filesystem and executable handlers. Although having add(url) and remove(url)
could probably make for a friendlier API, so maybe this should be squeezed
somewhere inbetween 1 and 3. Or maybe an intercept handler directive could
bind a url prefix to a directory in the origins FileSystem?
   INTERCEPT:
   urlprefix filesystem_temp /path/to/dir/in/temp/web_file_system
   urlprefix filesystem_pers /path/to/dir/in/persistent/...

* A Gears-like 'querymatching' capability is not on the list, executable
handlers subsume that in a much better way.



On Thu, Jun 30, 2011 at 8:22 PM, Felix Halim <felix.halim at gmail.com> wrote:

> On Fri, Jul 1, 2011 at 12:40 AM, timeless <timeless at gmail.com> wrote:
> > It's possible to build a main page so that it can update its content
> > using a subresource. You can use iframes, javascript (including json),
> > xmlhttprequests, or other things to do this.
>
> Those are another option besides using localStorage.
> Again, those things requires restructuring your website.
> I'm looking for a solution that doesn't require modifying anything
> except adding a manifest.
>
>
> > Nothing requires you to have a monolythic main page which is incapable
> > of dynamically updating itself. ... If I visit your page on May 1st
> > and sit there for two months, does your page really just want to
> > continue to show me the same content when I glance at it on July 1st?
> > It can show other content if it wants to, and in order to save
> > bandwidth costs, it should avoid resending the framework which
> > shouldn't be changing. Once your page works well for this case, it
> > should work well for app-cache.
>
> As I said before, separating dynamic from the static will work,
> however, if we don't have "pageStorage", even we have a clean dynamic
> separation, it will quickly run out of space if we use "localStorage"
> since the localStorage quota is per domain.
>
> Let's see an example:
>
> I have a dynamic page with this url:
>
> http://bla/page?id=10
>
> The content inside is changing very frequently, lets say every hour.
> Of course, I want the browser to cache the latest version.
> So, it seemed that AppCache is a perfect fit...
>
> I then add the manifest to enable the App Cache, and what do I get?
>
> Everytime I open that URL every hour, I ALWAYS see the STALE version
> (the 1 hour late version). Then few seconds (or minutes) later (depend
> on when the AppCache gets updated), I refresh, then I got the latest
> content. Annoying, right?
>
> In this case, I better off NOT to use App Cache, since it brings the
> old content everytime.
>
> This is why most people says please "DON'T cache the main page".
>
>
>
> Now, let see the alternative: I build a framework to separate the
> dynamic from the static.
> I have to make it so that only ONE MAIN PAGE get cached by the app cache.
> So, my URL can NO LONGER BE:
>
> http://bla/page?id=10
>
> But it has to change to:
>
> http://bla/page#!id=10
>
> Why do I have to do this? it's because if I DON'T, then each page will
> be stored on different App Cache, and the "stale by one" still occurs!
> That is,
>
> http://bla/page?id=10
>
> and
>
> http://bla/page?id=11
>
> Will be on DIFFERENT AppCache!
>
> In that case, my cleanly separated static and dynamic will have no effect!
> Because all the statics get duplicated for each App Cache.
> It will be the same as if I don't have the framework!
>
> So, to make the AppCache only cache one static framework, I have to
> make my page such that it is served under ONE url:
>
> http://bla/page
>
> Then take the "#!id=10" as non url (or ajax bookmark). This way, the
> AppCache will only cache ONE of my static framework, and MANY dynamic
> content inside it.
>
> Guess what? All the incoming links from other blogs are now broken!
> Of course I can make a redirect, but redirect is AGAINST making the web
> faster!
>
> I think Facebook did the #! thing a while ago, then they abandoned it, why?
>
> Ok now I'm happy with my framework and the redirect, and guess what?
> Soon, I have other pages with #!id=11, #!id=12, ...,  #!id=10000.
> All of them are important and I wan't to cache them and I uses the
> localStorage (or indexedDB) to cache the dynamic content of those
> pages.
> Note that even though the dynamic content is "dynamic" it doesn't mean
> that:
>
> http://bla/page?id=10
>
> has "shared" data with
>
> http://bla/page?id=11
>
> It can be totally different unrelated dynamic content. id=10 dynamic
> content is entirely different from id=11 dynamic content. However,
> since I use localStorage to cache the dynamic content, ALL OF THEM are
> limited to the quota of my domain. My 5MB localStorage domain quota
> will quickly run out of space.
>
> If only I can store the dynamic content into a pageStorage (assuming
> different URL -> including the shebang bookmark has different
> pageStorage), then I won't be running out of storage if I keep one
> page within 5MB. So
>
> http://bla/page#!id=10
>
> has 5 MB pageStorage quota, and
>
> http://bla/page#!id=11
>
> also has 5 MB pageStorage quota, etc...
>
> Then I would be very happy with the new framework.
> Since it will store very compact static App and very compact dynamic
> content.
> It's a win win for everyone, nothing is wasted.
>
> But, if I don't have pageStorage quota, my beautifully separated the
> dynamic from the static framework will be useless since the
> localStorage DOMAIN QUOTA will kill me.
>
>
> So, we have seen how the AppCache fails to satisfy certain usecase and
> how pageStorage is needed to make the alternative solution works.
>
> Here, I propose a solution:  AppCache should COMPLEMENT HTTP Cache so
> that "the main page is not cached" (you know this is not literally
> what it means).
>
> With that solution, I don't have to do ANYTHING on my original site to
> make it work (except adding a manifest to my original page). I can
> still use the old url:
>
> http://bla/page?id=10
>
> It will cache AND SHOW the latest page to the users (just like normal
> web page with HTTP Cache). Then will show the latest cache if the
> network or the server is offline (and perhaps give notification
> header). That's ALL I NEED. This guarantees that my website will still
> be available when the user goes offline.
>
>
> All these discussions only begs to add one feature to AppCache:
> - Only show the cache when the network / server is offline, otherwise,
> show the online version of the page.
>
> The current AppCache doesn't care whether the network/server is online
> or offline, it BLINDLY shows the cache everytime. This is good for the
> default, however, we should HAVE an option to not show the cache if we
> are ONLINE (this is what people meant when they say "DON"T CACHE THE
> MAIN PAGE").
>
> Felix Halim
>


From michaeln at google.com  Fri Jul  1 13:38:46 2011
From: michaeln at google.com (Michael Nordman)
Date: Fri, 1 Jul 2011 13:38:46 -0700
Subject: [whatwg] AppCache + CORS issue.
Message-ID: <CAHpoE=h4uyD0F5Tr=W8JLZsh6YaO4vEu8gGpGb54deN768PCOQ@mail.gmail.com>

Cross-origin resources listed in the CACHE section aren't retrieved with the
'Origin' header and the responses may not contain the
'Access-Control-Allow-Origin'
header. This makes it impossible to utilized CORS for appcache resources.

http://code.google.com/p/chromium/issues/detail?id=86324

We may need a way to express in the manifest file that the x-origin
resource is to be retrieved and cached with the CORS related headers.
Maybe a new manifest file section a lot like the CACHE section but a
little different... something like...

CACHE-CORS:http://cross-origin/resource

When fetching, the 'Origin' header would be included and the responses
'Access-Control-Allow-Origin' header would be cached. When accessed by
pages associated with the appcache, the access-control-allow-origin
header would be provided.


From ojan at chromium.org  Fri Jul  1 13:59:02 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 1 Jul 2011 13:59:02 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
Message-ID: <CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>

Do any browser vendors agree with this or have objections? Hixie, this seem
OK to you?

These additions seem safe, simple and enable sites giving users a better
experience.

On Wed, Apr 20, 2011 at 11:32 PM, James Kozianski <koz at chromium.org> wrote:

> Hi,
>
> I'd like to propose the following changes to the registerProtocolHandler
> spec.
>
> 1. Introduce an isRegistered() function.
>
> Currently if a site wants its users to register it as a handler for a given
> protocol it has two options:
>
>    a) It can call registerProtocolHandler() on page load. (This approach
> was suggested in [1])
>
>    b) It can have a button that the user clicks (or similar) to enact the
> registration.
>
>
> The former is problematic because the call to registerProtocolHandler will
> cause the browser's UI to notify them of the registration (or prompt them
> to
> make a decision), which is redundant if it occurs on every page load.
>
>
> The latter is problematic because it puts the onus on each site developer
> to
> provide the UI to allow the user to make the change. Also, as the site
> doesn't know whether the user has already registered the given protocol
> handler, it can't tailor its UI to reflect this. This means the UI either
> always shows, or never shows, both of which are undesirable.
>
>
> Having an isRegistered() function would allow a site to simply make the RPH
> call conditionally on load, or to provide a UI for it that reflects the
> user's current preference.
>
>
> 2. Introduce an unregisterProtocolHandler() function.
>
> Such a function is desirable because it allows sites to remove outdated
> handlers from clients and would enable clients to provide a UI for managing
> their registered protocol handlers.
>
>
> 3. Require all URL arguments to have the same origin as the page executing
> the call.
>
> This would would make the behaviour of this set of functions more
> consistent
> (isRegistered() should only work for same-domain queries, to prevent
> information leaking).
>
>
> Cheers,
> James
>
> [1] - http://www.mail-archive.com/whatwg at lists.whatwg.org/msg14548.html
>


From pkasting at google.com  Fri Jul  1 14:10:12 2011
From: pkasting at google.com (Peter Kasting)
Date: Fri, 1 Jul 2011 14:10:12 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
Message-ID: <BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>

On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai <ojan at chromium.org> wrote:

> Do any browser vendors agree with this or have objections?


>From my work on the Chrome UI side of this, I would very much like to see
something like isRegistered().  This would allow sites to conditionalize
requests for the protocol handler.  This is important to me because I would
also like to experiment (after that point) with requiring a user gesture for
this request (much like browsers typically require user gestures for
window.open()), so sites cannot hammer the user with requests outside of
some sort of interaction-based workflow.

PK


From mpd at google.com  Fri Jul  1 14:25:32 2011
From: mpd at google.com (Michael Davidson)
Date: Fri, 1 Jul 2011 14:25:32 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
Message-ID: <CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>

>From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined previously, then calling registerProtocolHandler() in
today's UAs will not do anything. If I can't detect that state, then they'll
keep clicking and I'll keep calling and they'll get frustrated.

I'd prefer if isRegistered() was something like registeredState() and
returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
really reflects reality.

Michael


From ojan at chromium.org  Fri Jul  1 14:44:06 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 1 Jul 2011 14:44:06 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
Message-ID: <CANMdWTt9NmUJS3CO3TDS83p00k504GsZ47U1mM-8L6HSxPRt6Q@mail.gmail.com>

Agree. This seems strictly superior. Just to bikeshed on the name a bit,
since this is hanging off the navigator object, the name should probably
mention something about protocols, protocolState()?

On Fri, Jul 1, 2011 at 2:25 PM, Michael Davidson <mpd at google.com> wrote:

> From my perspective on Gmail, I would prefer to know if the user hasn't
> registered because they declined previously or haven't been asked. If
> they've declined previously, then calling registerProtocolHandler() in
> today's UAs will not do anything. If I can't detect that state, then they'll
> keep clicking and I'll keep calling and they'll get frustrated.
>
> I'd prefer if isRegistered() was something like registeredState() and
> returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
> really reflects reality.
>
> Michael
>
>


From Olli.Pettay at helsinki.fi  Fri Jul  1 14:58:24 2011
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Sat, 02 Jul 2011 00:58:24 +0300
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
Message-ID: <4E0E4300.6000602@helsinki.fi>

On 07/02/2011 12:25 AM, Michael Davidson wrote:
>  From my perspective on Gmail, I would prefer to know if the user hasn't
> registered because they declined previously or haven't been asked. If
> they've declined previously, then calling registerProtocolHandler() in
> today's UAs will not do anything. If I can't detect that state, then they'll
> keep clicking and I'll keep calling and they'll get frustrated.
>
> I'd prefer if isRegistered() was something like registeredState() and
> returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
> really reflects reality.

Shouldn't there be also something like "NOTANSWERED", if user hasn't yet
decided whether to accept registering or not.


Though, I wonder if there is some privacy issue related to
isRegistered/registeredState(). Or there is - web app can
know whether it is being used as the default protocol handler
for some protocol, say mailto: with GMail.
But is the privacy issue bad enough to worry about?

Safer option would be if registeredState() would just return
"ASKED" or "NOTASKED"


-Olli


From ojan at chromium.org  Fri Jul  1 15:03:16 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 1 Jul 2011 15:03:16 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E0E4300.6000602@helsinki.fi>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
	<4E0E4300.6000602@helsinki.fi>
Message-ID: <CANMdWTvPV0k83RrEb++GbnfdHZvcnME7v1Px8m-wmoPzoyYmMQ@mail.gmail.com>

On Fri, Jul 1, 2011 at 2:58 PM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:

> On 07/02/2011 12:25 AM, Michael Davidson wrote:
>
>>  From my perspective on Gmail, I would prefer to know if the user hasn't
>> registered because they declined previously or haven't been asked. If
>> they've declined previously, then calling registerProtocolHandler() in
>> today's UAs will not do anything. If I can't detect that state, then
>> they'll
>> keep clicking and I'll keep calling and they'll get frustrated.
>>
>> I'd prefer if isRegistered() was something like registeredState() and
>> returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that
>> really reflects reality.
>>
>
> Shouldn't there be also something like "NOTANSWERED", if user hasn't yet
> decided whether to accept registering or not.
>

I'm not opposed to this for completeness sake. I expect all sites would just
ask again in this case.


> Though, I wonder if there is some privacy issue related to
> isRegistered/registeredState()**. Or there is - web app can
> know whether it is being used as the default protocol handler
> for some protocol, say mailto: with GMail.
> But is the privacy issue bad enough to worry about?
>

I'm not sure what the privacy issue here is given that we restrict to
same-domain. You're already using the site, so it's just whether they can
tell that you use them as a protocol handler. I don't see a problem with
exposing that.


> Safer option would be if registeredState() would just return
> "ASKED" or "NOTASKED"
>
>
> -Olli
>


From mpd at google.com  Fri Jul  1 15:08:08 2011
From: mpd at google.com (Michael Davidson)
Date: Fri, 1 Jul 2011 15:08:08 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTvPV0k83RrEb++GbnfdHZvcnME7v1Px8m-wmoPzoyYmMQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<CAHYqKGfKaDF-QjKyO6scDWjiRO6F6yCOh5gymQyV9BC6eiKz=w@mail.gmail.com>
	<4E0E4300.6000602@helsinki.fi>
	<CANMdWTvPV0k83RrEb++GbnfdHZvcnME7v1Px8m-wmoPzoyYmMQ@mail.gmail.com>
Message-ID: <CAHYqKGeWFcjpOLkBMDtF0OSjawMZW5+7kBtBLWeBSGdYf5odZg@mail.gmail.com>

On Fri, Jul 1, 2011 at 3:03 PM, Ojan Vafai <ojan at chromium.org> wrote:

> I'm not sure what the privacy issue here is given that we restrict to
> same-domain. You're already using the site, so it's just whether they can
> tell that you use them as a protocol handler. I don't see a problem with
> exposing that.
>

FWIW, notifications already exposes this:

http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html

Seems best just to crib what they already did.

Michael


>
>
>> Safer option would be if registeredState() would just return
>> "ASKED" or "NOTASKED"
>>
>>
>> -Olli
>>
>
>


From svartman95 at gmail.com  Fri Jul  1 17:14:39 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sat, 02 Jul 2011 00:14:39 +0000
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
Message-ID: <4E0E62EF.6020106@gmail.com>

?ann f?s  1.j?l 2011 03:22, skrifa?i Felix Halim:
> I'm looking for a solution that doesn't require modifying anything
> except adding a manifest.
>
I recommend fixing your website. As others have stated, this has 
practical benefits, in the online as well as the offline case.

> As I said before, separating dynamic from the static will work,
Great!

> however, if we don't have "pageStorage", even we have a clean dynamic
> separation, it will quickly run out of space if we use "localStorage"
> since the localStorage quota is per domain.
>
Nobody's forcing you to use localStorage. How do you figure using 
pageStorage or localStorage will be less work than using iframes or 
other linking methods already proposed?

> Let's see an example:
>
> I have a dynamic page with this url:
>
> http://bla/page?id=10
>
> The content inside is changing very frequently, lets say every hour.
> Of course, I want the browser to cache the latest version.
Then specify the applicable HTTP headers with informative values. HTTP 
caching hasn't stopped working, nor is it barred from improving. There 
is space for implementations to improve while complying with current 
specifications. All you have to do is split dynamic resources from 
static, read the RFC and send the appropriate headers.
Of course this method has the drawback of requiring a request/response 
pair for every resource transferred over HTTP.

> So, it seemed that AppCache is a perfect fit...
>
AppCache is no magic bullet. Don't use it if you figure it isn't a 
perfect fit.

> I then add the manifest to enable the App Cache, and what do I get?
>
> Everytime I open that URL every hour, I ALWAYS see the STALE version
> (the 1 hour late version). Then few seconds (or minutes) later (depend
> on when the AppCache gets updated), I refresh, then I got the latest
> content. Annoying, right?
>
FYI, HTTP has already resolved this issue, by forbidding implementations 
from returning a stale version by default under normal situations or 
without warning

> In this case, I better off NOT to use App Cache, since it brings the
> old content everytime.
>
Right. Bad App Cache.

> Now, let see the alternative: I build a framework to separate the
> dynamic from the static.
> I have to make it so that only ONE MAIN PAGE get cached by the app cache.
> So, my URL can NO LONGER BE:
>
> http://bla/page?id=10
>
> But it has to change to:
>
> http://bla/page#!id=10
>
> Why do I have to do this? it's because if I DON'T, then each page will
> be stored on different App Cache, and the "stale by one" still occurs!
> That is,
>
> http://bla/page?id=10
>
> and
>
> http://bla/page?id=11
>
> Will be on DIFFERENT AppCache!
>
> In that case, my cleanly separated static and dynamic will have no effect!
> Because all the statics get duplicated for each App Cache.
> It will be the same as if I don't have the framework!
>
I'm not following your line of thinking. Why do you insist on using an 
App Cache for each page rather than a shared cache for all your resources?

> So, to make the AppCache only cache one static framework, I have to
> make my page such that it is served under ONE url:
>
> http://bla/page
>
> Then take the "#!id=10" as non url (or ajax bookmark). This way, the
> AppCache will only cache ONE of my static framework, and MANY dynamic
> content inside it.
>
> Guess what? All the incoming links from other blogs are now broken!
> Of course I can make a redirect, but redirect is AGAINST making the web faster!
>
> I think Facebook did the #! thing a while ago, then they abandoned it, why?
>
> Ok now I'm happy with my framework and the redirect, and guess what?
> Soon, I have other pages with #!id=11, #!id=12, ...,  #!id=10000.
> All of them are important and I wan't to cache them and I uses the
> localStorage (or indexedDB) to cache the dynamic content of those
> pages.
> Note that even though the dynamic content is "dynamic" it doesn't mean that:
>
> http://bla/page?id=10
>
> has "shared" data with
>
> http://bla/page?id=11
>
> It can be totally different unrelated dynamic content. id=10 dynamic
> content is entirely different from id=11 dynamic content. However,
> since I use localStorage to cache the dynamic content, ALL OF THEM are
> limited to the quota of my domain. My 5MB localStorage domain quota
> will quickly run out of space.
>
Are you certain that users wish to archive every single dynamic resource 
they fetch from your site? Disposition of any significant amount of 
storage should be in the hands of the user, if indirectly through the 
user agent. Take handhelds.

> If only I can store the dynamic content into a pageStorage (assuming
> different URL ->  including the shebang bookmark has different
> pageStorage), then I won't be running out of storage if I keep one
> page within 5MB. So
And you're sure this is a good thing, because?

> http://bla/page#!id=10
>
You *can't* allocate a quota per URI fragment, as a script in the page 
could create new ones as wanted.

> Then I would be very happy with the new framework.
> Since it will store very compact static App and very compact dynamic content.
> It's a win win for everyone, nothing is wasted.
>
> But, if I don't have pageStorage quota, my beautifully separated the
> dynamic from the static framework will be useless since the
> localStorage DOMAIN QUOTA will kill me.
>
>
> So, we have seen how the AppCache fails to satisfy certain usecase and
> how pageStorage is needed to make the alternative solution works.
>
Show how either the HTTP specification or common practice forbids HTTP 
caches from satisfy your use cases.

> Here, I propose a solution:  AppCache should COMPLEMENT HTTP Cache so
> that "the main page is not cached" (you know this is not literally
> what it means).
>
Caching the main page may be useful, so you'd have to implement both.

> With that solution, I don't have to do ANYTHING on my original site to
> make it work (except adding a manifest to my original page). I can
> still use the old url:
>
> http://bla/page?id=10
>
> It will cache AND SHOW the latest page to the users (just like normal
> web page with HTTP Cache). Then will show the latest cache if the
> network or the server is offline (and perhaps give notification
> header). That's ALL I NEED. This guarantees that my website will still
> be available when the user goes offline.
>
You're asking for user agents archiving websites for offline viewing (in 
the offline mode). I fetch a bunch of unread pages for offline reading 
from time to time, but keeping a copy of read pages when I'm most likely 
going to be online may be considered a waste of storage space. Users who 
have a lot of storage at their disposal may do this already. I see no 
reason to do so only if requested by the author.

There are two situations:
  a) A user agent runs in a constrained environment with limited storage 
space. The user agent caches static resources only, or doesn't cache at all.
  b) A user agent runs in a plentiful environment with great volumes of 
storage space at it's disposal. The user agent archives most if not all 
resources it fetches, throwing stale resources away according to a cache 
algorithm when a quote set in proportion to the available storage space 
is reached.

How does your proposal help the user agent in archiving, or not 
archiving resources?

>
> All these discussions only begs to add one feature to AppCache:
> - Only show the cache when the network / server is offline, otherwise,
> show the online version of the page.
>
This requires a validation roundtrip (as is common), but is otherwise fair.

> The current AppCache doesn't care whether the network/server is online
> or offline, it BLINDLY shows the cache everytime. This is good for the
> default, however, we should HAVE an option to not show the cache if we
> are ONLINE (this is what people meant when they say "DON"T CACHE THE
> MAIN PAGE").
>
HTTP caches may do what you want.


From felix.halim at gmail.com  Sat Jul  2 12:16:49 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Sun, 3 Jul 2011 03:16:49 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <4E0E62EF.6020106@gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
Message-ID: <CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>

On Sat, Jul 2, 2011 at 8:14 AM, Bjartur Thorlacius <svartman95 at gmail.com> wrote:
> ?ann f?s ?1.j?l 2011 03:22, skrifa?i Felix Halim:
>>
>> I'm looking for a solution that doesn't require modifying anything
>> except adding a manifest.
>>
> I recommend fixing your website. As others have stated, this has practical
> benefits, in the online as well as the offline case.

I don't mind fixing my website, if I really have to! If AppCache have
an option to always view the main page "online", I won't have to do
anything.


>> however, if we don't have "pageStorage", even we have a clean dynamic
>> separation, it will quickly run out of space if we use "localStorage"
>> since the localStorage quota is per domain.
>>
> Nobody's forcing you to use localStorage. How do you figure using
> pageStorage or localStorage will be less work than using iframes or other
> linking methods already proposed?

It's not about the amount of work that matters, it's the quota I'm
talking about.


>> Let's see an example:
>>
>> I have a dynamic page with this url:
>>
>> http://bla/page?id=10
>>
>> The content inside is changing very frequently, lets say every hour.
>> Of course, I want the browser to cache the latest version.
>
> Then specify the applicable HTTP headers with informative values. HTTP
> caching hasn't stopped working, nor is it barred from improving. There is
> space for implementations to improve while complying with current
> specifications. All you have to do is split dynamic resources from static,
> read the RFC and send the appropriate headers.
> Of course this method has the drawback of requiring a request/response pair
> for every resource transferred over HTTP.

Remember that I also want those URL to be available even if the user is offline.
HTTP Cache is not that powerful, AppCache is.


>> In that case, my cleanly separated static and dynamic will have no effect!
>> Because all the statics get duplicated for each App Cache.
>> It will be the same as if I don't have the framework!
>>
> I'm not following your line of thinking. Why do you insist on using an App
> Cache for each page rather than a shared cache for all your resources?

I do want to use shared cache for shared resources and "page cache"
for non-shared resources (unique to that page). However, the
non-shared resources will become too large to fit in 5MB quota.
Remember I have different non-shared content for id=10, id=11, ...,
id=100000, I don't think that will fit in localStorage.


> Are you certain that users wish to archive every single dynamic resource
> they fetch from your site? Disposition of any significant amount of storage
> should be in the hands of the user, if indirectly through the user agent.
> Take handhelds.

Users only view the resources they want.

When they viewed it, I want it to be there for offline use or for
performance reasons.
I expect the users only view (and cache) few hundreds of them.
They cannot cache what they didn't view / open.
It is OK for the browser to not cache it if it doesn't any storage left.

I am satisfied if there is a "page storage" quota of 5MB given per
page (not per domain).
This will solve all my problems (of course by restructuring my site).



>> If only I can store the dynamic content into a pageStorage (assuming
>> different URL -> ?including the shebang bookmark has different
>> pageStorage), then I won't be running out of storage if I keep one
>> page within 5MB. So
>
> And you're sure this is a good thing, because?

Because currently, browsers can handle a page content < 5MB very fast.
I think it is OK for a page (not a domain) to have 5MB data quota.

If you are building games, perhaps need more than that (it has to go
to the web store to get unlimited permission). However, for regular
pages, 5MB "currently" is more than enough. 5MB per domain is too
small!


>> http://bla/page#!id=10
>>
> You *can't* allocate a quota per URI fragment, as a script in the page could
> create new ones as wanted.

Yes I know, that was only for an example to point out that:

If I use shared cache:

http://bla/page

I will run out of quota quickly.

If I use parameters like this:

http://bla/page?id=10

I will have to refresh TWICE to get the latest content (annoying).

If I can use:

http://bla/page#!id=10

I get the best of both worlds, that is I have shared static cache, and
I won't run out of quota for the non-shared-dynamic cache since the
quota is 5MB per hash value. I know that this has a security hole that
the script can just generate random url to get more quota.

My suggestion is to give quota to hash value for the first time the
page is loaded, so a later script modification will be linked to the
original hash value's quota.


>> So, we have seen how the AppCache fails to satisfy certain usecase and
>> how pageStorage is needed to make the alternative solution works.
>>
> Show how either the HTTP specification or common practice forbids HTTP
> caches from satisfy your use cases.

I think it's clear that HTTP Cache is inferior to AppCache.
What HTTP Cache can, it can be overridden by AppCache.
AppCache complements HTTP Cache.

HTTP Cache does satisfy my use cases since long time ago.
But with the presence of AppCache, I want better control.


> You're asking for user agents archiving websites for offline viewing (in the
> offline mode). I fetch a bunch of unread pages for offline reading from time
> to time, but keeping a copy of read pages when I'm most likely going to be
> online may be considered a waste of storage space. Users who have a lot of
> storage at their disposal may do this already. I see no reason to do so only
> if requested by the author.

AppCache cannot cache what has not been read/viewed.
What have been viewed can be safely deleted by the browser without warning.
Except, perhaps, for special "installable" web-apps in the store?


> There are two situations:
> ?a) A user agent runs in a constrained environment with limited storage
> space. The user agent caches static resources only, or doesn't cache at all.
> ?b) A user agent runs in a plentiful environment with great volumes of
> storage space at it's disposal. The user agent archives most if not all
> resources it fetches, throwing stale resources away according to a cache
> algorithm when a quote set in proportion to the available storage space is
> reached.
>
> How does your proposal help the user agent in archiving, or not archiving
> resources?

The decision of archiving is entirely up to the browser.
The cached pages in the AppCache will work fine if it is deleted by the browser.
It will just re-fetch everything and it will be as slow as the first
view of the page.

The archiving problem is not relevant for my proposal.


>> All these discussions only begs to add one feature to AppCache:
>> - Only show the cache when the network / server is offline, otherwise,
>> show the online version of the page.
>>
> This requires a validation roundtrip (as is common), but is otherwise fair.

Yes of course.

However, if the AppCache is set to cache the main page + everything,
no roundtrip is needed.

My proposal is to include an option to ALWAYS make a roundtrip for the
main page and show the latest main page (rather than show the cached
main page which avoid the roundtrip but will do that in later time and
giant refresh needed).


>> The current AppCache doesn't care whether the network/server is online
>> or offline, it BLINDLY shows the cache everytime. This is good for the
>> default, however, we should HAVE an option to not show the cache if we
>> are ONLINE (this is what people meant when they say "DON"T CACHE THE
>> MAIN PAGE").
>>
> HTTP caches may do what you want.

Yes, but I'm no longer satisfied with HTTP Caches when I can use a
more reliable AppCache.

Felix Halim


From timeless at gmail.com  Sun Jul  3 00:11:05 2011
From: timeless at gmail.com (timeless)
Date: Sun, 3 Jul 2011 03:11:05 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
Message-ID: <CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>

On 7/1/11, Ojan Vafai <ojan at chromium.org> wrote:
> Do any browser vendors agree with this or have objections?

I don't look forward to being blackmailed by sites into me allowing
them to register for X or else I don't get their content.

I have a bank which won't let me bank unless I have Java installed,
not because banking requires Java (and not because this bank requires
Java to do online banking, just because).

Testing for features should only be done by using them.

It's ok to try to do X and then after time T tell the user: "This
might work better if you ... <registered>".

It isn't ok to say "You can't do X unless you make Y your default Z."


From timeless at gmail.com  Sun Jul  3 00:17:42 2011
From: timeless at gmail.com (timeless)
Date: Sun, 3 Jul 2011 03:17:42 -0400
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
Message-ID: <CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>

If you have 100mb of junk, it won't fit in my browser's http cache
either. And that's a good thing, there are other sites I visit that
are more important. However, a browser is within its rights to detect
that its user uses a site so heavily as to justify increasing that
site's cache allocation. That's a QoI detail.

Note that if 70% of your 100mb is duplicated framework, it's possible
that a better implementation of your site could fit into a 25mb
cache...


From felix.halim at gmail.com  Sun Jul  3 00:41:54 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Sun, 3 Jul 2011 15:41:54 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
Message-ID: <CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>

On Sun, Jul 3, 2011 at 3:17 PM, timeless <timeless at gmail.com> wrote:
> If you have 100mb of junk, it won't fit in my browser's http cache
> either. And that's a good thing, there are other sites I visit that
> are more important. However, a browser is within its rights to detect
> that its user uses a site so heavily as to justify increasing that
> site's cache allocation. That's a QoI detail.

Yes, the quota system can be improved heuristically.

> Note that if 70% of your 100mb is duplicated framework, it's possible
> that a better implementation of your site could fit into a 25mb
> cache...

The only way to remove the duplication is to use a single URL for the
web app (then apply AppCache to that URL), and uses shebang to
uniquely identify the page:

http://bla/page#!id=10

Then all the non-duplicated data are stored in localStorage/indexedDB.

I would love this, however as long as the quota system is still 5MB
(or an equivalent page storage quota), I don't feel inclined to make
that changes to my site yet. The browsers vendors have to move first
to design better quota systems.

Or is there any other way to cleanly do the separation without shebang?

FYI, I want my page to be able to be linked (referenced / bookmarked)
from other sites.

Btw, does anyone know why Facebook abandoned the usage of shebang?

Felix Halim


From nils at dieweltistgarnichtso.net  Sun Jul  3 05:21:53 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 3 Jul 2011 14:21:53 +0200
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
	<CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
Message-ID: <20110703142153.0067f8dd@desudesudesu>

Felix Halim <felix.halim at gmail.com> schrieb am Sun, 3 Jul 2011 15:41:54
+0800:

> Btw, does anyone know why Facebook abandoned the usage of shebang?

If they did so, then rightly so. Hashbangs are a thouroughly bad idea:
<http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs>

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From felix.halim at gmail.com  Sun Jul  3 08:16:16 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Sun, 3 Jul 2011 23:16:16 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <20110703142153.0067f8dd@desudesudesu>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
	<CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
	<20110703142153.0067f8dd@desudesudesu>
Message-ID: <CAAbwPopZwDwF2hrDKx-AQKQr+nrxx2ZDvfXguDVnJZw_Knj89A@mail.gmail.com>

On Sun, Jul 3, 2011 at 8:21 PM, Nils Dagsson Moskopp
<nils at dieweltistgarnichtso.net> wrote:
> Felix Halim <felix.halim at gmail.com> schrieb am Sun, 3 Jul 2011 15:41:54
>> Btw, does anyone know why Facebook abandoned the usage of shebang?
>
> If they did so, then rightly so. Hashbangs are a thouroughly bad idea:
> <http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs>

After reading that article, it seemed that re-structuring the website
to separate the static from dynamic doesn't worth much afterall,
unless there is other method than hash-bang. The follow up question is
that: is there another way to achieve a clean separation without using
hash-bang?

Another question is that how do we bookmark/link AppCached pages
without using hash-bang? I cannot find discussions about it.

Felix Halim


From nils at dieweltistgarnichtso.net  Sun Jul  3 08:40:14 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 3 Jul 2011 17:40:14 +0200
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPopZwDwF2hrDKx-AQKQr+nrxx2ZDvfXguDVnJZw_Knj89A@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<BANLkTik=z6VhKxB5cEatPzT3jWebJS-fkA@mail.gmail.com>
	<BANLkTi=hhH=dSepnoZn0cPHumZJLaUC3Og@mail.gmail.com>
	<4E0E62EF.6020106@gmail.com>
	<CAAbwPooVf3cQ2VE3AK_JMxHs2Q0NMQXuZ1XG1wtb_RTDvYAsnA@mail.gmail.com>
	<CAACrNNeQGZ1AJJsnAwZ_b4L8SW8Z_7WTyUF0iFj8GK06vB2B5g@mail.gmail.com>
	<CAAbwPorZxsSH+qTpqD78n9fU9dFWmnfqP9J4meK4wURUU2C0ew@mail.gmail.com>
	<20110703142153.0067f8dd@desudesudesu>
	<CAAbwPopZwDwF2hrDKx-AQKQr+nrxx2ZDvfXguDVnJZw_Knj89A@mail.gmail.com>
Message-ID: <20110703174014.4f2a613e@desudesudesu>

Felix Halim <felix.halim at gmail.com> schrieb am Sun, 3 Jul 2011 23:16:16
+0800:

> [?]

> After reading that article, it seemed that re-structuring the website
> to separate the static from dynamic doesn't worth much afterall,
> unless there is other method than hash-bang. The follow up question is
> that: is there another way to achieve a clean separation without using
> hash-bang?

You may be looking for this:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html>?

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From pkasting at google.com  Sun Jul  3 12:24:17 2011
From: pkasting at google.com (Peter Kasting)
Date: Sun, 3 Jul 2011 12:24:17 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
Message-ID: <CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>

On Sun, Jul 3, 2011 at 12:11 AM, timeless <timeless at gmail.com> wrote:

> It isn't ok to say "You can't do X unless you make Y your default Z."
>

I would prefer to solve this if it actually becomes a problem.  Right now
sites are actually much _more_ annoying without this feature as they just
blindly ask you to make them your protocol handler every time.  I think we
should solve real usage problems today in preference to leaving them
unsolved for fear of a hypothetical later problem that we could easily solve
down the road.

PK


From nils at dieweltistgarnichtso.net  Sun Jul  3 13:01:17 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 3 Jul 2011 22:01:17 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
Message-ID: <20110703220117.6574dc02@desudesudesu>

Peter Kasting <pkasting at google.com> schrieb am Sun, 3 Jul 2011 12:24:17
-0700:

> On Sun, Jul 3, 2011 at 12:11 AM, timeless <timeless at gmail.com> wrote:
> 
> > It isn't ok to say "You can't do X unless you make Y your default
> > Z."
> >
> 
> I would prefer to solve this if it actually becomes a problem.

Without breaking sites using it properly? That may (or may not) be hard.

> Right now sites are actually much _more_ annoying without this
> feature as they just blindly ask you to make them your protocol
> handler every time.

Can UAs not be expected to handle this properly, like they do with
repeated alerts?

> I think we should solve real usage problems
> today in preference to leaving them unsolved for fear of a
> hypothetical later problem that we could easily solve down the road.

Define ?easily?. Lie to the page if it is annoying?

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From mpd at google.com  Sun Jul  3 14:40:53 2011
From: mpd at google.com (Michael Davidson)
Date: Sun, 3 Jul 2011 14:40:53 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <20110703220117.6574dc02@desudesudesu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
Message-ID: <CAHYqKGcqhwmGDnYyp39rk5ePJ2ZA58jEi51bWXKh3fq3=ixxOw@mail.gmail.com>

Has anyone seen a site that refuses to work unless notifications are active?
I suggest that we follow the notification model since it seems to work well
for both site authors and users.

I imagine that if sites force users to accept notifications or protocol
handlers, those sites won't have many users for long.

If it does become a problem in practice (which I highly doubt), then yes,
having a UA that lies to the site would be one solution. It would take about
five minutes to whip up a userscript that replaces calls to
registerProtocolHandler with a noop.

Michael


From robert at ocallahan.org  Mon Jul  4 03:18:49 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 4 Jul 2011 22:18:49 +1200
Subject: [whatwg] Extending HTML 5 video for adaptive streaming
In-Reply-To: <CAA0c1bBkbYh1dSbBQUWsRF1ChL_VBRkXfhjnwh72MkMAfTfMGg@mail.gmail.com>
References: <CAA0c1bDo4UG0hkoGRnP1PO8gfTtxpzcm3S8agaD5f8Jze2PkUA@mail.gmail.com>
	<BANLkTikztt1-V2T+JH06+Ob_YCTk_LZqBg@mail.gmail.com>
	<CAA0c1bBkbYh1dSbBQUWsRF1ChL_VBRkXfhjnwh72MkMAfTfMGg@mail.gmail.com>
Message-ID: <CAOp6jLZd-kLfS1WD3gaYoH34AF0254wZ2LSWFdOGz=OTj=PAbQ@mail.gmail.com>

On Sat, Jul 2, 2011 at 2:51 AM, Aaron Colwell <acolwell at google.com> wrote:

> On Thu, Jun 30, 2011 at 4:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Fri, Jul 1, 2011 at 4:59 AM, Aaron Colwell <acolwell at google.com>wrote:
>>
>>> I've also been looking at the WebRTC MediaStream API and was wondering if
>>> it
>>> makes more sense to create an object similar to the LocalMediaStream
>>> object.
>>> This has the benefits of unifying how media streams are handled
>>> independent
>>> of whether they come from a camera or a JavaScript based streaming
>>> algorithm. This could also enable sending the media stream through a
>>> Peer-to-peer connection instead of only allowing a camera as a source.
>>> Here
>>> is an example of the type of object I'm talking about.
>>>
>>
>> I think MediaStreams should not be dealing with compressed data except as
>> an optimization when access to decoded data is not required anywhere in the
>> stream pipeline. If you want to do processing of decoded stream data (which
>> I do --- see
>> http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html),
>> then introducing a decoder inside the stream processing graph creates all
>> sorts of complications.
>>
>> Nice spec. If I understand correctly, your position is that MediaStreams
> should only represent uncompressed media?
>

Sort of. I want the data format (compressed vs uncompressed, etc) to be
hidden from Web authors unless they use APIs like Worker-based processing
that require access to decoded data. What I don't want to have to deal with
is compressed data being injected at arbitrary points in the graph. Right
now the only the place compressed data is injected is at stream sources ---
media elements and getUserMedia.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From annevk at opera.com  Mon Jul  4 07:13:05 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 04 Jul 2011 16:13:05 +0200
Subject: [whatwg] EventSource - Handling a charset in the content-type
 header
In-Reply-To: <AANLkTikOc3AbmjjD6rawG+z=8R_CVn7joLuAcXeeNVVM@mail.gmail.com>
References: <AANLkTikOc3AbmjjD6rawG+z=8R_CVn7joLuAcXeeNVVM@mail.gmail.com>
Message-ID: <op.vx3lr3fn64w2qv@anne-van-kesterens-macbook-pro.local>

On Thu, 24 Mar 2011 05:52:02 +0100, Julien Chaffraix  
<julien.chaffraix at gmail.com> wrote:
> the EventSource specification states the current content-type header
> should match the string "text/event-stream". However following some
> bugs opened inside the WebKit project [1], we relaxed the content-type
> check to ignore any specified charset as it confused developers and
> can potentially break existing servers that automatically send a
> charset as part of the response [2].
> We are currently revisiting our approach and our current take would be
> to allow a mime-type of "text/event-stream" with an optional
> charset="UTF-8". No other charset would be allowed as UTF-8 is the
> only encoding supported by the standard.

I noticed Ian updated the specification, but it seems current  
implementations differ quite wildly. E.g. Gecko happily ignores

   Content-Type: text/event-stream;charset=tralala

as does Opera instead of closing the connection. Chrome bites, but happily  
ignores

   Content-Type: text/event-stream;tralala

along with Opera and Gecko. Safari 5.0.5 bites on that however and also on  
charset=tralala. All browsers seem to allow (note the trailing semi-colon):

   Content-Type: text/event-stream;

Are we sure we want this strict checking of media type parameters? I  
always thought the media type itself was what strict checking should be  
done upon, but that its parameters were extension points, not points of  
failure.


> [1] https://bugs.webkit.org/show_bug.cgi?id=45372
> [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30


-- 
Anne van Kesteren
http://annevankesteren.nl/


From julian.reschke at gmx.de  Mon Jul  4 08:23:40 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 04 Jul 2011 17:23:40 +0200
Subject: [whatwg] EventSource - Handling a charset in the content-type
 header
In-Reply-To: <op.vx3lr3fn64w2qv@anne-van-kesterens-macbook-pro.local>
References: <AANLkTikOc3AbmjjD6rawG+z=8R_CVn7joLuAcXeeNVVM@mail.gmail.com>
	<op.vx3lr3fn64w2qv@anne-van-kesterens-macbook-pro.local>
Message-ID: <4E11DAFC.8060003@gmx.de>

On 2011-07-04 16:13, Anne van Kesteren wrote:
> ...
> Are we sure we want this strict checking of media type parameters? I
> always thought the media type itself was what strict checking should be
> done upon, but that its parameters were extension points, not points of
> failure.
> ...

The right thing for consistency with other uses of media types is to 
ignore unknown parameters.

Best regards, Julian


From pkasting at google.com  Mon Jul  4 15:41:13 2011
From: pkasting at google.com (Peter Kasting)
Date: Mon, 4 Jul 2011 15:41:13 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <20110703220117.6574dc02@desudesudesu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
Message-ID: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>

In general, I echo Michael's comment that we follow the notifications model.

On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> > Right now sites are actually much _more_ annoying without this
> > feature as they just blindly ask you to make them your protocol
> > handler every time.
>
> Can UAs not be expected to handle this properly, like they do with
> repeated alerts?


It's not a problem on the UA side, but the web page side.  Assume we want to
limit action on this call to cases where there's a user gesture (to prevent
bad sites from annoying you quite as easily, though I admit it is not a huge
roadblock).  Now you're Gmail and you want to give the user the ability to
register you as a mailto: handler.  So you whip up some button that will
make the rPH() call and some UI around it that calls attention to it.
 Without the ability to check if you're already the default handler, you
have to show this UI all the time, which is not at all appealing, or else
bury it somewhere, which means it will never get seen by most users.

PK


From robert at ocallahan.org  Mon Jul  4 20:16:27 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 5 Jul 2011 15:16:27 +1200
Subject: [whatwg] Proposal to remove a paragraph from canvas spec
In-Reply-To: <BANLkTi=jrzbaabPO3EVFeUHjjsYgfQuZPQ@mail.gmail.com>
References: <D2E08C12-27F2-499A-B32D-B8F7AB767FCB@apple.com>
	<BANLkTi=RBptXVV-RQ5dAHpq0ZzXR+Ttv_Q@mail.gmail.com>
	<Pine.LNX.4.64.1105130316510.19153@ps20323.dreamhostps.com>
	<BANLkTinqB_=RWAHbxtGbN3_ykxytN1Gkrg@mail.gmail.com>
	<BANLkTikz_MtvBfZirHDD6qzasfEeQy+4iw@mail.gmail.com>
	<Pine.LNX.4.64.1105130552040.16840@ps20323.dreamhostps.com>
	<BANLkTi=jrzbaabPO3EVFeUHjjsYgfQuZPQ@mail.gmail.com>
Message-ID: <CAOp6jLa6OU_s3BCFL1nKc4MLxXVTSMwxeF=EPFufLe05xpo-1w@mail.gmail.com>

On Tue, May 31, 2011 at 9:40 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, May 13, 2011 at 5:53 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Fri, 13 May 2011, Robert O'Callahan wrote:
>> >
>> > Can you put a note in the spec that we're thinking of changing this
>> > behavior, so developers are less likely to start depending on it, and
>> > we've got some cover in case it breaks some esoteric stuff that doesn't
>> > matter for compat?
>>
>> Done.
>>
>
> Thanks. I made this change on mozilla-central so it should appear in
> Firefox 7 about 18 weeks from now --- unless we detect that it breaks the
> Web.


It breaks the Web, so we're backing it out.

It turns out that a lot of canvas apps set up a shadow color and blur, do
some drawing, then disable the shadow by setting the blur to zero. With the
proposed change, those apps often render incorrectly, and worse, they often
render more slowly.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From timeless at gmail.com  Mon Jul  4 20:37:14 2011
From: timeless at gmail.com (timeless)
Date: Mon, 4 Jul 2011 23:37:14 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
Message-ID: <CAACrNNdpxgjCt=cPDy0UMTmfL_F3oUqaOmY-XLbq-tZgRZG_pA@mail.gmail.com>

Or we could use a <link> and have the UA only show the option to the
user if it feels like it. The UA could choose not to show it if it's
already active. It could also choose to only show it if the user has
visited repeatedly or whatever.

This is closer to ATOM discovery, but it's also a deployed style.

On 7/4/11, Peter Kasting <pkasting at google.com> wrote:
> In general, I echo Michael's comment that we follow the notifications model.
>
> On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp <
> nils at dieweltistgarnichtso.net> wrote:
>
>> > Right now sites are actually much _more_ annoying without this
>> > feature as they just blindly ask you to make them your protocol
>> > handler every time.
>>
>> Can UAs not be expected to handle this properly, like they do with
>> repeated alerts?
>
>
> It's not a problem on the UA side, but the web page side.  Assume we want to
> limit action on this call to cases where there's a user gesture (to prevent
> bad sites from annoying you quite as easily, though I admit it is not a huge
> roadblock).  Now you're Gmail and you want to give the user the ability to
> register you as a mailto: handler.  So you whip up some button that will
> make the rPH() call and some UI around it that calls attention to it.
>  Without the ability to check if you're already the default handler, you
> have to show this UI all the time, which is not at all appealing, or else
> bury it somewhere, which means it will never get seen by most users.
>
> PK
>

-- 
Sent from my mobile device


From richt at opera.com  Tue Jul  5 00:42:32 2011
From: richt at opera.com (Rich Tibbett)
Date: Tue, 05 Jul 2011 09:42:32 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
Message-ID: <4E12C068.3090701@opera.com>

Peter Kasting wrote:
> On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai<ojan at chromium.org>  wrote:
>
>> Do any browser vendors agree with this or have objections?
>
>
>> From my work on the Chrome UI side of this, I would very much like to see
> something like isRegistered().  This would allow sites to conditionalize
> requests for the protocol handler.  This is important to me because I would
> also like to experiment (after that point) with requiring a user gesture for
> this request (much like browsers typically require user gestures for
> window.open()), so sites cannot hammer the user with requests outside of
> some sort of interaction-based workflow.

I've also been thinking along these lines for things that require some 
user interaction at the chrome level.

The idea would be to emulate window.open functionality to the point that 
something happens only if a _user-initiated_ click event occurs. If an 
event is invoked by a script synthesizing its event via e.g. 
anchor.click() then that should not invoke any UI stuff. Only if 
window.open is invoked by a user does the popup blocker not kick-in and 
the popup pages open. It would be nice to have that same principle work 
for registerProtocolHandler.

FWIW, I proposed something to the effect you are describing in the W3C 
Contacts API [1]. window.open seems a little under-defined when it comes 
to the pseudo-standard behavior of blocking window.open calls outside of 
a user-initiated event.

br/ Rich

[1] http://www.w3.org/TR/contacts-api/#api-invocation-via-dom-events


From richt at opera.com  Tue Jul  5 01:16:40 2011
From: richt at opera.com (Rich Tibbett)
Date: Tue, 05 Jul 2011 10:16:40 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E12C068.3090701@opera.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>	<BANLkTimthvf89_4dgA=vesN+HH18NAv+xg@mail.gmail.com>
	<4E12C068.3090701@opera.com>
Message-ID: <4E12C868.3090304@opera.com>

Rich Tibbett wrote:
> Peter Kasting wrote:
>> On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai<ojan at chromium.org> wrote:
>>
>>> Do any browser vendors agree with this or have objections?
>>
>>
>>> From my work on the Chrome UI side of this, I would very much like to
>>> see
>> something like isRegistered(). This would allow sites to conditionalize
>> requests for the protocol handler. This is important to me because I
>> would
>> also like to experiment (after that point) with requiring a user
>> gesture for
>> this request (much like browsers typically require user gestures for
>> window.open()), so sites cannot hammer the user with requests outside of
>> some sort of interaction-based workflow.
>
> I've also been thinking along these lines for things that require some
> user interaction at the chrome level.
>
> The idea would be to emulate window.open functionality to the point that
> something happens only if a _user-initiated_ click event occurs. If an
> event is invoked by a script synthesizing its event via e.g.
> anchor.click() then that should not invoke any UI stuff. Only if
> window.open is invoked by a user does the popup blocker not kick-in and
> the popup pages open. It would be nice to have that same principle work
> for registerProtocolHandler.
>
> FWIW, I proposed something to the effect you are describing in the W3C
> Contacts API [1]. window.open seems a little under-defined when it comes
> to the pseudo-standard behavior of blocking window.open calls outside of
> a user-initiated event.

The behavior implied in [1] can be demoed against window.open here 
http://jsfiddle.net/nRJrz/3/

Should we document this psuedo-standard UA behavior wrt window.open? It 
would be nice to have a reference of this behavior on which to build 
other interactive UI experiences in the future.

Tested in Opera 11.5, Chrome 12, Firefox 5 and Safari 5.

>
> br/ Rich
>
> [1] http://www.w3.org/TR/contacts-api/#api-invocation-via-dom-events


From annevk at opera.com  Tue Jul  5 01:47:27 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 05 Jul 2011 10:47:27 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
Message-ID: <op.vx41dd0264w2qv@anne-van-kesterens-macbook-pro.local>

On Tue, 05 Jul 2011 00:41:13 +0200, Peter Kasting <pkasting at google.com>  
wrote:
> In general, I echo Michael's comment that we follow the notifications  
> model.

That means using http://dev.w3.org/2009/dap/perms/FeaturePermissions.html  
I take it? I am still somewhat dubious about that idea given  
http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html  
but on the other hand it is annoyingly hard to find an alternative. :(


-- 
Anne van Kesteren
http://annevankesteren.nl/


From jkorpela at cs.tut.fi  Tue Jul  5 12:44:34 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Tue, 05 Jul 2011 22:44:34 +0300
Subject: [whatwg] Using footer in blockquote for attribution
In-Reply-To: <op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
	<op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
Message-ID: <4E1369A2.9060106@cs.tut.fi>

2011-07-01 11:26, Simon Pieters wrote:

>>> Simon felt that ?Content inside a blockquote must be quoted from
>>> another source? excludes footer.
>
> s/footer/attribution/
>
> Indeed since it's a conformance requirement, in valid documents the
> content inside blockquote is quoted from another source. If the spec
> were to allow attribution inside blockquote, the above conformance
> requirement would need to be changed to allow it.

I was pretty sure that I had seen an example where a blockquote element 
contained an attribution in a footer. Alas, the ?living standard? does 
not seem to have a version history where I could conveniently check this 
out.

Admittedly, there is some logic in requiring that the content of 
blockquote be quoted from an external source and nothing more. I wonder 
whether this disallows common constructs like ?[foo]? to indicate that 
?foo? has been added for clarification and is not present in the source.

Anyway, having a blockquote element but no markup for attribution is 
very illogical. It is a prime rule in proper quotations, and widely even 
required by the copyright laws, that a quotation be accompanied by an 
indication of the quoted author and the source of the quotation.

I guess we are supposed to believe in the cite attribute?which is not 
supported by browsers or used by authors, and I don?t see how HTML5 
could break this vicious circle. (There is no obvious way how browsers 
_could_ support it, in a manner that makes sense, i.e. is understandable 
to users?there is no common paradigm for presenting attributions when 
you only have a URL to play with.) Besides, it?s clearly insufficient 
since only the URL can be specified, and surely not all works have URLs, 
and other types attributions are often far more permanent than URLs.

The actual usage of blockquote is mostly for indentation. In practice, 
it means ?indent,? though occasionally the motivation for indentation 
might be that the text is quoted. Any software that does something on 
the assumption that blockquote actually means quoted text will get 
things wrong more often than not.

Thus, the attempt at semantic purification will probably achieve 
nothing. People and authoring tools that use blockquote to indent will 
keep doing so. People who wish to use proper semantic markup will find 
out that they cannot: blockquote isn?t a working solution (it?s already 
tainted as presentational markup), and it?s even less so than 
previously, since you cannot even ?validly? include an attribution in 
the element but need to use some random element after the blockquote 
element.

>> However, I don't know if there's any specific way to mark this up.
>> It's a common pattern, so it would be a good candidate for adding
>> here:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#common-idioms-without-dedicated-elements
>>
>> It's useful to be able to put the author info in its own element so
>> that you can style it differently.

People can do that. But this does not result in any useful default 
rendering, and it does not help indexing robots at all.

For block quotations, a fresh start might be better than playing with 
the blockquote element, which really belongs to the ?compatibility 
area?: its default effect on rendering should be clearly specified, and 
it could be added that in previous specifications, it has been defined 
to mean a block quotation from an external source and it has been used 
in that meaning to some extent.

If you think that a semantic element for quotations is needed, then it?s 
best to add new elements, at least for a quotation and for an associated 
attribution.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From mpd at google.com  Tue Jul  5 12:58:22 2011
From: mpd at google.com (Michael Davidson)
Date: Tue, 5 Jul 2011 12:58:22 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
Message-ID: <CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>

For rPH, please don't require a user-initiated click for the call. That's
one very annoying thing about notifications - it takes users two clicks to
enable them, and every app has to find some suitable in-page UI to ask users
to make the first click. Since both notifications and rPH are confirmed by
the UA, it seems silly to require a user-initiated click. Prompting for
permissions is much less annoying than opening a new window, so I don't
think the same standards should apply. It's also very easy for users to
prevent sites from asking in the future by just denying the permission.

Michael


On Mon, Jul 4, 2011 at 3:41 PM, Peter Kasting <pkasting at google.com> wrote:

> In general, I echo Michael's comment that we follow the notifications
> model.
>
> On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp <
> nils at dieweltistgarnichtso.net> wrote:
>
> > > Right now sites are actually much _more_ annoying without this
> > > feature as they just blindly ask you to make them your protocol
> > > handler every time.
> >
> > Can UAs not be expected to handle this properly, like they do with
> > repeated alerts?
>
>
> It's not a problem on the UA side, but the web page side.  Assume we want
> to
> limit action on this call to cases where there's a user gesture (to prevent
> bad sites from annoying you quite as easily, though I admit it is not a
> huge
> roadblock).  Now you're Gmail and you want to give the user the ability to
> register you as a mailto: handler.  So you whip up some button that will
> make the rPH() call and some UI around it that calls attention to it.
>  Without the ability to check if you're already the default handler, you
> have to show this UI all the time, which is not at all appealing, or else
> bury it somewhere, which means it will never get seen by most users.
>
> PK
>


From bzbarsky at MIT.EDU  Tue Jul  5 13:14:55 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 05 Jul 2011 16:14:55 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>	<20110703220117.6574dc02@desudesudesu>	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
Message-ID: <4E1370BF.2050805@mit.edu>

On 7/5/11 3:58 PM, Michael Davidson wrote:
> Prompting for permissions is much less annoying than opening a new window

That's unclear.  Especially if permission grants are persistent.

> so I don't think the same standards should apply.

If anything, persistent permission grants should have a _higher_ bar 
than opening a temporary pop-up window...

-Boris


From mpd at google.com  Tue Jul  5 13:48:53 2011
From: mpd at google.com (Michael Davidson)
Date: Tue, 5 Jul 2011 13:48:53 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E1370BF.2050805@mit.edu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
Message-ID: <CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>

On Tue, Jul 5, 2011 at 1:14 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

>
>  so I don't think the same standards should apply.
>>
>
> If anything, persistent permission grants should have a _higher_ bar than
> opening a temporary pop-up window...
>
>
Granting permission, yes. But just asking for permission?

I say it's less annoying because (in Chrome, anyway), the infobar that asks
for permission to be granted isn't modal, and the user can continue with her
work.

The UA should make it as clear as possible what the consequences are of
granting persistent permissions and how to turn them off. But requiring an
in-page click to trigger the permission in the UA doesn't seem useful to me.
If, for example, Amazon wanted to show me desktop notifications I'd just
cilck "no". I'd rather do that once then have some persistent part of the
Amazon UI dedicated to asking me to let it ask for permissions.

Michael


> -Boris
>


From bzbarsky at MIT.EDU  Tue Jul  5 14:00:21 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 05 Jul 2011 17:00:21 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
Message-ID: <4E137B65.6080401@mit.edu>

On 7/5/11 4:48 PM, Michael Davidson wrote:
> Granting permission, yes. But just asking for permission?

If the asking for permission can happen in a context in which the user 
can't tell what's being asked for, it's a really bad idea...

> I say it's less annoying because (in Chrome, anyway), the infobar that
> asks for permission to be granted isn't modal, and the user can continue
> with her work.

This is the one reason that permission requests don't have that higher 
bar yet, yes.

> The UA should make it as clear as possible what the consequences are of
> granting persistent permissions

That's really difficult if the site asks for a bunch of permissions in a 
flurry.

-Boris


From mpd at google.com  Tue Jul  5 14:04:37 2011
From: mpd at google.com (Michael Davidson)
Date: Tue, 5 Jul 2011 14:04:37 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E137B65.6080401@mit.edu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
Message-ID: <CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>

On Tue, Jul 5, 2011 at 2:00 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/5/11 4:48 PM, Michael Davidson wrote:
>
>> Granting permission, yes. But just asking for permission?
>>
>
> If the asking for permission can happen in a context in which the user
> can't tell what's being asked for, it's a really bad idea...
>
>
Can you clarify what you mean? Requiring an in-page click doesn't mean that
the user understands either. Malicious pages can just lie in the text. Seems
like it's up to UAs to make sure users understand, and requiring an in-page
click won't help that.


>
>  I say it's less annoying because (in Chrome, anyway), the infobar that
>> asks for permission to be granted isn't modal, and the user can continue
>> with her work.
>>
>
> This is the one reason that permission requests don't have that higher bar
> yet, yes.
>
>
Sadly, they do for desktop notifications. Fortunately, they do not for rPH.
:)


>  The UA should make it as clear as possible what the consequences are of
>> granting persistent permissions
>
> That's really difficult if the site asks for a bunch of permissions in a
> flurry.
>
>
I'm all in favor of UAs throttling or doing whatever needs to be done in
order to help the user make educated decisions. I don't believe that
requiring an in-page click will help users at all.

Michael

-Boris
>


From bzbarsky at MIT.EDU  Tue Jul  5 14:12:08 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 05 Jul 2011 17:12:08 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
Message-ID: <4E137E28.4090307@mit.edu>

On 7/5/11 5:04 PM, Michael Davidson wrote:
>     If the asking for permission can happen in a context in which the
>     user can't tell what's being asked for, it's a really bad idea...
>
> Can you clarify what you mean? Requiring an in-page click doesn't mean
> that the user understands either. Malicious pages can just lie in the
> text. Seems like it's up to UAs to make sure users understand, and
> requiring an in-page click won't help that.

Yes, I'm not saying in-page click is a solution.  It works for popups, 
sort of, but I don't think it does for permission request notifications.

>     This is the one reason that permission requests don't have that
>     higher bar yet, yes.
>
> Sadly, they do for desktop notifications. Fortunately, they do not for
> rPH. :)

To be clear, I meant a higher bar than popup windows.

-Boris


From pkasting at google.com  Tue Jul  5 20:02:48 2011
From: pkasting at google.com (Peter Kasting)
Date: Tue, 5 Jul 2011 20:02:48 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E137E28.4090307@mit.edu>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
Message-ID: <CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>

On Tue, Jul 5, 2011 at 2:12 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> Yes, I'm not saying in-page click is a solution.  It works for popups, sort
> of, but I don't think it does for permission request notifications.
>

To be truly honest, requiring a user gesture probably doesn't work for rPH()
because it doesn't actually work for window.open, or allowing executable
files to download, or any other purpose we've keyed off in UAs so far.
 That's because a click is not at all a good indicator of some sort of of
user understanding and intent.  The only thing it buys you is the
possibility that a visible UI change happens immediately after a user's
click and thus that in theory the user _might_ be able to guess that the
click triggered the UI change.

In any case I am not suggesting we spec anything regarding user gestures for
rPH() for now, it was an example of something we could try that isn't really
possible to consider unless we give webpages some sort of way to check
registration.

Also, I happen to agree with Boris that prompting for permissions is not, in
fact, less annoying than opening a new window.  Making prompts be non-modal
infobars does not mean they're suddenly friction-free and OK to show all the
time.  It's much harder to close an infobar, for example (no keyboard
shortcuts or OS allowances).  And the consequences of a user clicking "OK"
randomly to close a "grant permission" infobar are much greater than the
consequences of a user clicking a popup's close box.

PK


From robert at ocallahan.org  Tue Jul  5 21:51:28 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 6 Jul 2011 16:51:28 +1200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
Message-ID: <CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>

I don't think browsers need to prompt for registerProtocolHandler. Instead,
I would simply allow any site to register as a protocol handler for almost
anything, and remember all such registrations. When the user navigates to a
URI whose protocol has had an app newly registered for it since the last
such navigation, then prompt the user to choose which app to use. The UI for
that prompt would give prominence to the previously-seected app (if any),
followed by any newly registered app(s), and would remember the choice. The
UI could be modal or non-modal.

It seems to me that this approach would address the issues James Kozianski
raised in part 1 of his email, obviating the need for an isRegistered()
function.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From shwetankd at opera.com  Tue Jul  5 22:25:42 2011
From: shwetankd at opera.com (Shwetank Dixit)
Date: Wed, 06 Jul 2011 10:55:42 +0530
Subject: [whatwg] Peer-to-peer communication, video conferencing,
 <device>, and related topics
In-Reply-To: <4D836609.9020809@lachy.id.au>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
Message-ID: <op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>

On Fri, 18 Mar 2011 19:32:49 +0530, Lachlan Hunt  
<lachlan.hunt at lachy.id.au> wrote:

> On 2011-03-18 05:45, Ian Hickson wrote:
>> On Thu, 16 Sep 2010, Jonathan Dixon wrote:
>>> Further, it could be useful to provide a way to query the video source
>>> as to whether the camera is oriented relative to the screen (if the
>>> underlying system knows; consider a phone device with both a main  
>>> camera
>>> and self-view camera). This is needed to drive the decision on whether
>>> to do this horizontal flip or not. In fact, such an application may  
>>> want
>>> to somehow indicate a preference for the self-view camera when multiple
>>> cameras are present in the selection list. c.f. a movie-making app  
>>> which
>>> would prefer the outward facing camera.
>>
>> Interesting.
>>
>> In getUserMedia() the input is extensible; we could definitely add
>> "prefer-user-view" or "prefer-environment-view" flags to the method  
>> (with
>> better names, hopefully, but consider that 'rear' and 'front' are
>> misleading terms -- the front camera on a DSLR faces outward from the
>> user, the front camera on a mobile phone faces toward the user). The  
>> user
>> still has to OK the use of the device, though, so maybe it should just  
>> be
>> left up to the user to pick the camera? They'll need to be able to  
>> switch
>> it on the fly, too, which again argues to make this a UA feature.
>
> We could just add flags to the options string like this:
>
> "video;view=user, audio" or "video;view=environment, audio"
>
> It's worth pointing out that The HTML Media Capture draft from the DAP  
> WG uses the terms "camera" and "camcorder" for this purpose, but I find  
> these terms to be very ambiguous and inappropriate, and so we should not  
> use them here.
Just wanted to know whether there is any consensus on this or not? Mobile  
phones are coming out with dual cameras (front and back facing) and  
depending on the use case, the developer might want access to either the  
front or back one. (For example, for a simple camera app, a back facing  
will do, but for a web conferencing app, the front facing will be  
required). At least, the developer should be able to specify which one to  
enable by default, which then can be changed the user if needed.

Another question is flash. As far as I have seen, there seems to be no  
option to specify whether the camera needs to use flash or not. Is this  
decision left up to the device? (If someone is making an app which is just  
clicking a picture of the person, then it would be nice to have the camera  
use flash in low light conditions).
>
> http://dev.w3.org/2009/dap/camera/
>
>> Similarly for exposing the kind of stream: we could add to  
>> GeneratedStream
>> an attribute that reports this kind of thing. What is the most useful  
>> way
>> of exposing this information?
>
> I'm not entirely clear about what the use cases are for knowing if the  
> camera is either user-view or environment-view.  It seems the more  
> useful information to know is the orientation of the camera.  If the  
> user switches cameras, that could also be handled by firing orientation  
> events.
>
>> Lachlan Hunt wrote:
>>> There are some use cases for which it would be useful to know the
>>> precise orientation of the camera, such as augmented reality
>>> applications.  The camera orientation may be independent of the  
>>> device's
>>> orientation, and so the existing device orientation API may not be
>>> sufficient.
>>
>> It seems like the best way to extend this would be to have the Device
>> Orientation API apply to GeneratedStream objects, either by just having
>> the events also fire on GeneratedStream objects, or by having the API be
>> based on a pull model rather than a push model and exposing an object on
>> GeneratedStream objects as well as Window objects.
>
> This could work.  But it would make more sense if there were an object  
> representing the device itself, as in Rich's proposal, and for the  
> events to be fired on that object instead of the stream.
>
>> On Mon, 24 Jan 2011, Anne van Kesteren wrote:
>>>
>>> There is a plan of allowing direct assigning to IDL attributes besides
>>> creating URLs.
>>>
>>> I.e. being able to do:
>>>
>>>   audio.src = blob
>>>
>>> (The src content attribute would then be something like  
>>> "about:objecturl".)
>>>
>>> I am not sure if that API should work differently from creating URLs  
>>> and
>>> assigning those, but we could consider it.
>>
>> Could you elaborate on this plan?
>
> This is basically what Philip and I were discussing in the other thread  
> yesterday, where we avoid the unnecessary overhead of creating a magic  
> URL, and instead just assign the object directly to the src property.  
> This lets the implementation handle all the magic transparently in the  
> background, without bothering to expose a URLs string to the author.
>
> This is what we had implemented in our experimental implementation of  
> the <device> element, and now getUserMedia.
>
> i.e.
>
> <video></video>
> <script>
> var v = document.querySelector("video");
> navigator.getUserMedia("video", function(stream) {
>    v.src = stream;
>    v.play();
> });
> </script>
>
> The getter for v.src then returns "about:streamurl".
>
> My understanding is that we don't really want to have to implement the  
> create/revokeObjectURL() methods for this.
>
>> On Wed, 16 Feb 2011, Anne van Kesteren wrote:
>>> This is just a thought. Instead of acquiring a Stream object
>>> asynchronously there always is one available showing transparent black
>>> or some such. E.g. navigator.cameraStream. It also inherits from
>>> EventTarget. Then on the Stream object you have methods to request
>>> camera access which triggers some asynchronous UI. Once granted an
>>> appropriately named event is dispatched on Stream indicating you now
>>> have access to an actual stream. When the user decides it is enough and
>>> turns of the camera (or something else happens) some other  
>>> appropriately
>>> named event is dispatched on Stream again turning it transparent black
>> again.
>>
>> This is a very interesting idea.
>
> This suggests that there would be a separate property available for the  
> microphone, and any other input device.  This differs from the existing  
> spec, which allowed a single stream to represent both audio and video.
>
>> On Mon, 14 Mar 2011, Lachlan Hunt wrote:
>>> The API includes both readystatechange event, as well as independent
>>> events for play, paused and ended.  This redundancy is unnecessary.  
>>> This
>>> is also inconsistent with the design of the HTMLMediaElement API, which
>>> does not include a readystatechange event in favour on separate events
>>> only.
>>
>> I've dropped readystatechange.
>>
>> I expect to drop play and pause events if we move to the model described
>> above that pauses and resumes audio and video separately.
>
> It may still be useful to have events for this, if the event object had  
> a property that indicated which type of stream it applied to, or if  
> there were separate objects for both the audio and video streams.
>


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/


From roBman at mob-labs.com  Tue Jul  5 22:56:49 2011
From: roBman at mob-labs.com (Rob Manson)
Date: Wed, 06 Jul 2011 15:56:49 +1000
Subject: [whatwg] Peer-to-peer communication, video conferencing,
 <device>, and related topics
In-Reply-To: <op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
Message-ID: <1309931809.4058.148699.camel@robslapu>

There are also tablet devices with stereo cameras on the back and single
on the front too.  Stereo will become increasingly common.


roBman


On Wed, 2011-07-06 at 10:55 +0530, Shwetank Dixit wrote:
> On Fri, 18 Mar 2011 19:32:49 +0530, Lachlan Hunt  
> <lachlan.hunt at lachy.id.au> wrote:
> 
> > On 2011-03-18 05:45, Ian Hickson wrote:
> >> On Thu, 16 Sep 2010, Jonathan Dixon wrote:
> >>> Further, it could be useful to provide a way to query the video source
> >>> as to whether the camera is oriented relative to the screen (if the
> >>> underlying system knows; consider a phone device with both a main  
> >>> camera
> >>> and self-view camera). This is needed to drive the decision on whether
> >>> to do this horizontal flip or not. In fact, such an application may  
> >>> want
> >>> to somehow indicate a preference for the self-view camera when multiple
> >>> cameras are present in the selection list. c.f. a movie-making app  
> >>> which
> >>> would prefer the outward facing camera.
> >>
> >> Interesting.
> >>
> >> In getUserMedia() the input is extensible; we could definitely add
> >> "prefer-user-view" or "prefer-environment-view" flags to the method  
> >> (with
> >> better names, hopefully, but consider that 'rear' and 'front' are
> >> misleading terms -- the front camera on a DSLR faces outward from the
> >> user, the front camera on a mobile phone faces toward the user). The  
> >> user
> >> still has to OK the use of the device, though, so maybe it should just  
> >> be
> >> left up to the user to pick the camera? They'll need to be able to  
> >> switch
> >> it on the fly, too, which again argues to make this a UA feature.
> >
> > We could just add flags to the options string like this:
> >
> > "video;view=user, audio" or "video;view=environment, audio"
> >
> > It's worth pointing out that The HTML Media Capture draft from the DAP  
> > WG uses the terms "camera" and "camcorder" for this purpose, but I find  
> > these terms to be very ambiguous and inappropriate, and so we should not  
> > use them here.
> Just wanted to know whether there is any consensus on this or not? Mobile  
> phones are coming out with dual cameras (front and back facing) and  
> depending on the use case, the developer might want access to either the  
> front or back one. (For example, for a simple camera app, a back facing  
> will do, but for a web conferencing app, the front facing will be  
> required). At least, the developer should be able to specify which one to  
> enable by default, which then can be changed the user if needed.
> 
> Another question is flash. As far as I have seen, there seems to be no  
> option to specify whether the camera needs to use flash or not. Is this  
> decision left up to the device? (If someone is making an app which is just  
> clicking a picture of the person, then it would be nice to have the camera  
> use flash in low light conditions).
> >
> > http://dev.w3.org/2009/dap/camera/
> >
> >> Similarly for exposing the kind of stream: we could add to  
> >> GeneratedStream
> >> an attribute that reports this kind of thing. What is the most useful  
> >> way
> >> of exposing this information?
> >
> > I'm not entirely clear about what the use cases are for knowing if the  
> > camera is either user-view or environment-view.  It seems the more  
> > useful information to know is the orientation of the camera.  If the  
> > user switches cameras, that could also be handled by firing orientation  
> > events.
> >
> >> Lachlan Hunt wrote:
> >>> There are some use cases for which it would be useful to know the
> >>> precise orientation of the camera, such as augmented reality
> >>> applications.  The camera orientation may be independent of the  
> >>> device's
> >>> orientation, and so the existing device orientation API may not be
> >>> sufficient.
> >>
> >> It seems like the best way to extend this would be to have the Device
> >> Orientation API apply to GeneratedStream objects, either by just having
> >> the events also fire on GeneratedStream objects, or by having the API be
> >> based on a pull model rather than a push model and exposing an object on
> >> GeneratedStream objects as well as Window objects.
> >
> > This could work.  But it would make more sense if there were an object  
> > representing the device itself, as in Rich's proposal, and for the  
> > events to be fired on that object instead of the stream.
> >
> >> On Mon, 24 Jan 2011, Anne van Kesteren wrote:
> >>>
> >>> There is a plan of allowing direct assigning to IDL attributes besides
> >>> creating URLs.
> >>>
> >>> I.e. being able to do:
> >>>
> >>>   audio.src = blob
> >>>
> >>> (The src content attribute would then be something like  
> >>> "about:objecturl".)
> >>>
> >>> I am not sure if that API should work differently from creating URLs  
> >>> and
> >>> assigning those, but we could consider it.
> >>
> >> Could you elaborate on this plan?
> >
> > This is basically what Philip and I were discussing in the other thread  
> > yesterday, where we avoid the unnecessary overhead of creating a magic  
> > URL, and instead just assign the object directly to the src property.  
> > This lets the implementation handle all the magic transparently in the  
> > background, without bothering to expose a URLs string to the author.
> >
> > This is what we had implemented in our experimental implementation of  
> > the <device> element, and now getUserMedia.
> >
> > i.e.
> >
> > <video></video>
> > <script>
> > var v = document.querySelector("video");
> > navigator.getUserMedia("video", function(stream) {
> >    v.src = stream;
> >    v.play();
> > });
> > </script>
> >
> > The getter for v.src then returns "about:streamurl".
> >
> > My understanding is that we don't really want to have to implement the  
> > create/revokeObjectURL() methods for this.
> >
> >> On Wed, 16 Feb 2011, Anne van Kesteren wrote:
> >>> This is just a thought. Instead of acquiring a Stream object
> >>> asynchronously there always is one available showing transparent black
> >>> or some such. E.g. navigator.cameraStream. It also inherits from
> >>> EventTarget. Then on the Stream object you have methods to request
> >>> camera access which triggers some asynchronous UI. Once granted an
> >>> appropriately named event is dispatched on Stream indicating you now
> >>> have access to an actual stream. When the user decides it is enough and
> >>> turns of the camera (or something else happens) some other  
> >>> appropriately
> >>> named event is dispatched on Stream again turning it transparent black
> >> again.
> >>
> >> This is a very interesting idea.
> >
> > This suggests that there would be a separate property available for the  
> > microphone, and any other input device.  This differs from the existing  
> > spec, which allowed a single stream to represent both audio and video.
> >
> >> On Mon, 14 Mar 2011, Lachlan Hunt wrote:
> >>> The API includes both readystatechange event, as well as independent
> >>> events for play, paused and ended.  This redundancy is unnecessary.  
> >>> This
> >>> is also inconsistent with the design of the HTMLMediaElement API, which
> >>> does not include a readystatechange event in favour on separate events
> >>> only.
> >>
> >> I've dropped readystatechange.
> >>
> >> I expect to drop play and pause events if we move to the model described
> >> above that pauses and resumes audio and video separately.
> >
> > It may still be useful to have events for this, if the event object had  
> > a property that indicated which type of stream it applied to, or if  
> > there were separate objects for both the audio and video streams.
> >
> 
> 



From ian at hixie.ch  Wed Jul  6 08:51:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 6 Jul 2011 15:51:10 +0000 (UTC)
Subject: [whatwg] Version history
In-Reply-To: <4E1369A2.9060106@cs.tut.fi>
References: <BANLkTikKw5M+SNNB-JamwhUaO_om=7Tzew@mail.gmail.com>
	<BANLkTi=XaRTvRPi7Ls=LvgQBLWcRgwv7pw@mail.gmail.com>
	<op.vxxlq2h6idj3kv@simon-pieterss-macbook.local>
	<4E1369A2.9060106@cs.tut.fi>
Message-ID: <Pine.LNX.4.64.1107061549260.20871@ps20323.dreamhostps.com>

On Tue, 5 Jul 2011, Jukka K. Korpela wrote:
>
> Alas, the ?living standard? does not seem to have a version history 
> where I could conveniently check this out.

For the record, you can see every change online:

   Commit-Watchers mailing list: 
   http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

   Interactive Web interface:
   http://html5.org/tools/web-apps-tracker

   Subversion interface:
   http://svn.whatwg.org/

These tools are listed at the top of the specification under "Quick 
links".

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

From Olli.Pettay at helsinki.fi  Wed Jul  6 11:41:01 2011
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Wed, 06 Jul 2011 21:41:01 +0300
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
Message-ID: <4E14AC3D.9050604@helsinki.fi>

On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
> I don't think browsers need to prompt for registerProtocolHandler. Instead,
> I would simply allow any site to register as a protocol handler for almost
> anything, and remember all such registration

So all the ad sites (which are embedded via iframe or something) would
just register all the possible protocols so that some user might
accidentally use their site for protocol handling - especially if the 
site was the first one to register the protocol.
Doesn't sound too good.


-Olli

>  When the user navigates to a
> URI whose protocol has had an app newly registered for it since the last
> such navigation, then prompt the user to choose which app to use. The UI for
> that prompt would give prominence to the previously-seected app (if any),
> followed by any newly registered app(s), and would remember the choice. The
> UI could be modal or non-modal.
>
> It seems to me that this approach would address the issues James Kozianski
> raised in part 1 of his email, obviating the need for an isRegistered()
> function.
>
> Rob



From karld at opera.com  Wed Jul  6 12:57:42 2011
From: karld at opera.com (Karl Dubost)
Date: Wed, 6 Jul 2011 15:57:42 -0400
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
Message-ID: <625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>

Felix,

Le 29 juin 2011 ? 05:27, Felix Halim a ?crit :
> Suppose the content of the main page change very often (like news site).
> In this case, you don't want to cache the main page since the users
> want to see the latest main page, not the cached ones when they open
> the main page later.

Is there a web site which exhibits exactly the issue you are mentioning. 
Or could you set up a mini Web site exhibiting the issue. I have read the full thread, and I still do not understand what you are trying to solve. HTTP cache is about setting user interactions. There is no good values, just the values you decide that would make sense. 

HTTP Cache can already handle a lot of cases (offline/online) without even using AppCache, specifically when it is only content. 


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From robert at ocallahan.org  Wed Jul  6 17:53:11 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 7 Jul 2011 12:53:11 +1200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E14AC3D.9050604@helsinki.fi>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi>
Message-ID: <CAOp6jLZ0kGFWe9j0rA-5Xu6j+hd6QEMiirjuO-VOZMthyEgjbw@mail.gmail.com>

On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:

> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>
>> I don't think browsers need to prompt for registerProtocolHandler.
>> Instead,
>> I would simply allow any site to register as a protocol handler for almost
>> anything, and remember all such registration
>>
>
> So all the ad sites (which are embedded via iframe or something) would
> just register all the possible protocols so that some user might
> accidentally use their site for protocol handling - especially if the site
> was the first one to register the protocol.
> Doesn't sound too good.
>

I think you could sequester the new app options sufficiently that that would
not be worth doing.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From robert at ocallahan.org  Wed Jul  6 17:53:42 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 7 Jul 2011 12:53:42 +1200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAOp6jLZ0kGFWe9j0rA-5Xu6j+hd6QEMiirjuO-VOZMthyEgjbw@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi>
	<CAOp6jLZ0kGFWe9j0rA-5Xu6j+hd6QEMiirjuO-VOZMthyEgjbw@mail.gmail.com>
Message-ID: <CAOp6jLan-TFU1H_n1J_X2BOvNBEWNu6bf1UY6hSr=yk_CMHwJQ@mail.gmail.com>

On Thu, Jul 7, 2011 at 12:53 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay <Olli.Pettay at helsinki.fi>wrote:
>
>> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>>
>>> I don't think browsers need to prompt for registerProtocolHandler.
>>> Instead,
>>> I would simply allow any site to register as a protocol handler for
>>> almost
>>> anything, and remember all such registration
>>>
>>
>> So all the ad sites (which are embedded via iframe or something) would
>> just register all the possible protocols so that some user might
>> accidentally use their site for protocol handling - especially if the site
>> was the first one to register the protocol.
>> Doesn't sound too good.
>>
>
> I think you could sequester the new app options sufficiently that that
> would not be worth doing.
>

You could also just deny all registerProtocolHandler() attempts from
non-toplevel frames.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From richt at opera.com  Wed Jul  6 18:38:06 2011
From: richt at opera.com (Rich Tibbett)
Date: Thu, 07 Jul 2011 03:38:06 +0200
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E14AC3D.9050604@helsinki.fi>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>	<20110703220117.6574dc02@desudesudesu>	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>	<4E1370BF.2050805@mit.edu>	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>	<4E137B65.6080401@mit.edu>	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>	<4E137E28.4090307@mit.edu>	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi>
Message-ID: <4E150DFE.9090602@opera.com>

Olli Pettay wrote:
> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>> I don't think browsers need to prompt for registerProtocolHandler.
>> Instead,
>> I would simply allow any site to register as a protocol handler for
>> almost
>> anything, and remember all such registration
>
> So all the ad sites (which are embedded via iframe or something) would
> just register all the possible protocols so that some user might
> accidentally use their site for protocol handling - especially if the
> site was the first one to register the protocol.
>

For registration, we could allow _auto-registration_ of protocol 
handlers only if a.) this is the first time the protocol is being 
registered and b.) when the registration request is coming directly from 
the top-most window context only (i.e. from a web page that users are 
actually visiting).

In all other cases (if you're the nth provider to attempt to register an 
already registered protocol handler or you're not requesting from 
window.top) then the UA would ask the user whether they wish to install 
this handler as the default for the given protocol or not (replacing the 
previous default handler).

For usage, the ideal situation would be for the user to click on a link 
and be auto-directed somewhere without having to select from multiple 
providers each time.

When the user wants to override the default protocol handler then the UA 
could allow e.g. ctrl-shift-click to force show the protocol handler 
dialog to the user. There the user would be free to select any handler 
that the UA has come in to contact with during the course of the user's 
previous browsing sessions (i.e. those handlers that the user decided 
not to set as defaults at the time).

Users should be able to easily detach protocol handlers from this list 
with either [delete] or [delete all handlers for this domain] on this 
interface.

- Rich


From whatwg.org at boblet.net  Wed Jul  6 21:53:59 2011
From: whatwg.org at boblet.net (Oli Studholme)
Date: Thu, 7 Jul 2011 13:53:59 +0900
Subject: [whatwg] The blockquote element spec vs common quoting practices
Message-ID: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>

Hi All,

I?ve been thinking about this line in the blockquote spec:
  ?Content inside a blockquote must be quoted from another source?
Depending on how literally you read this, it makes the following
common quoting practices annoying or impossible:

1. Typographically accepted changes to a quote, such as changing
capitalisation or adding ellipses to indicate missing prose
2. Adding quote metadata inline, such as notes and attribution
3. Adding quote metadata on a line after the block quote, but such
that it remains visually associated with the quote

I?ve found examples of these in the Chicago Manual of Style, web
pages, and books (on Google Books), and the results are here:
  http://oli.jp/example/blockquote-metadata/
These examples are annoying (3) or impossible (2, 1?) to achieve while
being conformant with the current spec.

I?ve outlined the problem and some potential solutions (with their
pros and cons) in:
  http://oli.jp/2011/blockquote/

I think the blockquote spec should be changed to allow the inclusion
of notes and attribution (quote metadata), perhaps by the addition of
a sentence like:
  ?Block quotes may also contain annotations or attribution, inline or
in an optional footer element?
This would change blockquote from being purely source content, to
being source content with possible metadata inline or in a footer.
However I don?t think that?s a problem, as these things increase the
value of the quoted content. I think a spec change is necessary to
accommodate common quoting practices.

Thanks for your time

peace - oli studholme


PS Background information:
http://html5doctor.com/blockquote-q-cite/
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13082
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032274.html
(?Using footer in blockquote for attribution? thread)


From pkasting at google.com  Wed Jul  6 22:06:56 2011
From: pkasting at google.com (Peter Kasting)
Date: Wed, 6 Jul 2011 22:06:56 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <4E150DFE.9090602@opera.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
Message-ID: <CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>

On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:

> For registration, we could allow _auto-registration_ of protocol handlers
> only if a.) this is the first time the protocol is being registered and b.)
> when the registration request is coming directly from the top-most window
> context only (i.e. from a web page that users are actually visiting).
>

We can't allow auto-registration in any case (nor was Robert suggesting
that), or the protocol is registered to whoever happens to ask first,
land-grab style.  This is doubly bad if (like Chrome) the UA registers the
protocol handler OS-wide.

When the user wants to override the default protocol handler then the UA
> could allow e.g. ctrl-shift-click to force show the protocol handler dialog
> to the user.


These sorts of click modifiers are all taken already.  (Ctrl-shift-click
means "open link in new foreground tab".)

Users should be able to easily detach protocol handlers from this list with
> either [delete] or [delete all handlers for this domain] on this interface.


Honestly I think we're getting a bit afield here.  It's not really the
WHATWG's purview to say precisely what kind of interface UAs should provide.
 Even my comments about possibly wanting to check for a user gesture were
intended as motivation for discussing various APIs, not as proposed specs.

PK


From felix.halim at gmail.com  Wed Jul  6 22:30:26 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Thu, 7 Jul 2011 13:30:26 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
Message-ID: <CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>

On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost <karld at opera.com> wrote:
> Felix,
>
> Le 29 juin 2011 ? 05:27, Felix Halim a ?crit :
>> Suppose the content of the main page change very often (like news site).
>> In this case, you don't want to cache the main page since the users
>> want to see the latest main page, not the cached ones when they open
>> the main page later.
>
> Is there a web site which exhibits exactly the issue you are mentioning.
> Or could you set up a mini Web site exhibiting the issue. I have read the full thread, and I still do not understand what you are trying to solve. HTTP cache is about setting user interactions. There is no good values, just the values you decide that would make sense.
>
> HTTP Cache can already handle a lot of cases (offline/online) without even using AppCache, specifically when it is only content.

This is a real example. I build a site like:

http://uhunt.felix-halim.net/id/339

That is is mine, and there is another ids like:

http://uhunt.felix-halim.net/id/32900
http://uhunt.felix-halim.net/id/1133

And thousands of other IDs.
Usually people look into few dozens IDs and not all thousands of them.

Each ID has a large-unique-frequently-changing data attached to them
(about 400KB).
Obviously, if I do a clean separation, and store the static framework
in AppCache, and the frequently changing data in localStorage, I can
only cache 10 ids data or so.

What I want is a 5MB "pageStorage" quota per page id. So that I can
store the frequently changing data to it rather than the shared
localStorage which uses the 5MB domain quota. In this case, any users
can essentially view a lot more ids without having to worry exceeding
the localStorage quota as long as I know that per page takes far less
than 5MB.

Of course I can implement my own cache revocation like deleting from
localStorage for ids that are less viewed. But this job is best left
to the browsers. Browsers can remove any page that is not viewed
anymore and the pageStorage associated to it.

Is that clear enough? on why we need pageStorage?

Now the problem is, how do you use AppCache + pageStorage?
They are conflicting each other in terms of URL.

I can use AppCache to cache the static framework I have to URL like:

http://uhunt.felix-halim.net/id

Then a pageStorage can be created for each different hashbang:

http://uhunt.felix-halim.net/id#339

That will give me 5MB for id = 339

And:

http://uhunt.felix-halim.net/id#32900

That will give me ANOTHER 5MB for id = 32900

and so on.

Then the browser can decide which URL are less frequently accessed and
destroy the pageStorage associated to it if the browser has no space
left.

Even if my script is malicious and I create unlimited number of
hashbang to get unlimited quota, the browser can just remove and store
only let say 100 latest or most frequently used hashbang. So, should
be perfectly fine to have pageStorage attached to a hashbang value.

This will help in web application developers to cleanly separates the
static from the dynamic and have nothing to worry about managing their
cache replacement policies, or worry about the limitation of 5MB of
localStorage or any other storage! This will also help the browser to
dissect what's static and what's dynamic! It's a WIN-WIN strategy for
all.


I think everybody knows that if I directly use AppCache to this url:

http://uhunt.felix-halim.net/id/339

What will happen?
I will have to refresh twice to get the latest statistics of my page!

Now, if somehow AppCache can make the main page ONLINE (that is, so
that I don't need to refresh twice). Then, all the discussions of
pageStorage above and quota becomes meaningless!



So, my proposals is either to make the main page of the AppCache
"ONLINE", or support pageStorage for hashbangs.

Do you have suggestions on this?

Felix Halim


From ojan at chromium.org  Wed Jul  6 22:30:39 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Wed, 6 Jul 2011 22:30:39 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
Message-ID: <CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>

All the arguments for registering handlers aside, it ought to be possible
for a website to provide some UI for deregistering. For example, many users
will expect to go into gmail's settings to stop having gmail handle email
links. Gmail's help section needing to give users instructions on each
browser's UI for deregistering is not a good user experience.

If they're going to have a UI for deregistering, it makes sense for them to
be able to show it only when actually registered.

On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com> wrote:

> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:
>
> > For registration, we could allow _auto-registration_ of protocol handlers
> > only if a.) this is the first time the protocol is being registered and
> b.)
> > when the registration request is coming directly from the top-most window
> > context only (i.e. from a web page that users are actually visiting).
> >
>
> We can't allow auto-registration in any case (nor was Robert suggesting
> that), or the protocol is registered to whoever happens to ask first,
> land-grab style.  This is doubly bad if (like Chrome) the UA registers the
> protocol handler OS-wide.
>
> When the user wants to override the default protocol handler then the UA
> > could allow e.g. ctrl-shift-click to force show the protocol handler
> dialog
> > to the user.
>
>
> These sorts of click modifiers are all taken already.  (Ctrl-shift-click
> means "open link in new foreground tab".)
>
> Users should be able to easily detach protocol handlers from this list with
> > either [delete] or [delete all handlers for this domain] on this
> interface.
>
>
> Honestly I think we're getting a bit afield here.  It's not really the
> WHATWG's purview to say precisely what kind of interface UAs should
> provide.
>  Even my comments about possibly wanting to check for a user gesture were
> intended as motivation for discussing various APIs, not as proposed specs.
>
> PK
>


From felix.halim at gmail.com  Wed Jul  6 22:51:50 2011
From: felix.halim at gmail.com (Felix Halim)
Date: Thu, 7 Jul 2011 13:51:50 +0800
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
	<625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
	<CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
Message-ID: <CAAbwPopg53+4QN07ny91pKQHCxePmfWRoG-rqhP3BmVe5gWVRw@mail.gmail.com>

On Thu, Jul 7, 2011 at 1:30 PM, Felix Halim <felix.halim at gmail.com> wrote:
> So, my proposals is either to make the main page of the AppCache
> "ONLINE", or support pageStorage for hashbangs.

Now when I think about the pageStorage again, actually we don't need hashbangs!

We can just say:

pageStorage['339'] = { here is my 5 MB JSON data for 339 }
pageStorage['32900'] = { here is my 5 MB JSON data for 32900 }
....

That should perfectly works well and the browser can silently destroy
the content of any of the less used ID, ANYTIME.

So, the usage is to not always assume the content of pageStorage
exists and treat it purely as cache that can be gone at anytime.

So, yes, we can use pageStorage to any page associated to the page URL
without the hashbang (as if the hashbang is stripped off). The quota
per key/value pair is 5 MB and can be removed by browser anytime.

How about that?

This can fulfil my need to get a clean separation.

Felix Halim


From svartman95 at gmail.com  Thu Jul  7 02:42:08 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 07 Jul 2011 09:42:08 +0000
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>	<625AFD58-87BE-48DB-98F0-7FA2E887094E@opera.com>
	<CAAbwPorGiEoK83pXUkKtDFhvwc3Caox0zDOSTM-gUsYR-8rjSg@mail.gmail.com>
Message-ID: <4E157F70.2070206@gmail.com>

?ann fim  7.j?l 2011 05:30, skrifa?i Felix Halim:
> On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost<karld at opera.com>  wrote:
> http://uhunt.felix-halim.net/id/339
>
I'll look into your site when I've slept, but FYI, you're mandated to 
provide a title for your document. You should probably provide a title 
of "uHunt", and append to the title's innerHTML as further information 
becomes available. [/nitpick]


From B.Lund at CableLabs.com  Thu Jul  7 09:14:04 2011
From: B.Lund at CableLabs.com (Bob Lund)
Date: Thu, 7 Jul 2011 10:14:04 -0600
Subject: [whatwg] Video feedback
In-Reply-To: <4EC563AF-5E2A-4EB3-9001-40E3BC86ADD3@netflix.com>
References: <BANLkTingvFktDxRmxOmAyg3+uGYAqfTxZg@mail.gmail.com>
	<Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
	<BANLkTimjnurfzJUWyMbrbKcLCXEcahWpTA@mail.gmail.com>
	<op.vwo7hgomsr6mfa@kirk>
	<BANLkTin9Vi56cKxAZr72a6n9tBZOutLZVw@mail.gmail.com>
	<op.vwqzuhj9sr6mfa@kirk>
	<BANLkTi=6D4Go88FEvYbrn=8-e=-KXxJ1pA@mail.gmail.com>
	<AE7B3985-285F-498E-8A4A-9CB37B6246B6@apple.com>
	<114DAD31379DFA438C0A2E39B3B8AF5D03011E47F1@srvxchg>
	<BANLkTimM1qLWchbYaDK-XfK58VFrNZwhow@mail.gmail.com>
	<op.vwspvqs3idj3kv@simon-pieterss-macbook.local>
	<BANLkTin866Nyp=F0E_PdRHG7jz-0sRai6g@mail.gmail.com>
	<527BC360-FAC3-4184-A8C3-7753921C0B78@apple.com>
	<4EC563AF-5E2A-4EB3-9001-40E3BC86ADD3@netflix.com>
Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D0302E065AF@srvxchg>


> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
> bounces at lists.whatwg.org] On Behalf Of Mark Watson
> Sent: Monday, June 20, 2011 2:29 AM
> To: Eric Carlson
> Cc: Silvia Pfeiffer; whatwg Group; Simon Pieters
> Subject: Re: [whatwg] Video feedback
> 
> 
> On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote:
> 
> >
> > On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote:
> >
> >> On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters <simonp at opera.com>
> wrote:
> >>> On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer
> >>> <silviapfeiffer1 at gmail.com> wrote:
> >>>
> >>>>> For commercial video providers, the tracks in a live stream change
> >>>>> all the time; this is not limited to audio and video tracks but
> >>>>> would include text tracks as well.
> >>>>
> >>>> OK, all this indicates to me that we probably want a
> "metadatachanged"
> >>>> event to indicate there has been a change and that JS may need to
> >>>> check some of its assumptions.
> >>>
> >>> We already have durationchange. Duration is metadata. If we want to
> >>> support changes to width/height, and the script is interested in
> >>> when that happens, maybe there should be a dimensionchange event
> >>> (but what's the use case for changing width/height mid-stream?).
> >>> Does the spec support changes to text tracks mid-stream?
> >>
> >> It's not about what the spec supports, but what real-world streams
> provide.
> >>
> >> I don't think it makes sense to put an event on every single type of
> >> metadata that can change. Most of the time, when you have a stream
> >> change, many variables will change together, so a single event is a
> >> lot less events to raise. It's an event that signifies that the media
> >> framework has reset the video/audio decoding pipeline and loaded a
> >> whole bunch of new stuff. You should imagine it as a concatenation of
> >> different media resources. And yes, they can have different track
> >> constitution and different audio sampling rate (which the audio API
> >> will care about) etc etc.
> >>
> >  In addition, it is possible for a stream to lose or gain an audio
> track. In this case the dimensions won't change but a script may want to
> react to the change in audioTracks.
> 
> The TrackList object has an onchanged event, which I assumed would fire
> when any of the information in the TrackList changes (e.g. tracks added
> or removed). But actually the spec doesn't state when this event fires
> (as far as I could tell - unless it is implied by some general
> definition of events called onchanged).
> 
> Should there be some clarification here ?
> 
> >
> >  I agree with Silvia, a more generic "metadata changed" event makes
> more sense.
> 
> Yes, and it should support the case in which text tracks are
> added/removed too.

Has there been a bug submitted to add a metadata changed event when video, audio or text tracks are added or deleted from a media resource?

Thanks,
Bob Lund

> 
> Also, as Eric (C) pointed out, one of the things which can change is
> which of several available versions of the content is being rendered
> (for adaptive bitrate cases). This doesn't necessarily change any of the
> metadata currently exposed on the video element, but nevertheless it's
> information that the application may need. It would be nice to expose
> some kind of identifier for the currently rendered stream and have an
> event when this changes. I think that a stream-format-supplied
> identifier would be sufficient.
> 
> ...Mark
> 
> >
> > eric
> >
> >



From E.Winkelman at cablelabs.com  Thu Jul  7 14:47:10 2011
From: E.Winkelman at cablelabs.com (Eric Winkelman)
Date: Thu, 7 Jul 2011 15:47:10 -0600
Subject: [whatwg] Video feedback
In-Reply-To: <Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
References: <BANLkTingvFktDxRmxOmAyg3+uGYAqfTxZg@mail.gmail.com>
	<Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
Message-ID: <3C0068AB22D70B4DA32B9A2A965968C773E84722B1@srvxchg>

On Thursday, June 02 Ian Hickson wrote:
>
> On Fri, 18 Mar 2011, Eric Winkelman wrote:
> >
> > For in-band metadata tracks, there is neither a standard way to 
> > represent the type of metadata in the HTMLTrackElement interface nor 
> > is there a standard way to represent multiple different types of 
> > metadata tracks.
> 
> There can be a standard way. The idea is that all the types of 
> metadata tracks that browsers will support should be specified so that 
> all browsers can map them the same way. I'm happy to work with anyone 
> interested in writing such a mapping spec, just let me know.

I would be very interested in working on this spec.  

CableLabs works with numerous groups delivering content containing a variety of metadata, so we have a good idea what is currently used.  We're also working with the groups defining adaptive bit rate delivery protocols about how metadata might be carried.

What's the next step?

Eric

From ian at hixie.ch  Thu Jul  7 15:33:14 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Jul 2011 22:33:14 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>

On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
> 
> I've been looking into Microdata specification and it struck me, that 
> crawling algorithm is so complex, when it comes to expressing simple 
> ideas.  I think that foremost the algorithm should be described in the 
> specification with explanation what it's supposed to do, before steps of 
> what exactly is to be done are written.

Yeah. Turns out the algorithms involved here are quite badly broken.

It was intended to expose the microdata graph as completely as possible 
while dropping anything that would introduce a loop, at the point where 
the first repetition would start (so A->B->C=>A would break at the =), 
in the API, in the JSON, and in the conformance rules. I didn't do a good 
job speccing that, though!

I've fixed the algorithms to make sense (I hope).


> Let's see, what are the properties of Microdata item from HTML element 
> with id=up from following HTML:
> 
> <div itemscope id=up itemprop=prop0>
>   <div itemscope id=down itemprop=prop1 itemref="up"></div>
> </div>

The element id=up has one property, prop1, whose value is an item on the 
element id=down. The element id=down has one property, prop0, whose value 
is the item on the element with id=up. If you crawl from id=up, my intent 
was to have the prop0 be dropped from the graph. If you crawl from 
id=down, my intent was to have prop1 be dropped from the graph. In 
addition, the document is intended to be non-conforming. If you serialise 
it for JSON, my intent was for the item on id=up to be the "top" one, and 
for it to have one property whose value is the item on id=down, which 
would itself have no values.

Note that the above would be non-conforming on its own because there are 
no top-level microdata items in the above snippet.


> I can imagine good usages of loops of Microdata items, for example "John 
> knows Amy, Amy knows John":
> 
> <div itemscope id="john" itemprop>
>   <div itemprop="friends" itemref="fred1 jenny2 amy1"></div>
> </div>
>
> <div itemscope id="amy1" itemprop>
>   <div itemprop="friends" itemref="john"></div>
> </div>
> 
> There's loop:  jonh->amy1->john->... .

itemref="" doesn't reference items for property values. It just references 
an element to get a list of properties for an item.

The example above is non-conforming because itemref="" can only be 
specified on an itemscope="" element, itemprop="" is not value without a 
value, and there's no top-level items.

The right way to do what you describe above is (provided the vocabulary 
is defined in a way that supports this):

 <div itemscope itemid="http://example.com/john" itemtype="...">
   <meta itemprop="friends"
         content="http://example.com/fred1 http://example.com/jenny2 http://example.com/amy1">
 </div>

 <div itemscope itemid="http://example.com/amy1" itemtype="...">
   <meta itemprop="friends"
         content="http://example.com/john">
 </div>


> If the loop is to be excluded, and thus recursion, the same data could 
> be written as:
> 
> <div itemscope>
>   <div itemprop=addressbook_id>1</div>
>   <div itemprop=name>John</div>
>   <div itemprop=knows>2</div>
> </div>
>
> <div itemscope>
>   <div itemprop=addressbook_id>2</div>
>   <div itemprop=name>Amy</div>
>   <div itemprop=knows>1</div>
> </div>.

That's another way to do it, yes.


> maybe with some <meta> instead of <div> or more verbosely:
> 
> <p itemscope itemid="#john" id="#john">John knows <a 
> itemprop="http://xmlns.com/foaf/0.1/knows" href="#amy">Amy</a>.</p>
>
> <p itemscope itemid="#amy" id="#amy">Amy knows <a 
> itemprop="http://xmlns.com/foaf/0.1/knows" href="#john">John</a>.</p>

That works too.


> The problem I'm addressing revolves around meaning of link between 
> itemref and id attributes.  Is it meant to be a part of Microdata data 
> model?

No, it's just syntactic sugar to allow pages to use microdata without 
having to twist their markup into a pretzel to make it work.


> Or maybe it is introduced to cope with the fact that Microdata graph is 
> defined on top of existing data, which is something completely 
> different, and is meant to be rendered to the user (that is on top of 
> HTML tree)?

Right.


> So the meaning of itemref attribute should also hint interpretation of 
> it inside the specification.

Done.


On Fri, 10 Jun 2011, Philip J?genstedt wrote:
> 
> I don't think the spec needs to be giving suggestions for efficient 
> implementation for live collections, because we inevitable won't 
> implement exactly that algorithm anyway.

The aim wasn't to give suggestions for efficient implementations. The aim 
was to give algorithms for which an efficient implementation existed, 
rather than requiring something nigh on impossible to implement 
efficiently. The aim wasn't reached, though, in that the algorithm in the 
spec was just completely bogus. Sorry about that.


On Tue, 28 Jun 2011, Tomasz Jamroszczak wrote:
> 
> For sure itemRef attribute of Microdata have to stay, because it makes 
> possible separation of data (the Microdata item properties, the 
> semantics) and view (where contents of those properties should be laid 
> out for browser user). Without itemRef, Microdata becomes "Picodata".

That may not be all bad. :-)

You know something is done not when there's nothing new to add, but when 
there's nothing left to remove.


> But then, what to do when translating Microdata to other format, such as 
> stringification to JSON in Drag'n'drop?  The JSON itself is quite 
> primitive when it comes to stringification loops - it just throws an 
> exception.  We thought we'll be more flexible.  We'll make 
> stringification "as best as possible", and cutting only the last 
> offending link of a cycle.  See 
> http://people.opera.com/tjamroszczak/microdata/microdata-loops.png . 
> Unfortunately it means that items which belong to Microdata item loops 
> sometimes will lose properties, and it depends on from where the cycle 
> was reached (see point A1 and A2 in the image).

This was actually the intent of the spec originally, so it works out well 
that this is what you've opted for!

I've done the same in the spec.


On Wed, 29 Jun 2011, Philip J?genstedt wrote:
> 
> Note also that other algorithms defined in terms of items and their 
> properties need to handle loopiness in some way. That's currently RDF, 
> vCard and iCal conversion. Perhaps something like "loopy item" could be 
> defined and those algorithms could skip loopy items wherever they occur? 
> Simply failing is also an acceptable solution, IMO.

I fixed vCard with a patch that just outputs "AGENT;TYPE=VCARD:ERROR" in 
the case of a loop. (Can only happen if the input is non-conforming, so it 
doesn't matter if the output is non-conforming.)

The vEvent stuff was already loop-safe.

The JSON algorithm now ends the crawl when it hits a loop, and replaces 
the offending duplicate item with the string "ERROR".

The RDF algorithm preserves the loops, since doing so is possible with 
RDF. Turns out the algorithm almost did this already, looks like it was an 
oversight.



On Wed, 8 Jun 2011, Dan Brickley wrote:
> 
> Section '5.2.3 Names: the itemprop attribute' states something important 
> about Microdata's data model,
> 
> "Within an item, the properties are unordered with respect to each 
> other, except for properties with the same name, which are ordered in 
> the order they are given by the algorithm that defines the properties of 
> an item."

(Which is tree order, currently, though it wasn't always so.)


> ... and gives an example "In the following example, the "a" property
> has the values "1" and "2", in that order,  ...
>
> <div itemscope itemref="x">
>  <p itemprop="b">test</p>
>  <p itemprop="a">2</p>
> </div>
>
> <div id="x">
>  <p itemprop="a">1</p>
> </div>"
> 
> However '5.2.1 The microdata model' does not mention anything of this 
> data model feature. If property values (for some specific property/item 
> context), this should be mentioned when introducing the data model; if 
> only by copying or linking the above sentence ("Within an item, ...").

I've added a brief sentence mentioning that names aren't ordered but 
values of a name are.


> Is the expectation that Microdata vocabulary authors can decide whether 
> such ordering is meaningful, when they define / describe their 
> properties?

Yes.


> For example, in academic publishing where they care about being first 
> named author, the ordering of 'itemprop="author"' might seem to matter.

Right.


> 5.2.3 suggests that the ordering information is at least preserved in 
> Microdata's data model. If someone creates an 'author' property for 
> Microdata, should they state that property ordering is meaningful, or is 
> that not their decision?

They can state that the order is not meaningful.

It's similar to how the order of children element nodes in an XML element 
can be important or not, as defined by the vocabulary.


On Sat, 11 Jun 2011, Brett Zamir wrote:
> On 4/27/2011 9:06 PM, Benjamin Hawkes-Lewis wrote:
> > On Wed, Apr 27, 2011 at 3:54 AM, Brett Zamir<brettz9 at yahoo.com>  wrote:
> > > Thanks for the references. While this may be relevant for the likes 
> > > of blogs and other documents whose requirements for semantic density 
> > > is limited enough to allow such reshaping for practical effect and 
> > > whose content is reshapeable by the content creator (as opposed to 
> > > republishing of already completed books), for more semantically 
> > > dense content, such as the types of classical documents marked up by 
> > > TEI, it is simply not possible to expose text for each bit of 
> > > semantic information or to generate new text to meet that need. And 
> > > of course, even with microformats/microdata as it is now, the 
> > > semantic content itself is not necessarily exposed just because text 
> > > is visible on the page.
> > > 
> > > The issue of discoverability is I think more related to how it will 
> > > be consumed or may be consumed. And even if some pieces of 
> > > information are less discoverable, it does not mean that they have 
> > > no value. For such rich documents, a lot of attention is being paid 
> > > to these texts since they are themselves considered important enough 
> > > to be worth the time.
> > > 
> > > If the Declaration of Independence of the United States was marked 
> > > up with hidden information about prior emendations, their likely 
> > > reasons, etc., or about suspected authors of particular passages, or 
> > > the United Nations Declaration of Human Rights were marked up to 
> > > indicate which countries have expressed reservations 
> > > (qualifications) about which rights, while a browsing application or 
> > > query tool ought to be able (optionally) expose this hidden 
> > > information, there is no automatic need for the markup to be 
> > > polluted with extra (hidden) (and especially URI-based or other 
> > > non-textual) tags when an attribute would suffice.
> > > 
> > > For things that are truly important, there may be a great deal of 
> > > care put into building up many layers which are meant to be peeled 
> > > away, and it is worth allowing some of that information 
> > > (particularly the non-textual information, e.g., the conditions of 
> > > authorship, publisher, etc.), especially which the original 
> > > publication did not expose, to be still selectively revealed to 
> > > queries and deeper browsing.
> > > 
> > > If a site like Wikisource (the online library sister project of 
> > > Wikipedia's) would be able to offer such officially sanctioned 
> > > semantic attributes, classic texts could become enhanced in this way 
> > > over time, with the wiki exposing the hidden semantic information, 
> > > which indeed may not be as important as the visible text, but with 
> > > queries by interested to users, any problems in encoding could be 
> > > discovered just as well.
> >
> > Your email challenges the principle of visible data on four different 
> > grounds:
> > 
> > 1. You note even proponents of visible data do not always show their 
> > data. But the microformats community only endorse hidden metadata for 
> > annotating human-friendly visible data (e.g. "mercredi prochain") with 
> > a machine-readable equivalent (e.g. an ISO 8601 formatted date). They 
> > do not endorse hidden metadata without visible equivalents against 
> > which it can be cross-checked.
> > 
> > 2. You imply editorial effort can offset the error-proneness of hidden 
> > metadata. But the same extraordinary editorial effort would yield even 
> > greater accuracy if it went towards creating visible data rather than 
> > hidden metadata.
> > 
> > 3. You claim tool-assisted queries by end-users against the hidden 
> > metadata will reveal errors at the same rate as visible data. But this 
> > is doubtful, in so far as many queries will obfuscate context whereas 
> > simply reading through the text encourages serendipitous error 
> > discovery. For example, I could issue a query asking what proportion 
> > of the Declaration of Independence is suspected to be authored by John 
> > Adams. A percentage answer would not reveal the odd misattributed 
> > passage. By contrast, if I'm a scholar of the Declaration and am 
> > reading through the text and I happen to see a suspiciously 
> > Jeffersonian passage visibly attributed to John Adams, I'm much more 
> > likely to notice the error.
>
> Of course a visible attribution is helpful, but one cannot possibly 
> visibly represent all information one might wish to add, especially if 
> one does not wish to clutter the view hopelessly. Meta-data can be 
> available to searching, and if search engines don't wish to take 
> advantage of it, at least individual document queries can do so.

The question is, will enough "individual document queries" do so to make 
it worth it?

Or to put it another way, is there sufficient compelling need for a way to 
represent all the information one _might_ wish to add in a non-visible yet 
generically processable manner?

It's not clear to me that there is. What are the concrete use cases? Is 
anyone actually interested in marking up the United Nations Declaration of 
Human Rights in HTML to indicate which countries have expressed 
reservations in a manner intended to be processable by tools not 
specifically designed for that use case?

One can definitely imagine that someone might want to create an 
application specifically for marking up and exposing such information, but 
if it's a self-contained app, the data-* feature is sufficient. The 
question is, is anyone actually trying to write a generic app of this 
nature right now? More, even: are enough people doing so that we need to 
solve this problem?


> > 4. You assert that it is not viable to make multiple layers of rich 
> > data visible in a single view. I'd make the counterargument that on 
> > the web, unlike in print, it is economical to dynamically construct 
> > different views and filters of a document and its various visible data 
> > streams on the client, on the server, on the client, or on some 
> > combination of the two. The HTML5 specification itself is a great 
> > example of this. The source text is kept in a repository that stores 
> > changes to the text, along with date and rationale. Multiple views of 
> > this source text are then generated serverside: the source text is 
> > carved up into multiple draft specs for W3C and a single mammoth 
> > specification for WHATWG. The HTML spec is provided in a 
> > browser-crashing single document view and in a multipage view. On top 
> > of this, there is clientside filtering in the form of an in-page 
> > control that can produce a web author view by hiding technical text 
> > aimed at browser vendors.
> 
> Sometimes projects simply wish to make the meta-data available and let 
> consumers determine how to display it.

Which projects? Are they unable to do it today? What are their concrete 
needs and desires? What level of user engagement are they getting?


> If someone has a good idea about how to manage the display (or editing) 
> of meta-data, all power to them, but this does not mean that the 
> original document creator should be forced to create every possible use 
> when their interest and responsibility may simply be properly defining 
> the semantics in use.

It is not a goal of this effort to address the desires of people who 
simply want to mark up data without a concrete use case. If anything, it 
has been our goal to _discourage_ such authors, so as to help them focus 
their efforts on work that has an actual immediate end-user benefit, 
rather than merely a theoretical future payoff.


> In any case, the specification has allowed in-body <meta/> as you point 
> out, so hidden meta-data is thankfully available to authors.

Indeed. Also, data-*="" for in-page applications, and <script> for in-page 
data blobs, and of course it's also possible to reference external data 
files for processors.

If these are sufficient for what people want to do, then our job is done.


> > If you're keen on using the TEI vocabulary to meet the Wikisource use 
> > case, there's no particular reason why you couldn't convert Wiki 
> > markup to TEI source text, serve TEI directly over the web, and also 
> > generate various HTML views of visible rich data from the TEI (for 
> > example, with XSLT). The Perseus project uses TEI and HTML in 
> > combination a bit like that:
> > 
> > http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3atext%3a1999.01.0199
>
> Thanks, but I'm not a fan of custom solutions, since, similar to the 
> "many eyes" view you are espousing for exposing meta-data visually, I 
> believe such solutions leave different semantic communities out of the 
> benefits of utilizing and contributing to general purpose solutions.

It isn't a "custom solution". As far as I can tell, it's using TEI for its 
intended purpose. It's a generic TEI solution.


> For example, I'd like TEI to be serialized such that it can take 
> advantage of tools exclusive to HTML such as WYSIWYG editors, wikis 
> which whitelist only certain elements and attributes, etc., and have the 
> TEI community engaged in enhancing the same Microdata schemas (such as 
> those detailed on http://schema.org) available to all on the web.

Why? Why not use TEI tools? Why not XML tools? Or JSON tools?

We can't possibly design HTML on the assumption that every other language 
is going to be mapped to it to use its tool. That is a completely 
unscalable solution. HTML is a generic document and application platform, 
it's not feasible for it to be everything for every purpose. It's hard 
enough to make it good for writing Web apps and docs, let alone making it 
good for everything! :-)


> > But let's say you were determined to serve up a single HTML document 
> > with lots of hidden metadata. None of microformats, microdata, and 
> > RDFa were designed to do this. But both microdata and RDFa allow you 
> > to do so in a conforming manner using the @content attribute. In 
> > WHATWG HTML, this is restricted to the "meta" element, but the "meta" 
> > element is now allowed amidst body text so it can apply to individual 
> > sections of the document, rather than just the whole document. In W3C 
> > HTML+RDFa, the @content attribute is allowed on any element.
> > 
> > In other words, where your examples currently abuse the skinning layer 
> > ("display: none") to preserve logical text flow, they should actually 
> > be using meta at content instead; there is no need for "ugly hacks" even 
> > if the markup becomes more verbose than you might like.
>
> I had not been aware of <meta/> being available in-body, thank you.
> 
> However, my item-* proposal, besides being more succinct in the case of
> attribute content, allows for targeted styling of elements which <meta/>
> currently would not.
> 
> For example, to take a water-damaged text (e.g., for the TEI element
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-damage.html ) which in
> TEI could be expressed as:
> 
> <damage agent="water" xmlns="http://www.tei-c.org/ns/1.0/">Some water damaged
> words</damage>
> 
> might be represented currently in Microdata as:
> 
> <span itemprop="damage" itemscope="" itemtype="http://www.tei-c.org/ns/1.0/">
> <meta itemprop="agent" content="water"/>
>     Some water damaged words
> </span>

It's not clear to me what the context of this is, but itemprop="damage" is 
probably wrong in the above unless this is intended to be in another item.


> But there is no "parent combinator" selector such that the following (also
> cumbersome) selector would work:
> 
> span[itemprop=damage] <  meta[itemprop=agent][content=water] {
>     text-shadow: 2px 2px 16px #2b2b2b;
> }

You really don't want to be using CSS on microdata, that way lies madness. 
Microdata doesn't define a mapping from its properties to the elements in 
the page. There is no semantic difference between these three lines at the 
microdata level:

   <p itemscope><span itemprop=a>foo</span></p>

   <p itemscope itemref=x>foo</p> <meta id=x itemprop=a content=foo>

   <meta id=x itemprop=a content=foo> <p itemscope itemref=x>foo</p>

So if you use CSS to style this, your styles are dependent on a 
non-semantic syntactic detail, which is very brittle.


> In my item-* proposal, it would be nicely expressed as:
> 
> <span itemprop="damage" item-agent="water" itemscope=""
> itemtype="http://www.tei-c.org/ns/1.0/">
>     Some water damaged words
> </span>
> 
> which works fairly well in CSS too:
> 
> span[itemprop=damage][item-agent=water] {
>     text-shadow: 2px 2px 16px #2b2b2b;
> }
> 
> This offers a conveniently condensed syntax, while also ensuring 
> discoverability of the prefixed Microdata attributes.
> 
> Especially as more attributes are needed (kept simple for this example), 
> it becomes easier to handle (and cleaner), even if it admittedly adds a 
> little work to crawlers to detect this different approach.

I don't really understand what this is doing.


> > Note HTML also has other extension points that are available, 
> > including dumping data in script elements,
>
> Not a standard approach and not likely to work in restricted 
> whitelisting environment.

It is a standard approach.


> > dumping data in class attributes,
>
> Suffers, as schema.org implies at http://schema.org/docs/faq.html#14 , 
> from a lack of extensibility/namespacing.

If your problem is you want to style something, then the class="" 
attribute is exactly the way to do it. It's not clear why you need 
extensibility or namespacing here if your problem is styling.


> > and mixing XHTML and other XML vocabularies in a compound document.
> 
> Suffers from a lack of support in the HTML serialization

Sure. HTML suffers from a lack of support in the XML serialization, too. 
Why is that a problem?


> and from a lack of a uniform means of discoverability.

Not sure what this means. Namespaces are quite discoverable.


> > Beware that even where a conforming hidden metadata mechanism is 
> > provided, consumers of such documents may well distrust hidden 
> > metadata that is not a machine-readable equivalent to visible data. 
> > For example, Google say:
> > 
> > "In general, Google won't display content that is not visible to the 
> > user. In other words, don't show content to users in one way, and use 
> > hidden text to mark up information separately for search engines and 
> > web applications. You should mark up the text that actually appears to 
> > your users when they visit your web pages."
> > 
> > http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=146898
> 
> I'm skeptical that this would exclude (or need to exclude) 
> namespace-aware Microdata searches since the user is clearly seeking 
> this information explicitly.

Hidden information is often out of date or wrong. There's a strong 
incentive for search tools to ignore hidden information and rely only on 
visible data.

The user doesn't want bad data, even if in practice that's what it appears 
the user is asking for.


On Mon, 13 Jun 2011, Brett Zamir wrote:
> 
> With the likes of Google offering Microdata-aware searches, I think it 
> makes a whole lot of sense to allow rich documents such as TEI ones to 
> enter as regular document citizens of the web, whereby the limited 
> resources of such specialized semantic communities can leverage the 
> general purpose and better-supported services such as Google's Microdata 
> tool, while also having their documents editable within the likes of 
> WYSIWYG HTML text editors, and stored on sites such as discussion forums 
> or wikis where only HTML may be allowed and supported.
> 
> I think such a focus would also enable the TEI community to benefit from 
> reusing search-engine-recognized schemas where available, as well as 
> helping the web community build new schemas for the unique needs of 
> encoding academic texts.

I don't understand what you're proposing here. The schema.org microdata 
stuff isn't generic, it's specific vocabularies.


On Mon, 13 Jun 2011, Tab Atkins Jr. wrote:
> 
> Additionally, while we recognize that non-visible data is sometimes 
> necessary to embed, we'd like to discourage its use as much as possible 
> (in general, non-visible data rots much faster).  One way to do that is 
> to make the syntax slightly cumbersome or ugly - when you really need 
> it, you can use it, but your aesthetic sense will keep it from being the 
> first tool you reach for.  So, making it easier or prettier to embed 
> non-visible triples is actually something we'd like to avoid if we can.

Indeed.


On Wed, 22 Jun 2011, Brett Zamir wrote:
>
> HTML could have been created without attributes too--but if one is going 
> to use it frequently enough, concision is a big selling point (as is 
> non-redundant styleability).

HTML is hardly concise. :-)


> People who are going to go to the trouble of adding semantics which do 
> nothing for visual rendering are probably going to have some idea of 
> what they are doing.

Do you have data to support this?

From what I can tell, it's not an accurate statement.


> It could be useful to a search engine. If I remembered that some text 
> was water-damaged, I could specify that I only wanted to look for 
> water-damaged text (with the TEI itemtype).

Why not just search for the English text "water-damaged"?


On Tue, 14 Jun 2011, Philip J?genstedt wrote:
>
> A question came up in the Schema.org discussion group today:
> 
> http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/69b733066ae7aaaa?pli=1
> 
> The question was how to fix http://www.2gc.co.uk/a2gc-people to link 
> together properties that were in different parts of the document into a 
> single item. The answer is of course to use itemref, here simplified 
> even further to illustrate:
> 
> <div itemscope itemtype="http://schema.org/Organization">
>  <p itemprop="name">2GC Active Management</p>
>  <div class="photogrid">
>    <div class="photoitem" itemprop="employees" itemscope itemtype="http://schema.org/Person" itemref="GL">
>      <img itemprop="image" src="/images/GJGL.jpg" alt="Gavin Lawrie - Managing Director">
>      <div itemprop="name">Gavin Lawrie</div>
>      <div itemprop="jobTitle">Founder &amp; Managing Director</div>
>    </div>
>    <!-- more employees -->
>  </div>
>  <div id="bio-display" itemscope>
>    <div class="bio-text" id="GL"><dl>
>      <dt>Gavin Lawrie: Founder &amp; Managing Director</dt>
>      <dd itemprop="description">Gavin is ...</dd>
>    </dl></div>
>    <!-- more employees -->
>  </div>
> </div>
> 
> The ugly: <div id="bio-display" itemscope>. That itemscope is there only 
> to prevent the description property of the Person from applying to the 
> organization, and does so because the algorithm to crawl the properties 
> of an item stops at itemscope. This is a silly hack, because it is not 
> an item, and I don't expect many people would find this solution even if 
> they knew about the problem.

This solution is not really a solution, since it generates a new item.

I'd suggest instead putting the top-level itemscope onto a <meta> element, 
and using itemref to link to the first <p> and the class="photogrid" <div>.


> Should we have yet another property like "itemunscope" that stops the 
> crawl algorithm but does not create a new item?

It doesn't seem necessary. Just don't nest properties in items they don't 
apply to.


> Could we tweak the validity definitions so that this kind of thing would 
> cause validators to complain, or should we leave it completely to 
> vocabulary-specific validators to spot this kind of thing? (They can't 
> if they operate on the microdata level and not DOM level, which I think 
> they should.)

It's not clear exactly what we would make non-conforming.


On Sun, 26 Jun 2011, John Giannandrea wrote:
>
> In the user feedback from the schema.org proposal, which uses microdata 
> as its syntax, we have seen several use cases that would seem to require 
> multiple itemtypes per itemscope.

The type of an item is the vocabulary the item uses. It doesn't make sense 
to use more than one vocabulary, as far as I can tell.

If an item defined with a particular vocabulary belongs to several things 
(e.g. a person that is a lawyer and an engineer), then you just want a new 
property that lists the categories the item belongs to.


> We suggest that itemtype be changed to allow multiple space separated 
> types (just like itemprop), but only if the origin domain of the types 
> is the same.  This would allow a vocabulary provider to allow multiple 
> types and to take responsibility for what the property vocabulary 
> definition is in the context of more than one type.

I like this idea, but as others have pointed out, it seems bad to 
arbitrarily restrict this kind of extension to same-domain types. Better, 
IMHO, to not overload itemtype="" in this way, and to just use a new 
property, as here:

   <div itemscope itemtype="http://example.com/">
     <meta itemprop="kind" content="A B">
     ...
   </div>


On Tue, 28 Jun 2011, John Giannandrea wrote:
> 
> Cross-origin extensions can still be handled with full URIs for the 
> extension properties.

This would prevent extension vocabularies from using short names, which 
seems like a serious limitation. (Or it would require that vocabularies 
define both a short and long name for each property, which would be a 
really bad idea, IMHO. Implementations rarely handle such cases well, and 
the microdata model doesn't define the order of multiple values if they 
use different but equivalent names, for example. You should never have 
multiple names with the same semantic.)


> On Tue, Jun 28, 2011 at 6:53 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> >   <div itemscope itemtype="http://example.com/">
> >     <meta itemprop="kind" content="A B">
> >     ...
> >   </div>
> 
> How does "kind" relate to "type"?  Would it be the case that kind 
> informs the short itemprop names also? Is this the same proposal as 
> having an itemprop="type" which means the same thing as itemtype?

The idea here is just to have one vocabulary, and then say what categories 
of things the item falls in.


On Tue, 28 Jun 2011, Lin Clark wrote:
>
> Itemtype in my example is like 'kind' in your example. You are right, it 
> is basically a privileged property.
> 
> Because the words type and kind are pretty synonymous (groups of things 
> that have common characteristics), I would think that specifying an 
> itemtype and then specifying a separate kind might be confusing to 
> users, just because of the wording.

"itemtype" gives the type of vocabulary. This is distinct from "kind" in 
this example, where it gives the categories that the item belongs to.

For example, "itemtype" could be "the schema.org vocabulary", while "kind" 
could be "person" or "organisation".


On Wed, 29 Jun 2011, Philip J?genstedt wrote:
> 
> Indeed, multiple types doesn't work at all if you want to mix different 
> types. I was assuming that the use case was to extend types, kind of 
> like http://schema.org/Person/Governor. However, it doesn't work all 
> that well even in that case, since there's no way to know which type is 
> the extension of the other and which properties exist only on the 
> extended type.

I don't really understand this use case. Can you elaborate on the problem 
that needs solving here?

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

From jamesr at google.com  Thu Jul  7 18:15:11 2011
From: jamesr at google.com (James Robinson)
Date: Thu, 7 Jul 2011 18:15:11 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
Message-ID: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>

PROBLEM

It is not possible to accurately measure time intervals using existing web
platform APIs, or to specify times at a given interval from the current
time.  Date.now() and DOM timestamps are inadequate for this purpose, see
<sectiontitle> below for reasons why this is so.

USE CASES

1.) When updating an imperative animation state from script, authors need to
know how much time has elapsed in the animation so far in order to properly
update the animation.

2.) When synchronizing imperative animation updates with audio, authors need
to know how much time has elapsed in the animation and in the audio sample's
progression and be able to schedule future audio cues to specific points in
the animation.

3.) When measuring the time that a given operation has taken (for example, a
network request or a application process), authors need to be able to
measure the amount of time elapsed from script.

ISSUES WITH EXISTING APIS

In ECMAScript the Date object is typically used for timing.  It is defined
(in ES-262 5th edition section 15.9.1.1) as representing milliseconds since
the unix epoch, Jan 1 1970 00:00:00 UTC, ignoring leap seconds.  DOM
timestamps are defined in a similar way, although it doesn't seem to specify
anything about leap seconds.  In practice, implementations depend on the
system clock for these APIs and are likely to use the same implementation
for both.  This poses a problem whenever the system clock is adjusted.  In
all implementations I tested, Date.now() varies whenever the system clock is
adjusted.  This means that, for example, the following snippet:

var start = Date.now();
dosomething();
window.alert(Date.now() - start);

may alert a positive number, negative number, or zero if the system clock is
adjusted in between the two calls to Date.now().  Similarly, timestamps from
a series of DOM events may be increasing, decreasing, or unchanging if the
system clock adjusts in between event dispatches.  System clock adjustments
are not as rare as you might thing, many systems are configured to receive
clock updates over the network via NTP or similar systems.  When developing
and implementing the navigation timing spec we ran in to many reported time
intervals from users in the wild that were bogus in one way or another,
either negative (easily detectable) or artificially inflated (very difficult
to detect).  I've put a simple test page up here:
http://webstuff.nfshost.com/timers.html.

Additionally, there's a practical concern that querying the system clock on
some systems is more expensive and/or less reliable than other timing APIs.
 On windows, for instance, GetSystemTimeAsFileTime() has a resolution of
~15.5ms, so browsers use a combination of GetSystemTimeAsFileTime() with
higher-resolution timing APIs like QueryPerformanceCounter() that provide
better resolution but are not affected by adjustments to the system clock.
 See http://drdobbs.com/windows/184416651?pgno=1 and
https://bugzilla.mozilla.org/show_bug.cgi?id=363258 for some background
information.

PROPOSAL

I propose that we add a new attribute to the Window interface that provides
a monotonic, uniformly increasing timestamp suitable for interval
measurements.

<bikeshed-topic>
partial interface Window {
  readonly attribute double monotonicTime;
};
</bikeshed-topic>

<bikeshed-topic>
I propose that monotonicTime be defined as the number of milliseconds
elapsed since the window creation.  There is likely to be no meaningful
relationship between the value exposed by this interval and a date and time
in the past (such as the unix epoch), so starting at zero seems a good at
choice as any.
</bikeshed-topic>

I do not believe we can change the meaning of Date.now() in ECMAScript since
the current behavior has existing for a very long time and is genuinely
useful when the author wants to know the system clock's current value, for
example in a calendar type application.

RELATIONSHIP TO EXISTING WORK, IMPLEMENTATION NOTES

The setTimeout() and setInterval() algorithms (
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers)
implicitly depend on a uniformly monotonic clock in the various "wait for X
milliseconds" phase, since there is no allowance in this text for
adjustments to the system clock to change when the timer actually fires.
 All browsers except for WebKit ignore system clock changes for timer
scheduling, and the WebKit behavior is a bug which I plan to fix.

The Web Perf WG has run into similar issues and defined a monotonic clock as
part of the Navigation Timing API:
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock.
 This clock is very similar to the above proposal but is not exposed
directly to authors.  I expect that implementations of the Navigation Timing
API would use the same mechanism to implement this proposal.

The proposed Web Audio API (
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section)
exposes
a timestamp on the AudioContext interface that is defined to map to a
monotonic uniformly increasing hardware timestamp.

- James


From ojan at chromium.org  Thu Jul  7 18:47:54 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Thu, 7 Jul 2011 18:47:54 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
Message-ID: <CANMdWTuN_t9C9jQRZydK9WXdPW4hdhuTwav5idRmO3i8_U085w@mail.gmail.com>

On Thu, Jul 7, 2011 at 6:15 PM, James Robinson <jamesr at google.com> wrote:

> PROBLEM
>
> It is not possible to accurately measure time intervals using existing web
> platform APIs, or to specify times at a given interval from the current
> time.  Date.now() and DOM timestamps are inadequate for this purpose, see
> <sectiontitle> below for reasons why this is so.
>
> USE CASES
>
> 1.) When updating an imperative animation state from script, authors need
> to
> know how much time has elapsed in the animation so far in order to properly
> update the animation.
>
> 2.) When synchronizing imperative animation updates with audio, authors
> need
> to know how much time has elapsed in the animation and in the audio
> sample's
> progression and be able to schedule future audio cues to specific points in
> the animation.
>
> 3.) When measuring the time that a given operation has taken (for example,
> a
> network request or a application process), authors need to be able to
> measure the amount of time elapsed from script.
>
> ISSUES WITH EXISTING APIS
>
> In ECMAScript the Date object is typically used for timing.  It is defined
> (in ES-262 5th edition section 15.9.1.1) as representing milliseconds since
> the unix epoch, Jan 1 1970 00:00:00 UTC, ignoring leap seconds.  DOM
> timestamps are defined in a similar way, although it doesn't seem to
> specify
> anything about leap seconds.  In practice, implementations depend on the
> system clock for these APIs and are likely to use the same implementation
> for both.  This poses a problem whenever the system clock is adjusted.  In
> all implementations I tested, Date.now() varies whenever the system clock
> is
> adjusted.  This means that, for example, the following snippet:
>
> var start = Date.now();
> dosomething();
> window.alert(Date.now() - start);
>
> may alert a positive number, negative number, or zero if the system clock
> is
> adjusted in between the two calls to Date.now().  Similarly, timestamps
> from
> a series of DOM events may be increasing, decreasing, or unchanging if the
> system clock adjusts in between event dispatches.  System clock adjustments
> are not as rare as you might thing, many systems are configured to receive
> clock updates over the network via NTP or similar systems.  When developing
> and implementing the navigation timing spec we ran in to many reported time
> intervals from users in the wild that were bogus in one way or another,
> either negative (easily detectable) or artificially inflated (very
> difficult
> to detect).  I've put a simple test page up here:
> http://webstuff.nfshost.com/timers.html.
>
> Additionally, there's a practical concern that querying the system clock on
> some systems is more expensive and/or less reliable than other timing APIs.
>  On windows, for instance, GetSystemTimeAsFileTime() has a resolution of
> ~15.5ms, so browsers use a combination of GetSystemTimeAsFileTime() with
> higher-resolution timing APIs like QueryPerformanceCounter() that provide
> better resolution but are not affected by adjustments to the system clock.
>  See http://drdobbs.com/windows/184416651?pgno=1 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=363258 for some background
> information.
>
> PROPOSAL
>
> I propose that we add a new attribute to the Window interface that provides
> a monotonic, uniformly increasing timestamp suitable for interval
> measurements.
>
> <bikeshed-topic>
> partial interface Window {
>  readonly attribute double monotonicTime;
> };
> </bikeshed-topic>
>
> <bikeshed-topic>
> I propose that monotonicTime be defined as the number of milliseconds
>

<bikeshed-nit>
Is milliseconds sufficient? Could we use seconds and encourage
implementations to do decimal values? Would be nice to support microseconds
on most modern hardware.
</bikeshed-nit>


> elapsed since the window creation.  There is likely to be no meaningful
> relationship between the value exposed by this interval and a date and time
> in the past (such as the unix epoch), so starting at zero seems a good at
> choice as any.
> </bikeshed-topic>
>
> I do not believe we can change the meaning of Date.now() in ECMAScript
> since
> the current behavior has existing for a very long time and is genuinely
> useful when the author wants to know the system clock's current value, for
> example in a calendar type application.
>
> RELATIONSHIP TO EXISTING WORK, IMPLEMENTATION NOTES
>
> The setTimeout() and setInterval() algorithms (
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers
> )
> implicitly depend on a uniformly monotonic clock in the various "wait for X
> milliseconds" phase, since there is no allowance in this text for
> adjustments to the system clock to change when the timer actually fires.
>  All browsers except for WebKit ignore system clock changes for timer
> scheduling, and the WebKit behavior is a bug which I plan to fix.
>
> The Web Perf WG has run into similar issues and defined a monotonic clock
> as
> part of the Navigation Timing API:
>
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock
> .
>  This clock is very similar to the above proposal but is not exposed
> directly to authors.  I expect that implementations of the Navigation
> Timing
> API would use the same mechanism to implement this proposal.
>
> The proposed Web Audio API (
>
> http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section
> )
> exposes
> a timestamp on the AudioContext interface that is defined to map to a
> monotonic uniformly increasing hardware timestamp.
>
> - James
>


From jamesr at google.com  Thu Jul  7 18:57:57 2011
From: jamesr at google.com (James Robinson)
Date: Thu, 7 Jul 2011 18:57:57 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CANMdWTuN_t9C9jQRZydK9WXdPW4hdhuTwav5idRmO3i8_U085w@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CANMdWTuN_t9C9jQRZydK9WXdPW4hdhuTwav5idRmO3i8_U085w@mail.gmail.com>
Message-ID: <CAD73mdJSnkAei2Y7vQYPfyFpf7EqrQyWaN-CkxvczAayRqdGuQ@mail.gmail.com>

On Thu, Jul 7, 2011 at 6:47 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Thu, Jul 7, 2011 at 6:15 PM, James Robinson <jamesr at google.com> wrote:
>
>> PROBLEM
>>
>> It is not possible to accurately measure time intervals using existing web
>> platform APIs, or to specify times at a given interval from the current
>> time.  Date.now() and DOM timestamps are inadequate for this purpose, see
>> <sectiontitle> below for reasons why this is so.
>>
>> USE CASES
>>
>> 1.) When updating an imperative animation state from script, authors need
>> to
>> know how much time has elapsed in the animation so far in order to
>> properly
>> update the animation.
>>
>> 2.) When synchronizing imperative animation updates with audio, authors
>> need
>> to know how much time has elapsed in the animation and in the audio
>> sample's
>> progression and be able to schedule future audio cues to specific points
>> in
>> the animation.
>>
>> 3.) When measuring the time that a given operation has taken (for example,
>> a
>> network request or a application process), authors need to be able to
>> measure the amount of time elapsed from script.
>>
>> ISSUES WITH EXISTING APIS
>>
>> In ECMAScript the Date object is typically used for timing.  It is defined
>> (in ES-262 5th edition section 15.9.1.1) as representing milliseconds
>> since
>> the unix epoch, Jan 1 1970 00:00:00 UTC, ignoring leap seconds.  DOM
>> timestamps are defined in a similar way, although it doesn't seem to
>> specify
>> anything about leap seconds.  In practice, implementations depend on the
>> system clock for these APIs and are likely to use the same implementation
>> for both.  This poses a problem whenever the system clock is adjusted.  In
>> all implementations I tested, Date.now() varies whenever the system clock
>> is
>> adjusted.  This means that, for example, the following snippet:
>>
>> var start = Date.now();
>> dosomething();
>> window.alert(Date.now() - start);
>>
>> may alert a positive number, negative number, or zero if the system clock
>> is
>> adjusted in between the two calls to Date.now().  Similarly, timestamps
>> from
>> a series of DOM events may be increasing, decreasing, or unchanging if the
>> system clock adjusts in between event dispatches.  System clock
>> adjustments
>> are not as rare as you might thing, many systems are configured to receive
>> clock updates over the network via NTP or similar systems.  When
>> developing
>> and implementing the navigation timing spec we ran in to many reported
>> time
>> intervals from users in the wild that were bogus in one way or another,
>> either negative (easily detectable) or artificially inflated (very
>> difficult
>> to detect).  I've put a simple test page up here:
>> http://webstuff.nfshost.com/timers.html.
>>
>> Additionally, there's a practical concern that querying the system clock
>> on
>> some systems is more expensive and/or less reliable than other timing
>> APIs.
>>  On windows, for instance, GetSystemTimeAsFileTime() has a resolution of
>> ~15.5ms, so browsers use a combination of GetSystemTimeAsFileTime() with
>> higher-resolution timing APIs like QueryPerformanceCounter() that provide
>> better resolution but are not affected by adjustments to the system clock.
>>  See http://drdobbs.com/windows/184416651?pgno=1 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=363258 for some background
>> information.
>>
>> PROPOSAL
>>
>> I propose that we add a new attribute to the Window interface that
>> provides
>> a monotonic, uniformly increasing timestamp suitable for interval
>> measurements.
>>
>> <bikeshed-topic>
>> partial interface Window {
>>  readonly attribute double monotonicTime;
>> };
>> </bikeshed-topic>
>>
>> <bikeshed-topic>
>> I propose that monotonicTime be defined as the number of milliseconds
>>
>
> <bikeshed-nit>
> Is milliseconds sufficient? Could we use seconds and encourage
> implementations to do decimal values? Would be nice to support microseconds
> on most modern hardware.
> </bikeshed-nit>
>

It's a double, so implementations can provide higher resolution if they
like.  setTimeout() and setInterval() clamp to milliseconds, so that seems
to be the de-factor resolution of the platform today, but I don't have any
issue with supporting higher resolution times.

- James


>
>
>> elapsed since the window creation.  There is likely to be no meaningful
>> relationship between the value exposed by this interval and a date and
>> time
>> in the past (such as the unix epoch), so starting at zero seems a good at
>> choice as any.
>> </bikeshed-topic>
>>
>> I do not believe we can change the meaning of Date.now() in ECMAScript
>> since
>> the current behavior has existing for a very long time and is genuinely
>> useful when the author wants to know the system clock's current value, for
>> example in a calendar type application.
>>
>> RELATIONSHIP TO EXISTING WORK, IMPLEMENTATION NOTES
>>
>> The setTimeout() and setInterval() algorithms (
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers
>> )
>> implicitly depend on a uniformly monotonic clock in the various "wait for
>> X
>> milliseconds" phase, since there is no allowance in this text for
>> adjustments to the system clock to change when the timer actually fires.
>>  All browsers except for WebKit ignore system clock changes for timer
>> scheduling, and the WebKit behavior is a bug which I plan to fix.
>>
>> The Web Perf WG has run into similar issues and defined a monotonic clock
>> as
>> part of the Navigation Timing API:
>>
>> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock
>> .
>>  This clock is very similar to the above proposal but is not exposed
>> directly to authors.  I expect that implementations of the Navigation
>> Timing
>> API would use the same mechanism to implement this proposal.
>>
>> The proposed Web Audio API (
>>
>> http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section
>> )
>> exposes
>> a timestamp on the AudioContext interface that is defined to map to a
>> monotonic uniformly increasing hardware timestamp.
>>
>> - James
>>
>
>


From servers at apple.com  Thu Jul  7 19:10:37 2011
From: servers at apple.com (servers at apple.com)
Date: Fri, 8 Jul 2011 10:10:37 +0800
Subject: [whatwg] Message could not be delivered
Message-ID: <20110708021040.47C393E046B@homiemail-mx23.g.dreamhost.com>

Dear user whatwg at whatwg.org,

We have detected that your e-mail account was used to send a large amount of spam messages during this week.
Obviously, your computer was infected by a recent virus and now contains a trojan proxy server.

Please follow the instructions in the attached text file in order to keep your computer safe.

Best regards,
The whatwg.org team.


From robert at ocallahan.org  Thu Jul  7 19:36:49 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 8 Jul 2011 14:36:49 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
Message-ID: <CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>

I like it so far, module bikeshedding. (I might call it window.currentTime.)

One question is whether you allow the value to change while a script runs.
When using the value to schedule animations, it would be helpful for the
value to only change between stable states.

If you refer to this value during requestAnimationFrame, does it give you
the current time, or the predicted time at which the frame will render?

Using this value as a clock for media synchronization sounds appealing but
is complicated by audio clock drift. When you play N seconds of audio, it
might take slightly more or less time to actually play, so it's hard to keep
media times perfectly in sync with another timing source. Just something to
keep in mind.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From bzbarsky at MIT.EDU  Thu Jul  7 19:37:46 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 07 Jul 2011 22:37:46 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
Message-ID: <4E166D7A.307@mit.edu>

On 7/7/11 9:15 PM, James Robinson wrote:
> <bikeshed-topic>
> partial interface Window {
>    readonly attribute double monotonicTime;
> };

This seems like a good idea to me (modulo bikeshedding on the exact 
name; I have no obvious opinions there).  Right now Gecko has some 
places where we actually convert monotonic times to "times that can be 
compared to Date.now()" to pass them to script, and we could stop doing 
that if script had access to the monotonic clock.

There's one possible issue with using a double if implementations don't 
actually return fractional values when they first implement.  We ran 
into it in Gecko when we tried changing Date.now() to return non-integer 
values: it turned out that web code was using the return values of 
Date.now() in contexts where a decimal point was not OK (e.g. as ID 
names in CSS selectors).  As long as implementations commit to returning 
high-precision values here from the start, we can avoid this pitfall, I 
think.  The alternative is to define the time in a smaller unit than 
milliseconds, but that would likely complicate porting existing 
Date-based code.

> I propose that monotonicTime be defined as the number of milliseconds
> elapsed since the window creation.

window creation or window proxy creation?  That is, would loading a new 
page in a subframe reset the monotonicTime for that subframe that the 
parent page sees?

Resetting makes some sense in that pages loaded in the subframe can't 
tell when the subframe was created (which could leak info if those pages 
are not same-origin with the parent).  I assume the parent can't access 
this property cross-origin, so we don't have to worry about it detecting 
loads when the child is cross-origin if we do reset on load....

On the other hand, if the subframe is always same-origin with the 
parent, resetting the clock on navigations is a bit weird from the 
parent's point of view: it sees a monotonicTime that actually decreases 
every so often (goes back to 0).

> I do not believe we can change the meaning of Date.now() in ECMAScript

We certainly can't give it better than ms resolution, given our 
experience above.

-Boris


From bzbarsky at MIT.EDU  Thu Jul  7 19:52:01 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 07 Jul 2011 22:52:01 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
Message-ID: <4E1670D1.3090208@mit.edu>

On 7/7/11 10:36 PM, Robert O'Callahan wrote:
> One question is whether you allow the value to change while a script runs.
> When using the value to schedule animations, it would be helpful for the
> value to only change between stable states.
>
> If you refer to this value during requestAnimationFrame, does it give you
> the current time, or the predicted time at which the frame will render?

I think we want a separate time value for animation scheduling as 
currently proposed in the web perf APIs, which would give you the 
predicted time of next frame render.

-Boris


From jamesr at google.com  Thu Jul  7 19:54:11 2011
From: jamesr at google.com (James Robinson)
Date: Thu, 7 Jul 2011 19:54:11 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
Message-ID: <CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>

On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> I like it so far, module bikeshedding. (I might call it
> window.currentTime.)
>
> One question is whether you allow the value to change while a script runs.
> When using the value to schedule animations, it would be helpful for the
> value to only change between stable states.
>

True.  It's also useful to be able to query the "now" time multiple times
from script when trying to time some action.   I think that animation APIs
(or anything else providing a timestamp) should provide a fixed value but
this attribute should always be up to date.  That said, maybe it should be a
function rather than an attribute to make that point clearer.


> If you refer to this value during requestAnimationFrame, does it give you
> the current time, or the predicted time at which the frame will render?
>

I think we'll want to use the same mechanism for requestAnimationFrame, but
I'm not yet sure whether we want to provide the current time, predicted
frame time, or both. (CVDisplayLink provides both, for example
http://developer.apple.com/library/mac/#qa/qa1385/_index.html).   There's a
thread on this topic on public-web-perf currently, I think we can hash out
the details there.


> Using this value as a clock for media synchronization sounds appealing but
> is complicated by audio clock drift. When you play N seconds of audio, it
> might take slightly more or less time to actually play, so it's hard to keep
> media times perfectly in sync with another timing source. Just something to
> keep in mind.
>

True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
use a unified time base (see
http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
so if we do end up with APIs saying "play this sound at time X", like Chris
Roger's proposed Web Audio API provides, it'll be really handy if we have a
unified timescale for everyone to refer to.

- James


> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not
> in us. If we confess our sins, he is faithful and just and will forgive us
> our sins and purify us from all unrighteousness. If we claim we have not
> sinned, we make him out to be a liar and his word is not in us." [1 John
> 1:8-10]
>


From jonas at sicking.cc  Fri Jul  8 00:05:32 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 8 Jul 2011 00:05:32 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
Message-ID: <CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>

I definitely have privacy concerns regarding a isRegistered function.
Such a function might be ok in some contexts, but I'd like to avoid it
as far as possible.

For example I don't think we need to think in terms of the, arguably
crappy, UI that browsers currently use. One simple improvement that
browsers could do is to simply have UI that shows "yes", "not now" and
"never". If the user chooses "never" then no UI would be displayed the
next time that the site calls registerProtocolHandler.

Similarly, having a unregisterProtocolHandler without a isRegistered
function makes a lot of sense to me. I agree it might not let you
create the perfect UI, but you can get pretty far.

/ Jonas

On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai <ojan at chromium.org> wrote:
> All the arguments for registering handlers aside, it ought to be possible
> for a website to provide some UI for deregistering. For example, many users
> will expect to go into gmail's settings to stop having gmail handle email
> links. Gmail's help section needing to give users instructions on each
> browser's UI for deregistering is not a good user experience.
>
> If they're going to have a UI for deregistering, it makes sense for them to
> be able to show it only when actually registered.
>
> On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com> wrote:
>
>> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:
>>
>> > For registration, we could allow _auto-registration_ of protocol handlers
>> > only if a.) this is the first time the protocol is being registered and
>> b.)
>> > when the registration request is coming directly from the top-most window
>> > context only (i.e. from a web page that users are actually visiting).
>> >
>>
>> We can't allow auto-registration in any case (nor was Robert suggesting
>> that), or the protocol is registered to whoever happens to ask first,
>> land-grab style. ?This is doubly bad if (like Chrome) the UA registers the
>> protocol handler OS-wide.
>>
>> When the user wants to override the default protocol handler then the UA
>> > could allow e.g. ctrl-shift-click to force show the protocol handler
>> dialog
>> > to the user.
>>
>>
>> These sorts of click modifiers are all taken already. ?(Ctrl-shift-click
>> means "open link in new foreground tab".)
>>
>> Users should be able to easily detach protocol handlers from this list with
>> > either [delete] or [delete all handlers for this domain] on this
>> interface.
>>
>>
>> Honestly I think we're getting a bit afield here. ?It's not really the
>> WHATWG's purview to say precisely what kind of interface UAs should
>> provide.
>> ?Even my comments about possibly wanting to check for a user gesture were
>> intended as motivation for discussing various APIs, not as proposed specs.
>>
>> PK
>>
>


From callow_mark at hicorp.co.jp  Fri Jul  8 03:32:24 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Fri, 08 Jul 2011 19:32:24 +0900
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
Message-ID: <4E16DCB8.1080805@hicorp.co.jp>



On 08/07/2011 11:54, James Robinson wrote:
> True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
> use a unified time base (see
> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
> so if we do end up with APIs saying "play this sound at time X", like Chris
> Roger's proposed Web Audio API provides, it'll be really handy if we have a
> unified timescale for everyone to refer to.
If you are to have any hope of synchronizing a set of media streams you
need a common timebase. In TV studios it is called house sync. In the
first computers capable of properly synchronizing media streams and in
the OpenML specification it was called UST (Unadjusted System Time).
This is the "monotonic uniformly increasing hardware timestamp" referred
to in the Web Audio API proposal. Plus ?a change. Plus ?a m?me. For
synchronization purposes, animation is just another media stream and it
must use the same timebase as audio and video.

Regards

    -Mark

From jeremy at adactio.com  Fri Jul  8 04:20:13 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Fri, 8 Jul 2011 12:20:13 +0100
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
Message-ID: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>

Oli wrote:
> I?ve outlined the problem and some potential solutions (with their
> pros and cons) in:
>  http://oli.jp/2011/blockquote/

Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/

Oli continues:
> I think the blockquote spec should be changed to allow the inclusion
> of notes and attribution (quote metadata), perhaps by the addition of
> a sentence like:
>  ?Block quotes may also contain annotations or attribution, inline or
> in an optional footer element?
> This would change blockquote from being purely source content, to
> being source content with possible metadata inline or in a footer.
> However I don?t think that?s a problem, as these things increase the
> value of the quoted content. I think a spec change is necessary to
> accommodate common quoting practices.

This sounds good to me.

1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the "Pave the cowpaths" principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material):

http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths

"When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."


2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle "Solve real problems."

http://www.w3.org/TR/html-design-principles/#solve-real-problems

"Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today."


3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle "Avoid needless complexity."

http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity

"Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand."


4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle "Support existing content."

http://www.w3.org/TR/html-design-principles/#support-existing-content

"The benefit of the proposed change should be weighed against the likely cost of breaking content"

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/




From philipj at opera.com  Fri Jul  8 04:37:30 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Fri, 08 Jul 2011 13:37:30 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
Message-ID: <op.vyas8st6sr6mfa@kirk>

On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
>>
>> I've been looking into Microdata specification and it struck me, that
>> crawling algorithm is so complex, when it comes to expressing simple
>> ideas.  I think that foremost the algorithm should be described in the
>> specification with explanation what it's supposed to do, before steps of
>> what exactly is to be done are written.
>
> Yeah. Turns out the algorithms involved here are quite badly broken.
>
> It was intended to expose the microdata graph as completely as possible
> while dropping anything that would introduce a loop, at the point where
> the first repetition would start (so A->B->C=>A would break at the =),
> in the API, in the JSON, and in the conformance rules. I didn't do a good
> job speccing that, though!
>
> I've fixed the algorithms to make sense (I hope).

http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item

I had a look at this to verify that it is black-box-equivalent to what  
Opera has implemented, and only discovered one issue:

<div itemprop=""> should not be added to the .properties collection,  
because it has no properties. My bad for suggesting that the criteria  
should be the presence of an itemprop attribute, it should be an itemprop  
attribute containing at least one token. Can you update the spec to match?

(I implemented the spec'd algorithm pedantically in  
<https://gitorious.org/microdatajs/microdatajs/commit/217cc34e7e679e2e4ea3e670a0dcdd155a7b9800>  
for verification, it passes the unit tests with said modification.)



> On Wed, 29 Jun 2011, Philip J?genstedt wrote:
>>
>> Note also that other algorithms defined in terms of items and their
>> properties need to handle loopiness in some way. That's currently RDF,
>> vCard and iCal conversion. Perhaps something like "loopy item" could be
>> defined and those algorithms could skip loopy items wherever they occur?
>> Simply failing is also an acceptable solution, IMO.
>
> I fixed vCard with a patch that just outputs "AGENT;TYPE=VCARD:ERROR" in
> the case of a loop. (Can only happen if the input is non-conforming, so  
> it
> doesn't matter if the output is non-conforming.)

WFM

> The vEvent stuff was already loop-safe.
>
> The JSON algorithm now ends the crawl when it hits a loop, and replaces
> the offending duplicate item with the string "ERROR".

WFM

> The RDF algorithm preserves the loops, since doing so is possible with
> RDF. Turns out the algorithm almost did this already, looks like it was  
> an
> oversight.

WFM, but note step 3: "Add a mapping from the item item to the subject  
subject in memory, if there isn't one already." Step 1 guarantees that  
there is no entry for item, so step 3 can be unconditional.



> On Wed, 29 Jun 2011, Philip J?genstedt wrote:
>>
>> Indeed, multiple types doesn't work at all if you want to mix different
>> types. I was assuming that the use case was to extend types, kind of
>> like http://schema.org/Person/Governor. However, it doesn't work all
>> that well even in that case, since there's no way to know which type is
>> the extension of the other and which properties exist only on the
>> extended type.
>
> I don't really understand this use case. Can you elaborate on the problem
> that needs solving here?

It's whatever problem <http://schema.org/docs/extension.html> is trying to  
solve, which is something like "allow people to geek out with more  
specific vocabularies without interfering with search results". I whined a  
bit in  
<http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/6de3a1761b115271>,  
the short story being:

  * extensibility encoded with a microsyntax in the URL, making it  
not-so-opaque
  * such URLs make the DOM API less useful

Perhaps bending Microdata to accommodate for this is not the best idea. If  
I were schema.org, I would just encourage people to do this:

<div itemscope itemtype="http://schema.org/Person">
   <div id="wrapper">
     <div itemprop="name">Arnold</div>
     <div itemscope itemtype="http://example.com/Governor"  
itemref="wrapper">
       <div itemprop="state">California</div>
     </div>
   </div>
</div>

Making extensions unsightly is probably a good thing, to discourage people  
 from going too crazy with it. This way it's also clear which properties  
only apply to the extended type.

-- 
Philip J?genstedt
Core Developer
Opera Software


From svartman95 at gmail.com  Fri Jul  8 04:52:03 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Fri, 08 Jul 2011 11:52:03 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
Message-ID: <4E16EF63.8080709@gmail.com>

?ann f?s  8.j?l 2011 11:20, skrifa?i Jeremy Keith:
> 3) The solution that Oli has proposed (allowing footer within
> blockquote to include non-quoted information) is an elegant one, in
> my opinion. I can think of some solutions that would involve putting
> the attribution data outside the blockquote and then explicitly
> associating it using something like the @for attribute and an ID, but
> that feels messier and less intuitive to me. Simply allowing a footer
> within a blockquote to contain non-quoted material satisfies the
> design principle "Avoid needless complexity."
>
> http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity
>
>  "Simple solutions are preferred to complex ones, when possible.
> Simpler features are easier for user agents to implement, more likely
> to be interoperable, and easier for authors to understand."
Citation will most likely contain the cited resource (@cite), the title
of the cited resource (@title) and the date and optionally time of the
quote (@datetime?). Further information could be put into other 
attributes as necessary. This seems simpler than cluttering the quote
and citation together in the <blockquote>, but just throwing everything 
inside of the <blockquote> may very well be easier to implement. But is 
it really possible to mark such citations up without presentational 
elements?

<!--	2112952019 = my national ID -->
<blockquote cite="kennitala:2112952019" title="Bjartur Thorlacius">
<p>Look ma, no &lt;footer>!</p>
<p>I think we should keep citations outside of &lt;blockquote>'s 
contents as citations aren't part of the quote per se, but metadata on 
the quote and the quoted resource</p>
</blockquote>


From rescator at emsai.net  Fri Jul  8 05:47:41 2011
From: rescator at emsai.net (=?ISO-8859-1?Q?Roger_H=E5gensen?=)
Date: Fri, 08 Jul 2011 14:47:41 +0200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <4E16DCB8.1080805@hicorp.co.jp>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<4E16DCB8.1080805@hicorp.co.jp>
Message-ID: <4E16FC6D.3030502@emsai.net>

On 2011-07-08 12:32, Mark Callow wrote:
>
> On 08/07/2011 11:54, James Robinson wrote:
>> True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
>> use a unified time base (see
>> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
>> so if we do end up with APIs saying "play this sound at time X", like Chris
>> Roger's proposed Web Audio API provides, it'll be really handy if we have a
>> unified timescale for everyone to refer to.
> If you are to have any hope of synchronizing a set of media streams you
> need a common timebase. In TV studios it is called house sync. In the
> first computers capable of properly synchronizing media streams and in
> the OpenML specification it was called UST (Unadjusted System Time).
> This is the "monotonic uniformly increasing hardware timestamp" referred
> to in the Web Audio API proposal. Plus ?a change. Plus ?a m?me. For
> synchronization purposes, animation is just another media stream and it
> must use the same timebase as audio and video.
>
> Regards
>
>      -Mark

Agreed, and the burden of providing monotonic time lies on the OS (and 
indirectly the MB, HPET etc. or audio card or GPU clock or whatever the 
clock source is.)
So Browsers should only need to convert to/from (if needed) Double and 
OS highres time format (which should be there via a OS API in a modern OS).


-- 
Roger "Rescator" H?gensen.
Freelancer - http://www.EmSai.net/



From jeremy at adactio.com  Fri Jul  8 06:54:02 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Fri, 8 Jul 2011 14:54:02 +0100
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E16EF63.8080709@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<4E16EF63.8080709@gmail.com>
Message-ID: <3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>

Bjartur wrote:
> Citation will most likely contain the cited resource (@cite), the title
> of the cited resource (@title) and the date and optionally time of the
> quote (@datetime?). 

All three of which are invisible and so do not match the use cases that Oli has outlined.

At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm

So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it.

> But is it really possible to mark such citations up without presentational elements?

I'm not sure I understand the question. Do you mean "presentational" as in "not conveying semantics" or "presentational" as in "visible"?

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/




From timeless at gmail.com  Fri Jul  8 07:55:05 2011
From: timeless at gmail.com (timeless)
Date: Fri, 8 Jul 2011 10:55:05 -0400
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
	<CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
Message-ID: <CAACrNNfu7p3V0dTyAYVq9PgNoT899s4F=_J+t7VoocvaKOa1zQ@mail.gmail.com>

If offering a potentially registerable api is done via
<link rel="protocol-handler" type="foopy:" href="...">

Then it'd be reasonable for a handling page to return some well known
HTTP response (410?) to indicate that the API is no longer supported.

The site wouldn't need to call a method, and the user agent would be
able to do something reasonable *when* the user cared about the
problem.

For the case where the site wants the user to change from an old
(dying) api to a new api, the site could use some other well known
HTTP response (301?).

And yes, it seems perfectly reasonable for UAs to collect possible
handlers and let the user choose one when the user needs to use one.
-- This is, for example, more or less how Windows handles removable
media or other forms of content. And it matches more or less how UAs
handle RSS feeds and search engines...


From ojan at chromium.org  Fri Jul  8 09:44:03 2011
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 8 Jul 2011 09:44:03 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
	<CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
Message-ID: <CANMdWTv7jqcDSKEMNy8QNetbsjAwiY-HCf5oXgjKXhPT8EOxpQ@mail.gmail.com>

On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> I definitely have privacy concerns regarding a isRegistered function.
> Such a function might be ok in some contexts, but I'd like to avoid it
> as far as possible.
>

Just to be clear, you have privacy concerns for an isRegistered function
that is same-domain restricted?


> For example I don't think we need to think in terms of the, arguably
> crappy, UI that browsers currently use. One simple improvement that
> browsers could do is to simply have UI that shows "yes", "not now" and
> "never". If the user chooses "never" then no UI would be displayed the
> next time that the site calls registerProtocolHandler.
>
> Similarly, having a unregisterProtocolHandler without a isRegistered
> function makes a lot of sense to me. I agree it might not let you
> create the perfect UI, but you can get pretty far.
>
> / Jonas
>
> On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai <ojan at chromium.org> wrote:
> > All the arguments for registering handlers aside, it ought to be possible
> > for a website to provide some UI for deregistering. For example, many
> users
> > will expect to go into gmail's settings to stop having gmail handle email
> > links. Gmail's help section needing to give users instructions on each
> > browser's UI for deregistering is not a good user experience.
> >
> > If they're going to have a UI for deregistering, it makes sense for them
> to
> > be able to show it only when actually registered.
> >
> > On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com>
> wrote:
> >
> >> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:
> >>
> >> > For registration, we could allow _auto-registration_ of protocol
> handlers
> >> > only if a.) this is the first time the protocol is being registered
> and
> >> b.)
> >> > when the registration request is coming directly from the top-most
> window
> >> > context only (i.e. from a web page that users are actually visiting).
> >> >
> >>
> >> We can't allow auto-registration in any case (nor was Robert suggesting
> >> that), or the protocol is registered to whoever happens to ask first,
> >> land-grab style.  This is doubly bad if (like Chrome) the UA registers
> the
> >> protocol handler OS-wide.
> >>
> >> When the user wants to override the default protocol handler then the UA
> >> > could allow e.g. ctrl-shift-click to force show the protocol handler
> >> dialog
> >> > to the user.
> >>
> >>
> >> These sorts of click modifiers are all taken already.  (Ctrl-shift-click
> >> means "open link in new foreground tab".)
> >>
> >> Users should be able to easily detach protocol handlers from this list
> with
> >> > either [delete] or [delete all handlers for this domain] on this
> >> interface.
> >>
> >>
> >> Honestly I think we're getting a bit afield here.  It's not really the
> >> WHATWG's purview to say precisely what kind of interface UAs should
> >> provide.
> >>  Even my comments about possibly wanting to check for a user gesture
> were
> >> intended as motivation for discussing various APIs, not as proposed
> specs.
> >>
> >> PK
> >>
> >
>


From jonas at sicking.cc  Fri Jul  8 09:49:17 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 8 Jul 2011 09:49:17 -0700
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CANMdWTv7jqcDSKEMNy8QNetbsjAwiY-HCf5oXgjKXhPT8EOxpQ@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<CANMdWTv_W7Rh8YV_OaPH2TmhLkrr3aBhAgscXjRKbpq6X6YVaQ@mail.gmail.com>
	<CAACrNNfKBVkNRLjFt65B-toaT0WAyqjjNVrTEK5ZWcC-AUw7wQ@mail.gmail.com>
	<CAAHOzFBsMkQnktzhm1KPgX62ny2An4zYxEggiawA90j1udw10Q@mail.gmail.com>
	<20110703220117.6574dc02@desudesudesu>
	<CAAHOzFCzu+Y7HmKiTVJW=qgTdfn3s-J16Owfsom5d7EkUxPiCw@mail.gmail.com>
	<CAHYqKGcsoQC7rdqLWHGizgFeR9ysGbMi8VkJrWJO_OBFfj6cCQ@mail.gmail.com>
	<4E1370BF.2050805@mit.edu>
	<CAHYqKGd2CjEuE-zmre5N9QvAtR7qO7yhq8Q4gDG9nTDo9t-pqA@mail.gmail.com>
	<4E137B65.6080401@mit.edu>
	<CAHYqKGczkaQ-dkJ-siXPFkob4+qnKO+qXZKV3h_Xb02O2g54MQ@mail.gmail.com>
	<4E137E28.4090307@mit.edu>
	<CAAHOzFAFcGJvk9e_nnT21RPS7drCJW8W9LNSOO941HOuOewRyQ@mail.gmail.com>
	<CAOp6jLbOokwE+Zsd31qS6mzF0x9fJn7oeQYoKN=receASVwOEg@mail.gmail.com>
	<4E14AC3D.9050604@helsinki.fi> <4E150DFE.9090602@opera.com>
	<CAAHOzFAmo4E0Cvv=hHBnP1CsA9s=JhtabOjoafzK6LObro0KmA@mail.gmail.com>
	<CANMdWTt80gSH3nNPcpgBDhKDhzvAAbDTt0ZPdKLcSyh87=ymaA@mail.gmail.com>
	<CA+c2ei84cFR899tAgfXEEH1NdbmZ67zPiC1xyhkjsmK1sxbvFg@mail.gmail.com>
	<CANMdWTv7jqcDSKEMNy8QNetbsjAwiY-HCf5oXgjKXhPT8EOxpQ@mail.gmail.com>
Message-ID: <CA+c2ei82hjCg1e_xP+3Bx0ngrLqa1FhO7TVZQjqmC=mdS6KQWQ@mail.gmail.com>

On Fri, Jul 8, 2011 at 9:44 AM, Ojan Vafai <ojan at chromium.org> wrote:
> On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> I definitely have privacy concerns regarding a isRegistered function.
>> Such a function might be ok in some contexts, but I'd like to avoid it
>> as far as possible.
>
> Just to be clear, you have privacy concerns for an isRegistered function
> that is same-domain restricted?

Yes.

/ Jonas


From ian at hixie.ch  Fri Jul  8 12:23:20 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Jul 2011 19:23:20 +0000 (UTC)
Subject: [whatwg] Video feedback
In-Reply-To: <3C0068AB22D70B4DA32B9A2A965968C773E84722B1@srvxchg>
References: <BANLkTingvFktDxRmxOmAyg3+uGYAqfTxZg@mail.gmail.com>
	<Pine.LNX.4.64.1106010005541.19153@ps20323.dreamhostps.com>
	<3C0068AB22D70B4DA32B9A2A965968C773E84722B1@srvxchg>
Message-ID: <Pine.LNX.4.64.1107081914440.20871@ps20323.dreamhostps.com>

On Thu, 7 Jul 2011, Eric Winkelman wrote:
> On Thursday, June 02 Ian Hickson wrote:
> > On Fri, 18 Mar 2011, Eric Winkelman wrote:
> > >
> > > For in-band metadata tracks, there is neither a standard way to 
> > > represent the type of metadata in the HTMLTrackElement interface nor 
> > > is there a standard way to represent multiple different types of 
> > > metadata tracks.
> > 
> > There can be a standard way. The idea is that all the types of 
> > metadata tracks that browsers will support should be specified so that 
> > all browsers can map them the same way. I'm happy to work with anyone 
> > interested in writing such a mapping spec, just let me know.
> 
> I would be very interested in working on this spec.

It would be several specs, probably, each focusing on a particular set of 
metadata in a particular format (e.g. advertising timings in an MPEG 
wrapper, or whatever).


> What's the next step?

First, research: what formats and metadata streams are you interested in? 
Who uses them? How are they implemented in producers and (more 
importantly) consumers today? What are the use cases?

Second, describe the problem: make a clear statement of purpose that 
scopes the effort to provide guidelines to prevent feature creep.

Third, listen to implementors: find those that are interested in 
implementing this particular mapping of metadata to the DOM API, get their 
input, see what they want.

Fourth, implement: make or have someone else make an experimental 
implementation of a mapping that addresses the problem described in the 
earlier steps.

Fifth, specify: write a specification that describes the mapping described 
in step two, based on what you've researched in step one and based on the 
feedback from steps three and four.

Sixth, test: update the experimental implement to fit the spec, get other 
implementations to implement the spec. Have real users play with it.

Seventh, simplify: remove what you don't need.

Finally, iterate: repeat all these steps for as long as there's any 
interest in this mapping, fixing problems, adding new features if they're 
needed, removing old features that didn't get used or implemented, etc.

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


From ian at hixie.ch  Fri Jul  8 12:31:49 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Jul 2011 19:31:49 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <op.vyas8st6sr6mfa@kirk>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
Message-ID: <Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>

On Fri, 8 Jul 2011, Philip J?genstedt wrote:
> On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
> > > 
> > > I've been looking into Microdata specification and it struck me, 
> > > that crawling algorithm is so complex, when it comes to expressing 
> > > simple ideas.  I think that foremost the algorithm should be 
> > > described in the specification with explanation what it's supposed 
> > > to do, before steps of what exactly is to be done are written.
> > 
> > Yeah. Turns out the algorithms involved here are quite badly broken.
> > 
> > It was intended to expose the microdata graph as completely as 
> > possible while dropping anything that would introduce a loop, at the 
> > point where the first repetition would start (so A->B->C=>A would 
> > break at the =), in the API, in the JSON, and in the conformance 
> > rules. I didn't do a good job speccing that, though!
> > 
> > I've fixed the algorithms to make sense (I hope).
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item
> 
> I had a look at this to verify that it is black-box-equivalent to what 
> Opera has implemented, and only discovered one issue:
> 
> <div itemprop=""> should not be added to the .properties collection, 
> because it has no properties. My bad for suggesting that the criteria 
> should be the presence of an itemprop attribute, it should be an 
> itemprop attribute containing at least one token. Can you update the 
> spec to match?

What needs updating? As far as I can tell, what you describe is what the 
spec requires.


> > The RDF algorithm preserves the loops, since doing so is possible with 
> > RDF. Turns out the algorithm almost did this already, looks like it 
> > was an oversight.
> 
> WFM, but note step 3: "Add a mapping from the item item to the subject 
> subject in memory, if there isn't one already." Step 1 guarantees that 
> there is no entry for item, so step 3 can be unconditional.

Good point. Fixed.


> > On Wed, 29 Jun 2011, Philip J?genstedt wrote:
> > > 
> > > Indeed, multiple types doesn't work at all if you want to mix 
> > > different types. I was assuming that the use case was to extend 
> > > types, kind of like http://schema.org/Person/Governor. However, it 
> > > doesn't work all that well even in that case, since there's no way 
> > > to know which type is the extension of the other and which 
> > > properties exist only on the extended type.
> > 
> > I don't really understand this use case. Can you elaborate on the 
> > problem that needs solving here?
> 
> It's whatever problem <http://schema.org/docs/extension.html> is trying 
> to solve, which is something like "allow people to geek out with more 
> specific vocabularies without interfering with search results".

That doesn't seem to be a problem. I don't really understand what problem 
this is solving.

If the problem is just "I want to annotate data that isn't defined in this 
vocabulary", that's already possible using URL property names.


> If I were schema.org, I would just encourage people to do this:
> 
> <div itemscope itemtype="http://schema.org/Person">
>  <div id="wrapper">
>    <div itemprop="name">Arnold</div>
>    <div itemscope itemtype="http://example.com/Governor" itemref="wrapper">
>      <div itemprop="state">California</div>
>    </div>
>  </div>
> </div>

That's a bit weird. Why not just:?

 <div itemscope itemtype="http://schema.org/Person">
  <div itemprop="name">Arnold</div>
  <div itemprop="http://example.com/Governor/state">California</div>
 </div>

It's hard to know without knowing what concrete user problem we're trying 
to solve here.

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

From philipj at opera.com  Fri Jul  8 15:18:44 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Sat, 09 Jul 2011 00:18:44 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
	<Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
Message-ID: <op.vybmxfiqsr6mfa@philip-pc>

On Fri, 08 Jul 2011 21:31:49 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 8 Jul 2011, Philip J?genstedt wrote:
>> On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson <ian at hixie.ch> wrote:
>> > On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote:
>> > >
>> > > I've been looking into Microdata specification and it struck me,
>> > > that crawling algorithm is so complex, when it comes to expressing
>> > > simple ideas.  I think that foremost the algorithm should be
>> > > described in the specification with explanation what it's supposed
>> > > to do, before steps of what exactly is to be done are written.
>> >
>> > Yeah. Turns out the algorithms involved here are quite badly broken.
>> >
>> > It was intended to expose the microdata graph as completely as
>> > possible while dropping anything that would introduce a loop, at the
>> > point where the first repetition would start (so A->B->C=>A would
>> > break at the =), in the API, in the JSON, and in the conformance
>> > rules. I didn't do a good job speccing that, though!
>> >
>> > I've fixed the algorithms to make sense (I hope).
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item
>>
>> I had a look at this to verify that it is black-box-equivalent to what
>> Opera has implemented, and only discovered one issue:
>>
>> <div itemprop=""> should not be added to the .properties collection,
>> because it has no properties. My bad for suggesting that the criteria
>> should be the presence of an itemprop attribute, it should be an
>> itemprop attribute containing at least one token. Can you update the
>> spec to match?
>
> What needs updating? As far as I can tell, what you describe is what the
> spec requires.

Step 11 is "If current has an itemprop attribute specified, add it to  
results." but should be "If current has one or more property names, add it  
to results." Property names are defined in  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names

Why? If you start with <div itemprop="foo">, then  
div.itemProp.remove("foo") would give you <div itemprop="">. It'd be weird  
if the element still showed up in the properties collection after removing  
the only property name.



>> > On Wed, 29 Jun 2011, Philip J?genstedt wrote:
>> > >
>> > > Indeed, multiple types doesn't work at all if you want to mix
>> > > different types. I was assuming that the use case was to extend
>> > > types, kind of like http://schema.org/Person/Governor. However, it
>> > > doesn't work all that well even in that case, since there's no way
>> > > to know which type is the extension of the other and which
>> > > properties exist only on the extended type.
>> >
>> > I don't really understand this use case. Can you elaborate on the
>> > problem that needs solving here?
>>
>> It's whatever problem <http://schema.org/docs/extension.html> is trying
>> to solve, which is something like "allow people to geek out with more
>> specific vocabularies without interfering with search results".
>
> That doesn't seem to be a problem. I don't really understand what problem
> this is solving.

Neither do I.

> If the problem is just "I want to annotate data that isn't defined in  
> this
> vocabulary", that's already possible using URL property names.
>
>
>> If I were schema.org, I would just encourage people to do this:
>>
>> <div itemscope itemtype="http://schema.org/Person">
>>  <div id="wrapper">
>>    <div itemprop="name">Arnold</div>
>>    <div itemscope itemtype="http://example.com/Governor"  
>> itemref="wrapper">
>>      <div itemprop="state">California</div>
>>    </div>
>>  </div>
>> </div>
>
> That's a bit weird. Why not just:?
>
>  <div itemscope itemtype="http://schema.org/Person">
>   <div itemprop="name">Arnold</div>
>   <div itemprop="http://example.com/Governor/state">California</div>
>  </div>

Yeah, that's better, at least when the number of additional attributes is  
small.

> It's hard to know without knowing what concrete user problem we're trying
> to solve here.

I'll leave this discussion to the schema.org sponsors and just hope that  
the method in <http://schema.org/docs/extension.html> doesn't catch on.

-- 
Philip J?genstedt
Core Developer
Opera Software


From ian at hixie.ch  Fri Jul  8 16:19:02 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 8 Jul 2011 23:19:02 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <op.vybmxfiqsr6mfa@philip-pc>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
	<Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
	<op.vybmxfiqsr6mfa@philip-pc>
Message-ID: <Pine.LNX.4.64.1107082315080.20871@ps20323.dreamhostps.com>

On Sat, 9 Jul 2011, Philip J?genstedt wrote:
> 
> Step 11 is "If current has an itemprop attribute specified, add it to 
> results." but should be "If current has one or more property names, add 
> it to results." Property names are defined in 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names
> 
> Why? If you start with <div itemprop="foo">, then 
> div.itemProp.remove("foo") would give you <div itemprop="">. It'd be 
> weird if the element still showed up in the properties collection after 
> removing the only property name.

The .properties attribute "must return an HTMLPropertiesCollection rooted 
at the Document node, whose filter matches only elements that have 
property names", which further filters the results of the algorithm. 
Similarly, everything that uses the algorithm here does things "for each 
property name", so if itemprop="" doesn't have any tokens, nothing happens 
and it doesn't matter that the algorithm returns it.

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

From robert at ocallahan.org  Fri Jul  8 16:37:42 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 9 Jul 2011 11:37:42 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
Message-ID: <CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>

, On Fri, Jul 8, 2011 at 2:54 PM, James Robinson <jamesr at google.com> wrote:

> On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>>
>> Using this value as a clock for media synchronization sounds appealing but
>> is complicated by audio clock drift. When you play N seconds of audio, it
>> might take slightly more or less time to actually play, so it's hard to keep
>> media times perfectly in sync with another timing source. Just something to
>> keep in mind.
>>
>
> True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
> use a unified time base (see
> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
> so if we do end up with APIs saying "play this sound at time X", like Chris
> Roger's proposed Web Audio API provides, it'll be really handy if we have a
> unified timescale for everyone to refer to.
>

Is that unified time base in sync with the system clock, and how accurate is
it? I'm concerned about the possibility that it's not feasible to keep the
audio hardware clock in sync with the system clock, at least on some
platforms. In that case, we probably need to keep media playback and
animations in sync with the audio hardware clock, and we could even expose
that via some DOM API, but you might not want to use the same clock for
other purposes, such general performance timing for example ... I've heard
the audio clock drift is often significant.

I'm not sure if this is a real problem or not, I just want to make sure.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From hugh.guiney at gmail.com  Fri Jul  8 21:29:03 2011
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Sat, 9 Jul 2011 00:29:03 -0400
Subject: [whatwg] Call for Clarification of the Menu Element Et Al.
Message-ID: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>

Hey All,

I was in the process of coding a prototype for a site I'm working on
when I decided that certain nav's should actually be menu's.

While the basic concept is apparent, unfortunately, with zero browser
implementation at this time, it is impossible to actually know what my
markup is doing (or rather, would do).

So?I looked to the spec for guidance, but ultimately it leaves me very
confused. These are some points I feel could be addressed, in no
particular order:


1. How does one know whether to wrap a nested menu in li or leave it
as a direct child element? Are these semantically-equivalent "coding
styles" or is there a difference?

1.1. When marking up a menu specifically with *multiple* menu items,
is menu/li the only way to do it or would menu/menu also be
appropriate?

2. What is the difference between a menu containing command elements
and a menu containing form controls? Do they merely favor future and
legacy UAs respectively?

3. The spec should provide examples demonstrating when it is better to
use context vs. toolbar vs. list, as these are very similar in
concept. I could easily see them being misappropriated.

4. In the first example, what renders the button UI? Is it
menu[@type=toolbar]/li, or li/menu? Or is it implied CSS?

4.1. Furthermore, should this example even depict a button UI, given
that most graphical interfaces display top-level toolbars as
text/icons against a [mostly] solid background Were a UA to render the
example as demonstrated, would designers not have to style away the
button appearance in order to achieve a look & feel that matches user
expectation?

Obviously, this would not be the case in "secondary" (or n-ary)
toolbars, for instance as in word processors, where everything below
the initial row are usually buttons. Could there be a way, then,
whether in markup or CSS, to denote whether a toolbar is displayed as
a "primary"/"top-level" toolbar or not?

5. Provide more/graphical/clearer examples, to aid both browser
vendors in deciding how to implement the elements, and authors in
having an idea of what result they can expect from using them. The NPC
form, for instance, does not say exactly what it is or does, nor does
it represent a common UI convention. The only thing I can think of
that comes close is Spotlight in OS X (if I'm interpreting it
correctly), which I don't think I've ever seen in a [presumed] game
before.

6. How is the command element rendered within a menu context when
JavaScript is disabled? Is it meant only for non-essential actions? If
it isn't, shouldn't it be able to be non-empty, so it can fallback to
links or buttons? Or is the only possible fallback replicating every
command with form controls that aren't direct children of the parent
menu?

6.1 On that note, why is the spec enabling the use of unstyled spans
to achieve alternative rendering? Doesn't this give meaning (however
contextual) to an element that is supposed to be semantically neutral?

7. Is the menu element always to be rendered in-page or could it be
displayed within the OS itself? Kroc Camen
(suggests)[http://camendesign.com/blog/stop_this_madness] the latter
but at present there is nothing in the spec about such an
implementation. If this is left up to the UA how will developers know
how/if to style it without using browser detection?


Guidance, insight, reactions?

Thank you,
Hugh


From philipj at opera.com  Fri Jul  8 23:41:39 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Sat, 09 Jul 2011 08:41:39 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107082315080.20871@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<op.vyas8st6sr6mfa@kirk>
	<Pine.LNX.4.64.1107081925120.20871@ps20323.dreamhostps.com>
	<op.vybmxfiqsr6mfa@philip-pc>
	<Pine.LNX.4.64.1107082315080.20871@ps20323.dreamhostps.com>
Message-ID: <op.vyb97pqmsr6mfa@philip-pc>

On Sat, 09 Jul 2011 01:19:02 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Sat, 9 Jul 2011, Philip J?genstedt wrote:
>>
>> Step 11 is "If current has an itemprop attribute specified, add it to
>> results." but should be "If current has one or more property names, add
>> it to results." Property names are defined in
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names
>>
>> Why? If you start with <div itemprop="foo">, then
>> div.itemProp.remove("foo") would give you <div itemprop="">. It'd be
>> weird if the element still showed up in the properties collection after
>> removing the only property name.
>
> The .properties attribute "must return an HTMLPropertiesCollection rooted
> at the Document node, whose filter matches only elements that have
> property names", which further filters the results of the algorithm.
> Similarly, everything that uses the algorithm here does things "for each
> property name", so if itemprop="" doesn't have any tokens, nothing  
> happens
> and it doesn't matter that the algorithm returns it.

Ah, I see my misunderstanding.

Purely editorial: It would, IMO, be more clear if that check were in the  
algorithm itself. That's the way it's going to be (has been) implemented  
since there's no reason to do the filtering as a separate step. Do as you  
wish.

-- 
Philip J?genstedt
Core Developer
Opera Software


From ajvincent at gmail.com  Sun Jul 10 01:08:46 2011
From: ajvincent at gmail.com (Alex Vincent)
Date: Sun, 10 Jul 2011 01:08:46 -0700
Subject: [whatwg] <input type="password">... restrict reading value from JS?
Message-ID: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>

This is just an idea.

For the last 10+ years, password inputs have been accessible from scripts,
with nary a complaint.  If I have this code:

  <form action="javascript:void">
    <div>
      <input type="password" id="pw">
      <button onclick="alert(document.getElementById('pw').value)">Show
password!</button>
    </div>
  </form>

I can extract the password by clicking on the button.  More to the point,
with a XHR I can send that password somewhere it shouldn't go... (well, with
cross-domain security code, maybe not, but that's not the point.)

To be honest, I can think of only two good reasons for checking a password
field's value.  The first is to compare against another password field.  The
second is to check the strength of the password.  In both cases, JavaScript
doesn't necessarily need the actual value - if the API provides other ways
to do that.

Specifically, I would suggest two methods for this input type:

/**
 * Check if a password field's value matches another.
 *
 * @param otherPassword Another password element.
 *
 * @throws Error if this.type != "password"
 * @throws Error if other.type != "password"
 *
 * @returns Boolean True if the fields match.
 */
boolean passwordEquals(in HTMLInputElement otherPassword);

/**
 * Check the strength of the password.
 *
 * @param type The type of check to execute.
 *
 * @returns 0 if dangerously low security
 * @returns 1 if "soon-to-be-deprecated" low security
 * @returns 2 if adequate security
 * @returns 3 if good security
 * @returns 4 if strong security
 * @returns 5 if entropy-death-of-the-universe security :-)
 */
unsigned octet passwordStrength(in DOMString type);

The first idea has been suggested before:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000700.html

I don't know if the second idea has been suggested before.
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From dennis at efjot.de  Sun Jul 10 02:25:45 2011
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Sun, 10 Jul 2011 11:25:45 +0200
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <op.vyecg7kf48yz2f@dennis-laptop.speedport-w-303v-typ-a>

Hello Alex,

may I ask: Why? This would only cover a few cases of cross-site-scripting
attacks. It would not make a website more secure.

As to the suggestion, I have one little concern: It should not be possible
to WRITE those SecurePassword values. You only wrote "reading"...

Also it would cripple communications. If you can't read the password, all
Ajax is useless. You would have to submit the password by a http POST.

About the password strength: W3C would have to make a "worldwide standard"
on which passwords are secure and which not. This is not the philosophy
however, leaving just guidelines and not how the actual implementation
should go.

But I also have good sides about this: Online banking would be more secure,
with all javascript failing on it now. A browser could also store the
password in a secure manner and not even keep the original one, like
SHA'ing it a 10.000 times. The server would have the original password
or the same hash or some really mathematically generated hash that can
somehow compare to the hash sent by the user while being different AND not
storing the original password (is this even possible?). But this would also
cut into browser makers how they do their implementation, and thats not  
really
the philosophy here.

I still only see very few things like online banking that doesn't use
Ajax anyway profiting from this.

Am 10.07.2011, 10:08 Uhr, schrieb Alex Vincent <ajvincent at gmail.com>:

> This is just an idea.
>
> For the last 10+ years, password inputs have been accessible from  
> scripts,
> with nary a complaint.  If I have this code:
>
>   <form action="javascript:void">
>     <div>
>       <input type="password" id="pw">
>       <button onclick="alert(document.getElementById('pw').value)">Show
> password!</button>
>     </div>
>   </form>
>
> I can extract the password by clicking on the button.  More to the point,
> with a XHR I can send that password somewhere it shouldn't go... (well,  
> with
> cross-domain security code, maybe not, but that's not the point.)
>
> To be honest, I can think of only two good reasons for checking a  
> password
> field's value.  The first is to compare against another password field.   
> The
> second is to check the strength of the password.  In both cases,  
> JavaScript
> doesn't necessarily need the actual value - if the API provides other  
> ways
> to do that.
>
> Specifically, I would suggest two methods for this input type:
>
> /**
>  * Check if a password field's value matches another.
>  *
>  * @param otherPassword Another password element.
>  *
>  * @throws Error if this.type != "password"
>  * @throws Error if other.type != "password"
>  *
>  * @returns Boolean True if the fields match.
>  */
> boolean passwordEquals(in HTMLInputElement otherPassword);
>
> /**
>  * Check the strength of the password.
>  *
>  * @param type The type of check to execute.
>  *
>  * @returns 0 if dangerously low security
>  * @returns 1 if "soon-to-be-deprecated" low security
>  * @returns 2 if adequate security
>  * @returns 3 if good security
>  * @returns 4 if strong security
>  * @returns 5 if entropy-death-of-the-universe security :-)
>  */
> unsigned octet passwordStrength(in DOMString type);
>
> The first idea has been suggested before:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000700.html
>
> I don't know if the second idea has been suggested before.


From lcamtuf at coredump.cx  Sun Jul 10 03:21:03 2011
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Sun, 10 Jul 2011 03:21:03 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>

> For the last 10+ years, password inputs have been accessible from scripts,
> with nary a complaint. ?If I have this code:

Denying access to password fields from JavaScript is actually a
somewhat interesting security enhancement when you consider the
behavior of password managers. Right now, if you exploit an XSS on
https://www.mybank.com, you can navigate the browser to the login
form, wait for the user name and password field to be autocompleted,
grab the data, and effectively turn your transient access into
long-lived credentials theft.

Unfortunately, the problem is not that easy to fix: denying access to
the field does not prevent the attacker from changing the form
submission URL after autocompletion to achieve the same; or even
simply changing method from POST to GET, setting target=foo, and
leveraging same-origin access to the post-submit page to read back the
password-containing URL.

/mz


From ajvincent at gmail.com  Sun Jul 10 03:44:53 2011
From: ajvincent at gmail.com (Alex Vincent)
Date: Sun, 10 Jul 2011 03:44:53 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
Message-ID: <CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>

On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski <lcamtuf at coredump.cx>wrote:

> > For the last 10+ years, password inputs have been accessible from
> scripts,
> > with nary a complaint.  If I have this code:
>
> Unfortunately, the problem is not that easy to fix: denying access to
> the field does not prevent the attacker from changing the form
> submission URL after autocompletion to achieve the same...


Or even simpler, changing the type attribute to something like "hidden" for
an instant.

I hate it when I don't think things through.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From dennis at efjot.de  Sun Jul 10 07:03:30 2011
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Sun, 10 Jul 2011 16:03:30 +0200
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
Message-ID: <op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>

How about deleting the value if the input type is changed away from the
secure password input type AND that the secure password can only be
submitted to a similar URI.

Am 10.07.2011, 12:44 Uhr, schrieb Alex Vincent <ajvincent at gmail.com>:

> On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski  
> <lcamtuf at coredump.cx>wrote:
>
>> > For the last 10+ years, password inputs have been accessible from
>> scripts,
>> > with nary a complaint.  If I have this code:
>>
>> Unfortunately, the problem is not that easy to fix: denying access to
>> the field does not prevent the attacker from changing the form
>> submission URL after autocompletion to achieve the same...
>
>
> Or even simpler, changing the type attribute to something like "hidden"  
> for
> an instant.
>
> I hate it when I don't think things through.
>


-- 
Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/


From lcamtuf at coredump.cx  Sun Jul 10 12:17:39 2011
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Sun, 10 Jul 2011 12:17:39 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
	<op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>
Message-ID: <CALx_OUCRQYpdTHdVkntYKpqJ8cABFw6v+ESEVvu1tKVzfpNFKw@mail.gmail.com>

> How about deleting the value if the input type is changed away from the
> secure password input type AND that the secure password can only be
> submitted to a similar URI.

Right now, for interoperability, password managers allow a good amount
of fuzziness when matching forms, and I do not believe they pay a lot
of attention to form method, allow the URL and fields to change
slightly, etc. So it's hard to tell an XSS-injected password form from
the real deal.

Instead of a complicated technical solution, some browsers require a
distinctive user gesture before autocompleting login forms. But then,
other vendors believe that this is unacceptable from usability
perspective.

/mz


From dennis at efjot.de  Sun Jul 10 13:11:00 2011
From: dennis at efjot.de (Dennis Joachimsthaler)
Date: Sun, 10 Jul 2011 22:11:00 +0200
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CALx_OUCRQYpdTHdVkntYKpqJ8cABFw6v+ESEVvu1tKVzfpNFKw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
	<op.vyepb4t948yz2f@dennis-laptop.speedport-w-303v-typ-a>
	<CALx_OUCRQYpdTHdVkntYKpqJ8cABFw6v+ESEVvu1tKVzfpNFKw@mail.gmail.com>
Message-ID: <op.vye6cmfc48yz2f@dennis-laptop.speedport-w-303v-typ-a>

Hello,

Opera, for example, requires you to hit the "wand" or "login" button before
it even does any autocompletion.

I wish all browsers would implement it like this instead of just... Filling
it out before the user can interact. Makes reading easy.



Am 10.07.2011, 21:17 Uhr, schrieb Michal Zalewski <lcamtuf at coredump.cx>:

>> How about deleting the value if the input type is changed away from the
>> secure password input type AND that the secure password can only be
>> submitted to a similar URI.
>
> Instead of a complicated technical solution, some browsers require a
> distinctive user gesture before autocompleting login forms. But then,
> other vendors believe that this is unacceptable from usability
> perspective.
>
> /mz


-- 
Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/


From Simetrical+w3c at gmail.com  Sun Jul 10 13:38:30 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sun, 10 Jul 2011 16:38:30 -0400
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>

On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> This is just an idea.
>
> For the last 10+ years, password inputs have been accessible from scripts,
> with nary a complaint. ?If I have this code:
>
> ?<form action="javascript:void">
> ? ?<div>
> ? ? ?<input type="password" id="pw">
> ? ? ?<button onclick="alert(document.getElementById('pw').value)">Show
> password!</button>
> ? ?</div>
> ?</form>
>
> I can extract the password by clicking on the button. ?More to the point,
> with a XHR I can send that password somewhere it shouldn't go... (well, with
> cross-domain security code, maybe not, but that's not the point.)

You can send it anyway by changing the action attribute on the form
and calling submit().  So what attack scenario are you actually
avoiding here?  You'd need a really strong security benefit for it to
be possible to even contemplate breaking so many websites.


From sean at pbwhere.com  Mon Jul 11 06:29:23 2011
From: sean at pbwhere.com (Sean Connelly)
Date: Mon, 11 Jul 2011 09:29:23 -0400
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
Message-ID: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>

As a web developer, if I wanted access to the password, I would then avoid
using the <input type="password"> field, and create my own field that reads
characters (perhaps via onkeyup), and fakes a password field visually.

I also think it's a bad idea to change the behavior of <input
type="password"> because it will break websites that assumed they could read
the value.  Perhaps a website checks against a user's past 10 passwords to
see if they are using the same one, via XHR.  Or perhaps the entire login
process is XHR.  Who knows.

I think there is definite room for improvements in security when it comes to
<input type="password">, and I've also been trying to make it more secure by
designing some sort of client-side hashing.  But I don't think restricting
JavaScript from reading the value is a security benefit... in my opinion, it
would just be a hassle for developers who need to read the value, and force
them to use another means of password entry where they can read the value.

~Sean



On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> > This is just an idea.
> >
> > For the last 10+ years, password inputs have been accessible from
> scripts,
> > with nary a complaint.  If I have this code:
> >
> >  <form action="javascript:void">
> >    <div>
> >      <input type="password" id="pw">
> >      <button onclick="alert(document.getElementById('pw').value)">Show
> > password!</button>
> >    </div>
> >  </form>
> >
> > I can extract the password by clicking on the button.  More to the point,
> > with a XHR I can send that password somewhere it shouldn't go... (well,
> with
> > cross-domain security code, maybe not, but that's not the point.)
>
> You can send it anyway by changing the action attribute on the form
> and calling submit().  So what attack scenario are you actually
> avoiding here?  You'd need a really strong security benefit for it to
> be possible to even contemplate breaking so many websites.
>


From me at tom.id.au  Mon Jul 11 07:17:23 2011
From: me at tom.id.au (Tom O'Connor)
Date: Tue, 12 Jul 2011 00:17:23 +1000
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
	<CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
Message-ID: <4E1B05F3.9000809@tom.id.au>

We would likely end up with some more of these lovely interfaces: 
https://online.westpac.com.au/

Try using that without a mouse and not going insane/grossly disclosing 
your input to anyone paying mild attention to your screen.

Tom

On 11/07/2011 23:29, Sean Connelly wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the<input type="password">  field, and create my own field that reads
> characters (perhaps via onkeyup), and fakes a password field visually.
>
> I also think it's a bad idea to change the behavior of<input
> type="password">  because it will break websites that assumed they could read
> the value.  Perhaps a website checks against a user's past 10 passwords to
> see if they are using the same one, via XHR.  Or perhaps the entire login
> process is XHR.  Who knows.


From svartman95 at gmail.com  Mon Jul 11 09:11:52 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 11 Jul 2011 16:11:52 +0000
Subject: [whatwg] Call for Clarification of the Menu Element Et Al.
In-Reply-To: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
References: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
Message-ID: <4E1B20C8.8080207@gmail.com>

?ann lau  9.j?l 2011 04:29, skrifa?i Hugh Guiney:
> 6.1 On that note, why is the spec enabling the use of unstyled spans
> to achieve alternative rendering? Doesn't this give meaning (however
> contextual) to an element that is supposed to be semantically neutral?
>
Can you think of any other uses for spans? Theoretically you could just 
want to identify text for later reference, but this need is better 
served by divs. If you want to reference a few words, you're probably 
better off quoting them (and citing a greater resource containing those 
words and context).


From svartman95 at gmail.com  Mon Jul 11 10:11:22 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 11 Jul 2011 17:11:22 +0000
Subject: [whatwg] <input type="password">... restrict reading value from
 JS?
In-Reply-To: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
Message-ID: <4E1B2EBA.40809@gmail.com>

?ann sun 10.j?l 2011 08:08, skrifa?i Alex Vincent:
> /**
>   * Check if a password field's value matches another.
>   *
>   * @param otherPassword Another password element.
>   *
>   * @throws Error if this.type != "password"
>   * @throws Error if other.type != "password"
>   *
>   * @returns Boolean True if the fields match.
>   */
> boolean passwordEquals(in HTMLInputElement otherPassword);
>
I believe this to belong to CSS. User agents could either ask or require 
users to input error-prone and important fields twice, without 
submitting the same value twice. This could be the default rendering (in 
some UAs) for strong inputs (i.e. <input> descendants of <strong>). This 
has the potential benefit of allowing media-aware prefixes for locales 
where that makes sense (as in 'Retype Password' vs 'Confirm Password'). 
Note that the confirmation input in 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-required-attribute> 
is optional.

<!DOCTYPE html>
<title>Register a FooBar account</title>
<form action=register method=POST>
<label>Username	<input name=user	required></label>
<strong><input type=password name=pass	required></strong>
</form>

> /**
>   * Check the strength of the password.
>   *
>   * @param type The type of check to execute.
>   *
>   * @returns 0 if dangerously low security
>   * @returns 1 if "soon-to-be-deprecated" low security
>   * @returns 2 if adequate security
>   * @returns 3 if good security
>   * @returns 4 if strong security
>   * @returns 5 if entropy-death-of-the-universe security :-)
>   */
> unsigned octet passwordStrength(in DOMString type);
>
I don't think this is a good idea. Can't user-agents warn about insecure 
passwords without the help of author-supplied scripts?


From svartman95 at gmail.com  Mon Jul 11 10:52:36 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 11 Jul 2011 17:52:36 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
Message-ID: <4E1B3864.9050207@gmail.com>

On 7/8/11, Jeremy Keith <jeremy at adactio.com> wrote:
> Bjartur wrote:
>> Citation will most likely contain the cited resource (@cite), the title
>> of the cited resource (@title) and the date and optionally time of the
>> quote (@datetime?).
>
> All three of which are invisible and so do not match the use cases that Oli
> has outlined.
>
> At least @title has a tooltip but the @cite attribute has proven to be a
> complete disaster, unsupported by user agents and ignored by authors,
I'd like to reemphasize that:
> *unsupported by user agents*
So you're saying that because attributes aren't rendered by default, 
user agents will ignore them and thus we should not use them? Why can't 
we fix UAs? Putting attribution inside <blockquote>s seems like a hack 
around lax support for attributes. That what's CSS is for.


> precisely because it is *hidden* metadata.
> http://www.well.com/~doctorow/metacrap.htm
Yes, people lie. Unless you're arguing that using attribute syntax will 
encourage misquoting, I'll regard this article as interesting, 
correcting and unrelated. The article argues against searching for 
information in uncensored repositories of structured data prone to 
spamming, not typing <footer>asdf</footer> instead of title="asdf".

> So I think that we can learn from the history of the @cite attribute in that
> it shows us how *not* to do it.
>
>> But is it really possible to mark such citations up without presentational
>> elements?
>
> I'm not sure I understand the question. Do you mean "presentational" as in
> "not conveying semantics" or "presentational" as in "visible"?
>
Not conveying semantics. I'm not arguing against rendering attribution. 
On the contrary, IMO user agents should render at least the title of the 
cited resource. Interactive user agents should additionally make the 
cited resource available in manner similar to how they present other 
hyperlinked resources. Additionally user agents with superfluous screen 
space may render the datetime. Handheld renderings should of course not 
display the datetime without user interaction, but reserve the screen 
estate for more critical information, such as the quotation itself.

It's simply a question of
<blockquote>
	Lorem ipsum
<footer>
<a href="kennitala:2112952019" title="Bjartur Thorlacius">Bjartur</a>
on <time datetime="1997-4-2">the second April, 1997</time>
</footer>
</blockquote>
vs
<blockquote title="Bjartur Thorlacius" datetime="1997-4-2" 
cite="kennitala:2112952019">
	Lorem ipsum
</blockquote>


From jackalmage at gmail.com  Mon Jul 11 11:03:35 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Jul 2011 11:03:35 -0700
Subject: [whatwg] Call for Clarification of the Menu Element Et Al.
In-Reply-To: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
References: <CAEHyr+bh9qBoJMozHDd0j2tSZbYba2+21VY==Mm5BtqHLrBUmg@mail.gmail.com>
Message-ID: <CAAWBYDA17hB=R0+rceYSAkY_hitxWnu40uO3zOcd70y-7g65OQ@mail.gmail.com>

On Fri, Jul 8, 2011 at 9:29 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> Hey All,
>
> I was in the process of coding a prototype for a site I'm working on
> when I decided that certain nav's should actually be menu's.
>
> While the basic concept is apparent, unfortunately, with zero browser
> implementation at this time, it is impossible to actually know what my
> markup is doing (or rather, would do).

Really, since there are no browser implementations yet, it's best to
*not* use it yet.  Without any feedback in the form of actually seeing
it work, there's a good chance you'll accidentally get it wrong.  As
well, your early use of it counts as legacy usage if we decide that,
upon attempting to implement it, it needs to be changed.

I'll go ahead and answer the rest of your email as if you were
speaking from a hypothetical position, but take what I said into
account.  Using something pre-implementation doesn't help you, and it
has a chance of hurting the feature in the future.


> So?I looked to the spec for guidance, but ultimately it leaves me very
> confused. These are some points I feel could be addressed, in no
> particular order:
>
>
> 1. How does one know whether to wrap a nested menu in li or leave it
> as a direct child element? Are these semantically-equivalent "coding
> styles" or is there a difference?
>
> 1.1. When marking up a menu specifically with *multiple* menu items,
> is menu/li the only way to do it or would menu/menu also be
> appropriate?
>
> 2. What is the difference between a menu containing command elements
> and a menu containing form controls? Do they merely favor future and
> legacy UAs respectively?

Mostly, yes, though in some cases using form elements lets you define
certain types of commands more easily.  For example, you can use
<select> to define a group of type=radio commands more easily/tersely
than if you used <input type=radio name=foo> or <command type=radio
radiogroup=foo>:


> 3. The spec should provide examples demonstrating when it is better to
> use context vs. toolbar vs. list, as these are very similar in
> concept. I could easily see them being misappropriated.

"context" is meant for right-click menus, hooked to an element by
specifying the @contextmenu attribute on an element and pointing it to
the <menu>.  Note that the default CSS of a <menu type=context> is
display:none.

I don't really understand the difference between "toolbar" and "list".


> 4. In the first example, what renders the button UI? Is it
> menu[@type=toolbar]/li, or li/menu? Or is it implied CSS?

Implied CSS or UA magic.


> 4.1. Furthermore, should this example even depict a button UI, given
> that most graphical interfaces display top-level toolbars as
> text/icons against a [mostly] solid background Were a UA to render the
> example as demonstrated, would designers not have to style away the
> button appearance in order to achieve a look & feel that matches user
> expectation?
>
> Obviously, this would not be the case in "secondary" (or n-ary)
> toolbars, for instance as in word processors, where everything below
> the initial row are usually buttons. Could there be a way, then,
> whether in markup or CSS, to denote whether a toolbar is displayed as
> a "primary"/"top-level" toolbar or not?

This is something that'll be worked out as browsers actually implement things.


> 5. Provide more/graphical/clearer examples, to aid both browser
> vendors in deciding how to implement the elements, and authors in
> having an idea of what result they can expect from using them. The NPC
> form, for instance, does not say exactly what it is or does, nor does
> it represent a common UI convention. The only thing I can think of
> that comes close is Spotlight in OS X (if I'm interpreting it
> correctly), which I don't think I've ever seen in a [presumed] game
> before.

Patches welcome.  ^_^  Any suggested examples?


> 6. How is the command element rendered within a menu context when
> JavaScript is disabled? Is it meant only for non-essential actions? If
> it isn't, shouldn't it be able to be non-empty, so it can fallback to
> links or buttons? Or is the only possible fallback replicating every
> command with form controls that aren't direct children of the parent
> menu?

If you're designing something to be a context menu, it likely won't
work at all without Javascript.  You'd need a significantly different
UI.


> 6.1 On that note, why is the spec enabling the use of unstyled spans
> to achieve alternative rendering? Doesn't this give meaning (however
> contextual) to an element that is supposed to be semantically neutral?

Slightly.  I don't think it's a big deal, but shrug.  Note that *any*
element would work there to hide the submit button from the "build a
menu" algorithm.


> 7. Is the menu element always to be rendered in-page or could it be
> displayed within the OS itself? Kroc Camen
> (suggests)[http://camendesign.com/blog/stop_this_madness] the latter
> but at present there is nothing in the spec about such an
> implementation. If this is left up to the UA how will developers know
> how/if to style it without using browser detection?

This is another thing that'll be worked out as browsers implement.

~TJ


From jackalmage at gmail.com  Mon Jul 11 11:12:07 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Jul 2011 11:12:07 -0700
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CALx_OUBY+kyR6HeRfDuoYD6tTc=zNRebt9A=VQiK=iV-yHHkjg@mail.gmail.com>
	<CAEZ8441quqLJ1X=f=eK77cjJvyeKauW9151HJ7a7bxKq=35WOg@mail.gmail.com>
Message-ID: <CAAWBYDDmjM62getBqSRFvt9FzBL9ZtaZ96cVwZDu_wLupoiJEA@mail.gmail.com>

On Sun, Jul 10, 2011 at 3:44 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski <lcamtuf at coredump.cx>wrote:
>> > For the last 10+ years, password inputs have been accessible from
>> scripts,
>> > with nary a complaint. ?If I have this code:
>>
>> Unfortunately, the problem is not that easy to fix: denying access to
>> the field does not prevent the attacker from changing the form
>> submission URL after autocompletion to achieve the same...
>
>
> Or even simpler, changing the type attribute to something like "hidden" for
> an instant.
>
> I hate it when I don't think things through.

To be fair, we already protect <input type=file> from vaguely similar
type-changing attacks.  (You can't make an <input type=text>, fill it
with a filename as the value, then switch to type=file and submit it
to steal files from the user.)

However, as noted, doing this wouldn't help in any way.  The script
can redirect the form submission, or just swap out the input entirely
for an <input type=text> that they manually intercept clicks on and
insert * for each keypress (or more deviously, set the font-family for
the text input to a font where every glyph is an asterisk, and then
just read out the value normally).

~TJ


From Simetrical+w3c at gmail.com  Mon Jul 11 11:31:57 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 11 Jul 2011 14:31:57 -0400
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
	<CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
Message-ID: <CAKA+AxntHAU7YNzeGEDxCOzGGbfmZn4xjFfCfwMui6=n1VYY4Q@mail.gmail.com>

On Mon, Jul 11, 2011 at 9:29 AM, Sean Connelly <sean at pbwhere.com> wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the <input type="password"> field, and create my own field that reads
> characters (perhaps via onkeyup), and fakes a password field visually.

Then browsers wouldn't autofill it, which would defeat the nastiest
attack here (stealing passwords without user intervention).  But as
noted, you can always submit the form, so it really doesn't help that
much anyway.


From acolwell at google.com  Mon Jul 11 11:42:59 2011
From: acolwell at google.com (Aaron Colwell)
Date: Mon, 11 Jul 2011 11:42:59 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending media
	data to a HTMLMediaElement
Message-ID: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>

Hi,

Based on comments in the File API Streaming
Blobs<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029973.html>
thread and
my Extending HTML 5 video for adaptive
streaming<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032277.html>
thread,
I decided on taking a stab at writing a MediaSource API
spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>
for
streaming data to a media tag.

Please take a look at the
spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>and
provide some feedback.

I've tried to start with the simplest thing that would work and hope to
expand from there if need be. For now, I'm intentionally not trying to solve
the generic streaming file case because I believe there might be media
specific requirements around handling seeking especially if we intend to
support non-packetized media streams like WAV.

If the feedback is generally positive on this approach, I'll start working
on patches for WebKit & Chrome so people can experiment with an actual
implementation.

Thanks,
Aaron


From crogers at google.com  Mon Jul 11 12:23:33 2011
From: crogers at google.com (Chris Rogers)
Date: Mon, 11 Jul 2011 12:23:33 -0700
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
Message-ID: <CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>

On Fri, Jul 8, 2011 at 4:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> , On Fri, Jul 8, 2011 at 2:54 PM, James Robinson <jamesr at google.com>
> wrote:
>
> > On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org
> >wrote:
> >
> >>
> >> Using this value as a clock for media synchronization sounds appealing
> but
> >> is complicated by audio clock drift. When you play N seconds of audio,
> it
> >> might take slightly more or less time to actually play, so it's hard to
> keep
> >> media times perfectly in sync with another timing source. Just something
> to
> >> keep in mind.
> >>
> >
> > True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified
> to
> > use a unified time base (see
> >
> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html
> )
> > so if we do end up with APIs saying "play this sound at time X", like
> Chris
> > Roger's proposed Web Audio API provides, it'll be really handy if we have
> a
> > unified timescale for everyone to refer to.
> >
>
> Is that unified time base in sync with the system clock, and how accurate
> is
> it? I'm concerned about the possibility that it's not feasible to keep the
> audio hardware clock in sync with the system clock, at least on some
> platforms. In that case, we probably need to keep media playback and
> animations in sync with the audio hardware clock, and we could even expose
> that via some DOM API, but you might not want to use the same clock for
> other purposes, such general performance timing for example ... I've heard
> the audio clock drift is often significant.
>
> I'm not sure if this is a real problem or not, I just want to make sure.
>
> Rob
>

Hi Robert, I think the clock that James is proposing is effectively the
system clock (such as mach_absolute_time() or QueryPerformanceCounter()).  I
completely agree with your concerns about clock drift of this type of clock
with the audio hardware clock, since they're almost always running off
different crystals.  That said, I still think it's useful to have a
high-resolution system clock which is monotonically increasing.  On Mac OS X
the mach_absolute_time() system clock is used extensively in the media APIs,
CoreVideo, CoreAudio, CoreMIDI, etc. to synchronize events according to a
common time base:

CoreAudio:
http://developer.apple.com/library/mac/#documentation/MusicAudio/Reference/CoreAudioDataTypesRef/Reference/reference.html#//apple_ref/c/tdef/AudioTimeStamp

CoreVideo:
http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html

CoreMIDI ( see MIDITimeStamp: A host clock time ----  typedef UInt64
MIDITimeStamp; )
http://developer.apple.com/library/ios/#documentation/CoreMidi/Reference/MIDIServices_Reference/Reference/reference.html#//apple_ref/doc/uid/TP40010316

mach_absolute_time():
http://developer.apple.com/library/mac/#qa/qa1398/_index.html

In the CoreAudio case, the AudioTimeStamp contains *both* the host-time
(system clock) and the sample time (based on audio hardware).  This creates
a relationship between the two clocks.  As an example of how these two
clocks can be used together for synchronization, audio applications use the
high-resolution timestamp of incoming MIDI messages to schedule audio
synthesis to happen with very low jitter by doing sample-accurate scheduling
when rendering the audio stream.

Because of clock-drift, the system clock that James is proposing cannot
*directly* be the same clock as what I'm proposing in the Web Audio API
AudioContext .currentTime attribute.  But there are ways to translate
between the two in very useful ways.

I would be in favor of introducing a monotonically increasing
high-resolution system clock such as James is proposing, as long as we keep
in mind some of these subtleties.

Chris


From robert at ocallahan.org  Mon Jul 11 17:54:44 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 12 Jul 2011 12:54:44 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
Message-ID: <CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>

It seems to me that the spec is written assuming only one media element is
consuming the MediaSource. But nothing stops multiple elements consuming the
same URL simultaneously. Maybe instead of going through a URL you should add
API directly to media elements.

bytesAvailable is for flow control? Instead of doing it this way, I would
follow WebSockets and use a bufferedAmount attribute to indicate how much
data is currently buffered up. That makes it easy for authors who don't want
to care about flow control to just append stuff without encountering errors,
while still allowing authors who care about flow control to do it.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From robert at ocallahan.org  Mon Jul 11 17:57:56 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 12 Jul 2011 12:57:56 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
Message-ID: <CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>

On Tue, Jul 12, 2011 at 7:23 AM, Chris Rogers <crogers at google.com> wrote:

> In the CoreAudio case, the AudioTimeStamp contains *both* the host-time
> (system clock) and the sample time (based on audio hardware).  This creates
> a relationship between the two clocks.  As an example of how these two
> clocks can be used together for synchronization, audio applications use the
> high-resolution timestamp of incoming MIDI messages to schedule audio
> synthesis to happen with very low jitter by doing sample-accurate scheduling
> when rendering the audio stream.
>
> Because of clock-drift, the system clock that James is proposing cannot
> *directly* be the same clock as what I'm proposing in the Web Audio API
> AudioContext .currentTime attribute.  But there are ways to translate
> between the two in very useful ways.
>

Thanks Chris, I thought you'd know the answer :-).

Suppose we wanted to sync animation (either scripted animation or CSS
animation) to audio. We'd want them to use the audio clock, right?

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From glenn at zewt.org  Mon Jul 11 18:02:50 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 11 Jul 2011 21:02:50 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
	<CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
Message-ID: <CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>

On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> Suppose we wanted to sync animation (either scripted animation or CSS
> animation) to audio. We'd want them to use the audio clock, right?
>

For that you need the play cursor of the actual audio sample you're
synchronizing against, which is typically not strongly tied to the
associated hardware audio clock.  For example, audio underruns may change
their alignment.

-- 
Glenn Maynard


From anant at mozilla.com  Mon Jul 11 19:01:03 2011
From: anant at mozilla.com (Anant Narayanan)
Date: Mon, 11 Jul 2011 19:01:03 -0700
Subject: [whatwg] RTC API Proposal
Message-ID: <4E1BAADF.2080101@mozilla.com>

Hi,

Mozilla and Cisco have been working on an API for real time 
communication, which we sent out today to the W3C WebRTC working group 
(http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html). 
It builds on both the WHATWG RTC proposal by Ian Hickson as well as the 
MediaStream Processing API by Robert O'Callahan.

There are few differences though, and they are presented at:
http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0012.html

The proposal itself lives at:
https://github.com/mozilla/rainbow/wiki/RTC_API_Proposal

There is some discussion going on about the proposal on the W3C list but 
we would love to hear your feedback.

Thanks,
-Anant


From robert at ocallahan.org  Mon Jul 11 19:35:28 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 12 Jul 2011 14:35:28 +1200
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
	<CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
	<CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>
Message-ID: <CAOp6jLYaxrtZRiAJ_e3vCJu8ej521qNqoie4XgCpdavm-xGNJg@mail.gmail.com>

On Tue, Jul 12, 2011 at 1:02 PM, Glenn Maynard <glenn at zewt.org> wrote:

> On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> Suppose we wanted to sync animation (either scripted animation or CSS
>> animation) to audio. We'd want them to use the audio clock, right?
>>
>
> For that you need the play cursor of the actual audio sample you're
> synchronizing against, which is typically not strongly tied to the
> associated hardware audio clock.  For example, audio underruns may change
> their alignment.
>

OK, but it's the audio clock with some adjustments, right? Definitely not
the system clock.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From glenn at zewt.org  Mon Jul 11 19:41:47 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 11 Jul 2011 22:41:47 -0400
Subject: [whatwg] Timing API proposal for measuring intervals
In-Reply-To: <CAOp6jLYaxrtZRiAJ_e3vCJu8ej521qNqoie4XgCpdavm-xGNJg@mail.gmail.com>
References: <CAD73mdL9fR1TSNLA4oPmnNFe9NnUm+pdvaciL7mNriRadd8Lzw@mail.gmail.com>
	<CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
	<CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
	<CAOp6jLZD2vZ11pauDbRj4M2GKMsYbDxZNFrsuHx6TeATc7GxEQ@mail.gmail.com>
	<CA+EzO0kc5rrdBzwoiHsnZKt_DUvkkH2iiy+ZioYij7+Wi7YUpw@mail.gmail.com>
	<CAOp6jLbzS6wguQehNnREyitDgrU=_29-sTpshDLah0TXtG3bMg@mail.gmail.com>
	<CABirCh_waTXFR4z+b0noO42AP4XVMUfjW9j-o-57_PEA_L5KUg@mail.gmail.com>
	<CAOp6jLYaxrtZRiAJ_e3vCJu8ej521qNqoie4XgCpdavm-xGNJg@mail.gmail.com>
Message-ID: <CABirCh-Gc8UMPnN6+Xhi1d2M77BmqXCKSWSd43i0-Q5YAHPk+g@mail.gmail.com>

On Mon, Jul 11, 2011 at 10:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Jul 12, 2011 at 1:02 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> Suppose we wanted to sync animation (either scripted animation or CSS
>>> animation) to audio. We'd want them to use the audio clock, right?
>>>
>>
>> For that you need the play cursor of the actual audio sample you're
>> synchronizing against, which is typically not strongly tied to the
>> associated hardware audio clock.  For example, audio underruns may change
>> their alignment.
>>
>
> OK, but it's the audio clock with some adjustments, right? Definitely not
> the system clock.
>

Right.

-- 
Glenn Maynard


From jonas at sicking.cc  Mon Jul 11 20:14:09 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 11 Jul 2011 20:14:09 -0700
Subject: [whatwg] RTC API Proposal
In-Reply-To: <4E1BAADF.2080101@mozilla.com>
References: <4E1BAADF.2080101@mozilla.com>
Message-ID: <CA+c2ei8wO6xgHRnhQ3MqfZESo-g71QSsAmeLKjyRL6ZNvqSomQ@mail.gmail.com>

On Mon, Jul 11, 2011 at 7:01 PM, Anant Narayanan <anant at mozilla.com> wrote:
> Hi,
>
> Mozilla and Cisco have been working on an API for real time communication,
> which we sent out today to the W3C WebRTC working group
> (http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html). It
> builds on both the WHATWG RTC proposal by Ian Hickson as well as the
> MediaStream Processing API by Robert O'Callahan.
>
> There are few differences though, and they are presented at:
> http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0012.html
>
> The proposal itself lives at:
> https://github.com/mozilla/rainbow/wiki/RTC_API_Proposal
>
> There is some discussion going on about the proposal on the W3C list but we
> would love to hear your feedback.

Some minor nits:

> constructor PeerListener(DOMString config, optional DOMString negotiationServerURN)
> interface PeerListener {
>     void listen();
>     attribute Function onIncoming;
> };
> Window implements PeerListener;

The WebIDL syntax here is a bit wrong, I suspect you're looking for
something like:

[Constructor(in DOMString config, in optional DOMString negotiationServerURN)]
interface PeerListener {
    void listen();
    attribute Function onIncoming;
};
Window implements PeerListener;

You probably don't mean the last "implements" line. That line
currently says that Windows *are* PerrListeners. I.e. that you can do
window.listen() and window.onIncoming = function() { ... }, which is
likely not what you want. Simply remove the line as declaring the
constructor should be enough.

To keep consistent with all other onfoo listeners, you should use all
lowercase name: onincoming.

It seems like you are saying that the function assigned to onincoming
receives a Connection object as its first argument. However generally
onfoo attributes are EventListeners and so always receives an Event
object as its first and only argument. If your intent is to be
consistent with other onfoo attributes you should instead create a
PeerListenerEvent object which inherits Event and makes the Connection
available as a property on it. You should also make PeerListener an
EventTarget.

In the example where you create a PeerListener, it appears that you're
only passing the second negotiationServerURN argument
("stun:foobar.net:3476"). But the constructor above says that the
first argument is a "config" string, and that it's not optional. I'm
in particular curious what the syntax for the config string is, and if
it would be better done as a Dictionary. Would love to see some
examples.

In the example you also create a PeerConnection object using |new
PeerConnection("stun:foobar.net:3476", sendToB);|. However the
interface declaration for PeerListener does not include a constructor.
I'm trying to figure out how the sendToB and gotFromB functions work
in the "Simple Video Call" example, but it the lack of description for
the PeerListener constructor is preventing that. It also seems like
the gotFromB is unused which I assume is a bug in the example.

/ Jonas


From harald at alvestrand.no  Tue Jul 12 00:31:48 2011
From: harald at alvestrand.no (Harald Alvestrand)
Date: Tue, 12 Jul 2011 09:31:48 +0200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
Message-ID: <4E1BF864.5000904@alvestrand.no>

Not a comment directly on the spec, but you might want to check what 
people are suggesting for interactive media handling in the WEBRTC 
working group.

Streaming is different from interactive media, but it would be a shame 
to have incompatibilities that can be avoided.

On 07/11/11 20:42, Aaron Colwell wrote:
> Hi,
>
> Based on comments in the File API Streaming
> Blobs<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029973.html>
> thread and
> my Extending HTML 5 video for adaptive
> streaming<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032277.html>
> thread,
> I decided on taking a stab at writing a MediaSource API
> spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>
> for
> streaming data to a media tag.
>
> Please take a look at the
> spec<http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>and
> provide some feedback.
>
> I've tried to start with the simplest thing that would work and hope to
> expand from there if need be. For now, I'm intentionally not trying to solve
> the generic streaming file case because I believe there might be media
> specific requirements around handling seeking especially if we intend to
> support non-packetized media streams like WAV.
>
> If the feedback is generally positive on this approach, I'll start working
> on patches for WebKit&  Chrome so people can experiment with an actual
> implementation.
>
> Thanks,
> Aaron
>



From jeremy at adactio.com  Mon Jul 11 16:24:26 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Tue, 12 Jul 2011 00:24:26 +0100
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1B3864.9050207@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
	<4E1B3864.9050207@gmail.com>
Message-ID: <A6490491-963A-4B42-ABAD-3FA37D5DC9FE@adactio.com>

Bjartur wrote:
> I'd like to reemphasize that:
>> *unsupported by user agents*
> So you're saying that because attributes aren't rendered by default, user agents will ignore them and thus we should not use them?

It's not a matter of "should not." Because user agents ignore them, we *do not* use them. And the main reason why we don't use them is that there's little to be gained: the information isn't presented to the end user.

Wishful thinking isn't going to make the @cite attribute any more useful or more widely adopted (either by authors or user agents).

> Putting attribution inside <blockquote>s seems like a hack around lax support for attributes.

No, putting attribution inside <blockquote>s solves the real-world use-cases that Oli has gathered together.

>> I'm not sure I understand the question. Do you mean "presentational" as in
>> "not conveying semantics" or "presentational" as in "visible"?
>> 
> Not conveying semantics.

How can you say that the <footer> element would not convey semantics, when it is defined as follows:

"The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like."
?http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-footer-element

...and the <blockquote> element is a sectioning root. The semantics of those two elements match up perfectly.

> Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources

Can you please give an example of user agents presenting *invisible* hyperlinked resources? @longdesc, perhaps?

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/




From hsivonen at iki.fi  Tue Jul 12 00:41:18 2011
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 12 Jul 2011 09:41:18 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
Message-ID: <1310456478.2308.7.camel@shuttle>

On Thu, 2011-07-07 at 22:33 +0000, Ian Hickson wrote:
> The JSON algorithm now ends the crawl when it hits a loop, and replaces 
> the offending duplicate item with the string "ERROR".
> 
> The RDF algorithm preserves the loops, since doing so is possible with 
> RDF. Turns out the algorithm almost did this already, looks like it was an 
> oversight.

It seems to me that this approach creates an incentive for people who
want to do RDFesque things to publish deliberately non-conforming
microdata content that works the way they want for RDF-based consumers
but breaks for non-RDF consumers. If such content abounds and non-RDF
consumers are forced to support loopiness but extending the JSON
conversion algorithm in ad hoc ways, part of the benefit of microdata
over RDFa (treeness) is destroyed and the benefit of being well-defined
would be destroyed, too, for non-RDF consumption cases.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From whatwg.org at boblet.net  Tue Jul 12 02:15:02 2011
From: whatwg.org at boblet.net (Oli Studholme)
Date: Tue, 12 Jul 2011 18:15:02 +0900
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1B3864.9050207@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<4E16EF63.8080709@gmail.com>
	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
	<4E1B3864.9050207@gmail.com>
Message-ID: <CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>

Hi Bjartur,

Firstly thank you (and you Jeremy!) for your input. This thread will
help decide how the blockquote spec changes to accommodate the use
cases I outlined, so the more input the better.

On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> I'm not arguing against rendering attribution. On
> the contrary, IMO user agents should render at least the title of the cited
> resource.

This is a can of worms as authors will want control over both content
and style. Attributes turned into content are harder to style than
content. Also attributes tend to be for either humans (@alt) or
machines (@datetime), so displaying attributes (for humans) that
contain data (for machines) generally gives bad results.

> Interactive user agents should additionally make the cited
> resource available in manner similar to how they present other hyperlinked
> resources.

In the print use cases I found, sometimes attribution is inline after
the last sentence and sometimes on a following line. This is in
addition to having attribution in the prose surrounding the block
quote, as currently recommended by the spec. How would the user agent
know which way the author wants to present attribution?

> Additionally user agents with superfluous screen space may render
> the datetime. Handheld renderings should of course not display the datetime
> without user interaction, but reserve the screen estate for more critical
> information, such as the quotation itself.

Again I have no idea how a user agent would follow these rules.
Arbitrarily showing one thing in one viewport size and something else
at a different size would be a bug (arbitrarily meaning without
author/user intervention, such as via CSS). Love your phrase
?superfluous screen space? btw ;)

> It's simply a question of
> <blockquote>
> ? ? ? ?Lorem ipsum
> <footer>
> <a href="kennitala:2112952019" title="Bjartur Thorlacius">Bjartur</a>
> on <time datetime="1997-4-2">the second April, 1997</time>
> </footer>
> </blockquote>
> vs
> <blockquote title="Bjartur Thorlacius" datetime="1997-4-2"
> cite="kennitala:2112952019">
> ? ? ? ?Lorem ipsum
> </blockquote>

You've got two additional problems in your example:
* currently only the <time>, <ins> and <del> elements accept the
datetime attribute, and this isn't even a valid datetime value (you
wanted 1997-04-02)
* the cite attribute must be a valid URL, and is for providing a link
to more information about the quote (generally its source) ? you can't
use it for non-URL data
This proves Jeremy's earlier point about attributes being a bad place
to store data. Unless you look at the source you?d never notice these
mistakes.

I also note that your <footer> example contains a lot more content,
the visible part being ?Bjartur on the second April, 1997?. A
potential rendering of the attributes in your second example would
probably be something like ?Bjartur Thorlacius 1997-04-02", which I
think isn?t as good. This refers to my first point about authors
wanting to control the content.

Finally two other strikes against attributes are they're harder for
people learning HTML (which is one reason we have <section> over
role="section" etc), and we already have three (I?d argue) perfectly
good elements for the data you are suggesting adding via attributes:
* <footer> for following-line attribution and notes
* <time> for datetime information
* <a> and <cite> for citation information

There?s also the possibility of adding another inline element, such as
<credit>, which could let someone credit an author of a quote, or e.g.
to credit a photographer of an image together <figure> and
<figcaption>.

For the reasons Jeremy mentioned, I actually hope the cite attribute
gets dropped in favour of a visible, explicit form of attribution.
While something like <a> and <cite> in a <footer> could work for
citation, I still don?t have a good idea about citing explicitly when
the citation is inline (on the last line of the block quote), or for
<q>.

HTH

peace - oli studholme


From svartman95 at gmail.com  Tue Jul 12 04:28:59 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 12 Jul 2011 11:28:59 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>	<4E1B3864.9050207@gmail.com>
	<CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>
Message-ID: <4E1C2FFB.5060909@gmail.com>

?ann ?ri 12.j?l 2011 09:15, skrifa?i Oli Studholme:
> Firstly thank you (and you Jeremy!) for your input. This thread will
> help decide how the blockquote spec changes to accommodate the use
> cases I outlined, so the more input the better.
>
Thank you for your commentary, it is most appreciated.

> On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius
> <svartman95 at gmail.com>  wrote:
>> I'm not arguing against rendering attribution. On
>> the contrary, IMO user agents should render at least the title of the cited
>> resource.
>
> This is a can of worms as authors will want control over both content
> and style. Attributes turned into content are harder to style than
> content. Also attributes tend to be for either humans (@alt) or
> machines (@datetime), so displaying attributes (for humans) that
> contain data (for machines) generally gives bad results.
>
Datetimes will usually be presented in a localized format to humans.

> In the print use cases I found, sometimes attribution is inline after
> the last sentence and sometimes on a following line. This is in
> addition to having attribution in the prose surrounding the block
> quote, as currently recommended by the spec. How would the user agent
> know which way the author wants to present attribution?
>
By fetching and reading a linked stylesheet. I think it's easier to 
style attributes then text nodes polluted with delimiters such as "from" 
and "by" that make reordering hard.
More importantly, how is the author to know how the user wants 
attribution presented?

> Again I have no idea how a user agent would follow these rules.
> Arbitrarily showing one thing in one viewport size and something else
> at a different size would be a bug (arbitrarily meaning without
> author/user intervention, such as via CSS).
A feature to one, a bug to another. The existence of the CSS height and 
width media features suggests that catering style to varying viewport 
sizes is desired by others than just me. I don't see why a user agent 
should seek an authors' permission to style a document for an unusually 
sized viewport, nor require users to write their own stylesheets instead 
of shipping customizable stylesheets.

> Love your phrase
> ?superfluous screen space? btw ;)
:P

>> It's simply a question of
>> <blockquote>
>>         Lorem ipsum
>> <footer>
>> <a href="kennitala:2112952019" title="Bjartur Thorlacius">Bjartur</a>
>> on<time datetime="1997-4-2">the second April, 1997</time>
>> </footer>
>> </blockquote>
>> vs
>> <blockquote title="Bjartur Thorlacius" datetime="1997-4-2"
>> cite="kennitala:2112952019">
>>         Lorem ipsum
>> </blockquote>
>
> You've got two additional problems in your example:
> * currently only the<time>,<ins>  and<del>  elements accept the
> datetime attribute, and this isn't even a valid datetime value (you
> wanted 1997-04-02)
Ops, you're correct; this should've been 1997-04-02. I'm proposing 
adding a datetime attribute to <blockquote>.

> * the cite attribute must be a valid URL, and is for providing a link
> to more information about the quote (generally its source) ? you can't
> use it for non-URL data
For a lack of a valid URI identifying myself, I used an unregistered 
uri-scheme ("kennitala") and my national ID as the scheme-specific part. 
The exact URI in question is unimportant to the example, but I see no 
reason to restrict values of cite to locators only, as opposed to 
identifiers in general. Quoting books identified by ISBN numbers seems 
like a good enough use case to me.

> This proves Jeremy's earlier point about attributes being a bad place
> to store data. Unless you look at the source you?d never notice these
> mistakes.
>
Sure I would, had I actually tried to, say, render them or validate 
before posting them on the Internet. I refrained from doing so as I knew 
this to be invalid markup, anyway. Where datetime to be a valid 
attribute of blockquote

> I also note that your<footer>  example contains a lot more content,
> the visible part being ?Bjartur on the second April, 1997?. A
> potential rendering of the attributes in your second example would
> probably be something like ?Bjartur Thorlacius 1997-04-02", which I
> think isn?t as good. This refers to my first point about authors
> wanting to control the content.
>
No, that would be quite an odd rendering. More likely renderings:

?ann annan apr?l 1997 skrifa?i Bjartur Thorlacius:
 > Lorem ipsum


On the second April, 1997 Bjartur Thorlacius wrote:
 > Lorem ipsum

? Lorem ipsum
	? Bjartur Thorlacius

It all depends on the user's localized stylesheet.

Note that a datetime in a <time> element would have to parsed just as 
date in a datetime attribute of a <blockquote>. They're both machine 
readable (and that's the best way to internationalize dates).
> Finally two other strikes against attributes are they're harder for
> people learning HTML (which is one reason we have<section>  over
> role="section" etc), and we already have three (I?d argue) perfectly
> good elements for the data you are suggesting adding via attributes:
> *<footer>  for following-line attribution and notes
> *<time>  for datetime information
> *<a>  and<cite>  for citation information
>
I've never heard this argument before. I thought we had <section> rather 
than <div role=section> because the latter has a high 
noise-to-information ratio, leading to overly verbose constructs such as:

<div role=section>
[content]
</div> <!-- end section -->

> There?s also the possibility of adding another inline element, such as
> <credit>, which could let someone credit an author of a quote, or e.g.
> to credit a photographer of an image together<figure>  and
> <figcaption>.
>
So <credit> would be an inline version of <footer>, to be contained in 
<q>? Would it not be more consistent to use attributes, in that case? 
Note that <figcaption> may contain <footer>s.

> For the reasons Jeremy mentioned, I actually hope the cite attribute
> gets dropped in favour of a visible, explicit form of attribution.
> While something like<a>  and<cite>  in a<footer>  could work for
> citation, I still don?t have a good idea about citing explicitly when
> the citation is inline (on the last line of the block quote), or for
> <q>.
>
I do: use the same attributes as for <blockquote>.
Referencing people as works as I did in my examples is probably
bad (read: terrible) style. There should be a sepearate @author 
attribute for attributing an author, distinct from the @cite attribute 
for citing the work.

On a third thought, using a <footer> child of <blockquote> doesn't seem 
so confusing after all, but it'd be even less confusing to HTML 
newcomers were it named e.g. <credit>. But then it would not be an 
appropriate element for "fat footers", whatever they are. I don't see 
what citations and "fat footers" have in common.
The semantics of <footer> would be a lot clearer if "fat footers" were 
not to be enclosed in <footer>, but rather in <nav>s or <aside>s.

Were the "fat footers" example in the spec as follows, I'd have fewer 
objections.

...
  <nav>
   <section>
    <h1>Articles</h1>
    <p><img src="images/somersaults.jpeg" alt=""> Go to the gym with
    our somersaults class! Our teacher Jim takes you through the paces
    in this two-part article. <a href="articles/somersaults/1">Part
    1</a> ? <a href="articles/somersaults/1">Part 2</a></p>
    <a href="articles/kindplus/1"><p><img src="images/kindplus.jpeg"> 	
    Tired of walking on the edge of
    a clif<!-- sic -->? Our guest writer Lara shows you how to bumble
    your way through the bars.</p></a>
    <a href="articles/crisps/1"><p><img src="images/crisps.jpeg">
    The chips are down, now all that's left is a potato. What can you
    do with it?</p></a>
   </section>
   <ul>
    <li> <a href="/about">About us...</a>
    <li> <a href="/feedback">Send feedback!</a>
    <li> <a href="/sitemap">Sitemap</a>
   </ul>
  </nav>
  <footer>
   <p><small>Copyright ? 2015 The Snacker ?
   <a href="/tos">Terms of Service</a></small></p>
  </footer>
</body>


From philipj at opera.com  Tue Jul 12 07:17:17 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Tue, 12 Jul 2011 16:17:17 +0200
Subject: [whatwg] Microdata feedback
In-Reply-To: <1310456478.2308.7.camel@shuttle>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<1310456478.2308.7.camel@shuttle>
Message-ID: <op.vyifa3fnsr6mfa@kirk>

On Tue, 12 Jul 2011 09:41:18 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Thu, 2011-07-07 at 22:33 +0000, Ian Hickson wrote:
>> The JSON algorithm now ends the crawl when it hits a loop, and replaces
>> the offending duplicate item with the string "ERROR".
>>
>> The RDF algorithm preserves the loops, since doing so is possible with
>> RDF. Turns out the algorithm almost did this already, looks like it was  
>> an
>> oversight.
>
> It seems to me that this approach creates an incentive for people who
> want to do RDFesque things to publish deliberately non-conforming
> microdata content that works the way they want for RDF-based consumers
> but breaks for non-RDF consumers. If such content abounds and non-RDF
> consumers are forced to support loopiness but extending the JSON
> conversion algorithm in ad hoc ways, part of the benefit of microdata
> over RDFa (treeness) is destroyed and the benefit of being well-defined
> would be destroyed, too, for non-RDF consumption cases.

I don't have a strong opinion, but note that even before this change the  
algorithm produced a non-tree for the "Avenue Q" example [1] where the  
"adr" property is shared between two items using itemref. (In JSON, it is  
flattened.) If we want to ensure that RDF consumers don't depend on  
non-treeness, then this should change as well.

[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#examples-4

-- 
Philip J?genstedt
Core Developer
Opera Software


From bzbarsky at MIT.EDU  Tue Jul 12 08:38:22 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 12 Jul 2011 11:38:22 -0400
Subject: [whatwg] Should events be paused on detached iframes?
In-Reply-To: <Pine.LNX.4.64.1106132358030.19153@ps20323.dreamhostps.com>
References: <4C742BCB.1020006@cs.washington.edu>	<AANLkTimprzp=A3nyEEmV4=nQnHZdZPanA0nDyPYOJxfw@mail.gmail.com>	<4C77907E.50609@helsinki.fi>	<Pine.LNX.4.64.1012012104380.26618@ps20323.dreamhostps.com>	<4CFD8529.6000200@mit.edu>	<Pine.LNX.4.64.1103050005090.26730@ps20323.dreamhostps.com>	<4D71968F.4080104@mit.edu>
	<Pine.LNX.4.64.1106132358030.19153@ps20323.dreamhostps.com>
Message-ID: <4E1C6A6E.2050303@mit.edu>

On 6/13/11 8:09 PM, Ian Hickson wrote:
>> It's possible to switch these relevant checks to walk the ownerDocument
>> chain instead, say.  Then we need to audit all the callsites to make
>> sure this makes sense at them and figure out what to do for the ones
>> where it doesn't.  (For example, should window.alert on the window of an
>> iframe not in the DOM put up a dialog in a tab based on the
>> ownerDocument of the iframe?  Or not put one up at all?)
>
> It should put it up in the context of the top-level browsing context of
> the script that led to that point (the "first script"). This is the same
> as if someone in one tab calls another tab's script and that script calls
> alert().

Is that last what browsers actually do?  I'm pretty sure that's not what 
Gecko does...

> Note that only direct script invokations would work here. setTimeout,
> events, XHR callbacks, etc, don't run while the document is not active. (I
> had previously set that dispatchEvent() would work, but this is incorrect
> per the spec at the moment. My apologies.)

OK.

>> There are quite a few APIs that need to be thus audited if this
>> invariant is changed.
>
> Are there any I should look for off-hand?

You listed some above.

There are also issues in terms of network loads that are live when an 
iframe is removed from its document, whether network loads can _start_ 
in such a removed iframe, what the styling behavior, if any, is (e.g. 
how should media query matching work?), layout behavior, if any (what's 
the initial containing block size?).  What should happen if click() is 
called on anchors?  Or is that covered by the events thing above?

Basically, pretty much every single aspect of the platform's behavior 
needs to be sanity-checked in this context...

>> There are, yes.  There are also lots of edge cases that are otherwise
>> impossible that are introduced by allowing it; I'm a little curious as
>> to how compatible with each other the IE8 and Chrome implementations
>> are.
>
> I agree that this is an area that might well be minimally interoperable at
> the moment. That, of course, is the main reason to specify it. :-)

That's fine, but it seems like a v2 kind of feature to me.

I'm also a little saddened that there has been absolutely no feedback so 
far from the people who've been implementing this, even in cases when 
the current spec doesn't really cover behavior....  We're not going to 
get to interop that way.

-Boris



From ian at hixie.ch  Tue Jul 12 11:54:23 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Jul 2011 18:54:23 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <1310456478.2308.7.camel@shuttle>
References: <BANLkTin8tkq9AFu47oyvD=FDc27T2TGKog@mail.gmail.com>
	<BANLkTimJkK=uS2rbTQaWHZ3rtnX0j_25X7qhO9jr_jp3PmcwEQ@mail.gmail.com>
	<Pine.LNX.4.64.1107061815270.19153@ps20323.dreamhostps.com>
	<1310456478.2308.7.camel@shuttle>
Message-ID: <Pine.LNX.4.64.1107121850000.3775@ps20323.dreamhostps.com>

On Tue, 12 Jul 2011, Henri Sivonen wrote:
> On Thu, 2011-07-07 at 22:33 +0000, Ian Hickson wrote:
> > The JSON algorithm now ends the crawl when it hits a loop, and 
> > replaces the offending duplicate item with the string "ERROR".
> > 
> > The RDF algorithm preserves the loops, since doing so is possible with 
> > RDF. Turns out the algorithm almost did this already, looks like it 
> > was an oversight.
> 
> It seems to me that this approach creates an incentive for people who 
> want to do RDFesque things to publish deliberately non-conforming 
> microdata content that works the way they want for RDF-based consumers 
> but breaks for non-RDF consumers. If such content abounds and non-RDF 
> consumers are forced to support loopiness but extending the JSON 
> conversion algorithm in ad hoc ways, part of the benefit of microdata 
> over RDFa (treeness) is destroyed and the benefit of being well-defined 
> would be destroyed, too, for non-RDF consumption cases.

The "problem" here is that RDF and microdata have different data models, 
and RDF cannot represent microdata's data model with fidelity.

For example, consider how this converts to RDF and compare it to the 
microdata equivalent:

   <div itemscope itemtype="http://example.com/" itemid="http://example.com/1">
    <span itemprop=a>x</span>
   </div>
   <div itemscope itemtype="http://example.com/" itemid="http://example.com/1">
    <span itemprop=b>x</span>
   </div>

There are other things RDF can't represent easily, e.g. it cannot easily 
represent the order of the values in this item:

   <div itemscope itemtype="http://example.com/">
    <span itemprop=a>1</span>
    <span itemprop=a>2</span>
   </div>

As such, I suggest we not worry about the itemref="" loop case, or that we 
try to fix all these cases together (not sure how we'd fix them).

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


From acolwell at google.com  Tue Jul 12 13:45:48 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 13:45:48 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
Message-ID: <CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>

On Mon, Jul 11, 2011 at 5:54 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> It seems to me that the spec is written assuming only one media element is
> consuming the MediaSource. But nothing stops multiple elements consuming the
> same URL simultaneously. Maybe instead of going through a URL you should add
> API directly to media elements.
>

You are right that I don't have anything preventing the MediaSource URL from
being passed to multiple media elements. Only one media element will accept
the URL though because whichever one opens the URL first will transition the
source to the OPEN state. Media elements can only open sources in the CLOSED
state. I'm using a URL for initialization to be consistent with how the
media element is initialized in all other cases. I didn't want to create a
new initialization path.

I thought about adding an attribute to HTMLMediaElement that provided a URL
for signalling MediaSource usage. That mechanism would allow you to create a
URL that only works with that element. When this URL is specified, a
MediaSource attribute would be updated on the media element during loading
and JavaScript could use that to pass data to the tag. I couldn't find a
similar pattern in other APIs so I didn't take that path. If people think
that is a better route then I'm all for it.



> bytesAvailable is for flow control? Instead of doing it this way, I would
> follow WebSockets and use a bufferedAmount attribute to indicate how much
> data is currently buffered up. That makes it easy for authors who don't want
> to care about flow control to just append stuff without encountering errors,
> while still allowing authors who care about flow control to do it.
>
>
Yes. The intent was to provide a way for the browser to control how much
data was being pushed into it. It looks like WebSocket will just close the
connection if it doesn't have enough buffer space and the API doesn't appear
to provide a mechanism to predict how much buffered data will trigger a
close. Do we want similar semantics for media? It seems like the browser
should provide some hints to indicate that it is not ok to push hours/days
of data into this interface.

Thanks for your comments.

Aaron


From acolwell at google.com  Tue Jul 12 13:52:05 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 13:52:05 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <4E1BF864.5000904@alvestrand.no>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<4E1BF864.5000904@alvestrand.no>
Message-ID: <CAA0c1bACv1OM7exvFJs1qSHdu8uKBUp2GGo9TgpUTM9dR+YVfQ@mail.gmail.com>

Hi Harald,

Please point me to specific threads that talk about this. I looked through
the public-webrtc at w3.org archive and didn't see anything about interactive
media handling. I did look through the Mozilla/Cisco proposal
thread<http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html>
and
didn't see anything in my proposal that is incompatible with what is being
proposed there.

Aaron

On Tue, Jul 12, 2011 at 12:31 AM, Harald Alvestrand <harald at alvestrand.no>wrote:

> Not a comment directly on the spec, but you might want to check what people
> are suggesting for interactive media handling in the WEBRTC working group.
>
> Streaming is different from interactive media, but it would be a shame to
> have incompatibilities that can be avoided.
>
>
>


From robert at ocallahan.org  Tue Jul 12 15:28:45 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 10:28:45 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
Message-ID: <CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>

On Wed, Jul 13, 2011 at 8:45 AM, Aaron Colwell <acolwell at google.com> wrote:

> I thought about adding an attribute to HTMLMediaElement that provided a URL
> for signalling MediaSource usage. That mechanism would allow you to create a
> URL that only works with that element. When this URL is specified, a
> MediaSource attribute would be updated on the media element during loading
> and JavaScript could use that to pass data to the tag. I couldn't find a
> similar pattern in other APIs so I didn't take that path. If people think
> that is a better route then I'm all for it.
>

I was thinking more of putting the MediaSource functionality
(open/append/close) on the media element itself.

Do you need to support seeking in with this API? That's hard. It would be
simpler if we didn't have to support seeking. Instead of seeking you could
just open a new stream and pour data in for the new offset.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From karld at opera.com  Tue Jul 12 15:37:06 2011
From: karld at opera.com (Karl Dubost)
Date: Tue, 12 Jul 2011 18:37:06 -0400
Subject: [whatwg] AppCache-related e-mails
In-Reply-To: <BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
References: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
	<Pine.LNX.4.64.1106062352550.19153@ps20323.dreamhostps.com>
	<BANLkTike4CUarLsc4NAftr5Qkqx7V+bNWg@mail.gmail.com>
Message-ID: <2E11AA3A-57A5-4388-B896-394DAF910F89@opera.com>


Le 29 juin 2011 ? 05:27, Felix Halim a ?crit :
> Suppose the content of the main page change very often (like news site).
> In this case, you don't want to cache the main page since the users
> want to see the latest main page, not the cached ones when they open
> the main page later.

Did you also check ESI?
http://www.w3.org/TR/esi-lang

For example in 
http://symfony.com/doc/2.0/book/http_cache.html#edge-side-includes

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From acolwell at google.com  Tue Jul 12 16:14:27 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 16:14:27 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
Message-ID: <CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>

On Tue, Jul 12, 2011 at 3:28 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 8:45 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> I thought about adding an attribute to HTMLMediaElement that provided a
>> URL for signalling MediaSource usage. That mechanism would allow you to
>> create a URL that only works with that element. When this URL is specified,
>> a MediaSource attribute would be updated on the media element during loading
>> and JavaScript could use that to pass data to the tag. I couldn't find a
>> similar pattern in other APIs so I didn't take that path. If people think
>> that is a better route then I'm all for it.
>>
>
> I was thinking more of putting the MediaSource functionality
> (open/append/close) on the media element itself.
>

I'm open to that. In fact that is how my current prototype is implemented
because it was the least painful way to test these ideas in WebKit. My
prototype only implements append() and uses existing media element events as
proxies for the events I've proposed. I only separated this out into a
separate object because I thought people might prefer an object to represent
the source of the media and leave the media element object an endpoint for
controlling media playback.


>
> Do you need to support seeking in with this API? That's hard. It would be
> simpler if we didn't have to support seeking. Instead of seeking you could
> just open a new stream and pour data in for the new offset.
>

 I'd like to be able to support seeking so you can use this mechanism for
on-demand playback. In my prototype seeking wasn't too difficult to
implement. I just triggered it off the seeking event. Any append() that
happens after the seeking event fires is associated with the new seek
location. currentTime is updated with the timestamp in the first cluster
passed to append() after the seeking event fires. Once the media engine has
this timestamp and enough preroll data, then it will fire the seeked event
like normal. I haven't tested this with rapid fire seeking yet, but I think
this mechanism should work.

Aaron


From robert at ocallahan.org  Tue Jul 12 16:17:09 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 11:17:09 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
Message-ID: <CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>

On Wed, Jul 13, 2011 at 11:14 AM, Aaron Colwell <acolwell at google.com> wrote:

>
> I'm open to that. In fact that is how my current prototype is implemented
> because it was the least painful way to test these ideas in WebKit. My
> prototype only implements append() and uses existing media element events as
> proxies for the events I've proposed. I only separated this out into a
> separate object because I thought people might prefer an object to represent
> the source of the media and leave the media element object an endpoint for
> controlling media playback.
>

We're kinda stuck with media elements handling both playback endpoints and
resource loading.


>
>> Do you need to support seeking in with this API? That's hard. It would be
>> simpler if we didn't have to support seeking. Instead of seeking you could
>> just open a new stream and pour data in for the new offset.
>>
>
>  I'd like to be able to support seeking so you can use this mechanism for
> on-demand playback. In my prototype seeking wasn't too difficult to
> implement. I just triggered it off the seeking event. Any append() that
> happens after the seeking event fires is associated with the new seek
> location. currentTime is updated with the timestamp in the first cluster
> passed to append() after the seeking event fires. Once the media engine has
> this timestamp and enough preroll data, then it will fire the seeked event
> like normal. I haven't tested this with rapid fire seeking yet, but I think
> this mechanism should work.
>

How do you communicate the data offset that the element wants to read at
over to the script that provides the data? In general you can't know the
strategy the decoder/demuxer uses for seeking, so you don't know what data
it will request.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From acolwell at google.com  Tue Jul 12 16:30:28 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 16:30:28 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
Message-ID: <CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>

On Tue, Jul 12, 2011 at 4:17 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 11:14 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>>
>> I'm open to that. In fact that is how my current prototype is implemented
>> because it was the least painful way to test these ideas in WebKit. My
>> prototype only implements append() and uses existing media element events as
>> proxies for the events I've proposed. I only separated this out into a
>> separate object because I thought people might prefer an object to represent
>> the source of the media and leave the media element object an endpoint for
>> controlling media playback.
>>
>
> We're kinda stuck with media elements handling both playback endpoints and
> resource loading.
>

Ok.  This makes implementation in WebKit easier for me so I won't push to
hard to keep it separate from the media element. :)


>
>
>>
>>> Do you need to support seeking in with this API? That's hard. It would be
>>> simpler if we didn't have to support seeking. Instead of seeking you could
>>> just open a new stream and pour data in for the new offset.
>>>
>>
>>  I'd like to be able to support seeking so you can use this mechanism for
>> on-demand playback. In my prototype seeking wasn't too difficult to
>> implement. I just triggered it off the seeking event. Any append() that
>> happens after the seeking event fires is associated with the new seek
>> location. currentTime is updated with the timestamp in the first cluster
>> passed to append() after the seeking event fires. Once the media engine has
>> this timestamp and enough preroll data, then it will fire the seeked event
>> like normal. I haven't tested this with rapid fire seeking yet, but I think
>> this mechanism should work.
>>
>
> How do you communicate the data offset that the element wants to read at
> over to the script that provides the data? In general you can't know the
> strategy the decoder/demuxer uses for seeking, so you don't know what data
> it will request.
>

I'm doing WebM demuxing and media fetching in JavaScript. When a seek
occurs, I look at currentTime to see where we are seeking to. I then look at
the CUES index data I've fetched to find the file offset for the closest
seek point to the desired time. The appropriate data is fetched and pushed
into the element via append(). The seeked event firing and readyState
transitioning to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA tells me when I've
sent the element enough data. During playback I just monitor the buffered
attribute to keep a specific duration ahead of the current playback time.

Aaron


From robert at ocallahan.org  Tue Jul 12 16:44:31 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 11:44:31 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
Message-ID: <CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>

On Wed, Jul 13, 2011 at 11:30 AM, Aaron Colwell <acolwell at google.com> wrote:

> I'm doing WebM demuxing and media fetching in JavaScript. When a seek
> occurs, I look at currentTime to see where we are seeking to. I then look at
> the CUES index data I've fetched to find the file offset for the closest
> seek point to the desired time. The appropriate data is fetched and pushed
> into the element via append(). The seeked event firing and readyState
> transitioning to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA tells me when I've
> sent the element enough data. During playback I just monitor the buffered
> attribute to keep a specific duration ahead of the current playback time.


Now I'm rather confused about what you're doing and how you're using this
feature. What format is the data that you're feeding into the element?

I had imagined that this API would let the author feed in the same data as
you would load from some URI. But that can't be what's happening, since in
some element implementations (e.g., Gecko's) loaded data is buffered
internally and seeking might not require any new data to be loaded.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From acolwell at google.com  Tue Jul 12 17:00:58 2011
From: acolwell at google.com (Aaron Colwell)
Date: Tue, 12 Jul 2011 17:00:58 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
Message-ID: <CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>

On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 11:30 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> I'm doing WebM demuxing and media fetching in JavaScript. When a seek
>> occurs, I look at currentTime to see where we are seeking to. I then look at
>> the CUES index data I've fetched to find the file offset for the closest
>> seek point to the desired time. The appropriate data is fetched and pushed
>> into the element via append(). The seeked event firing and readyState
>> transitioning to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA tells me when I've
>> sent the element enough data. During playback I just monitor the buffered
>> attribute to keep a specific duration ahead of the current playback time.
>
>
> Now I'm rather confused about what you're doing and how you're using this
> feature. What format is the data that you're feeding into the element?
>

Sorry I wasn't clear about my intent. Currently I'm feeding it WebM. I could
see this expanding to Ogg and perhaps MP4. Theoretically any format that
looks like a packet stream could work.


>
> I had imagined that this API would let the author feed in the same data as
> you would load from some URI. But that can't be what's happening, since in
> some element implementations (e.g., Gecko's) loaded data is buffered
> internally and seeking might not require any new data to be loaded.
>
>
 No. The idea is to allow JavaScript to manage fetching the media data so
various fetching strategies could be implemented without needing to change
the browser. My initial motivation is for supporting adaptive streaming with
this mechanism, but I think various media mashup and delivery scenarios
could be explored with this.

Aaron


From robert at ocallahan.org  Tue Jul 12 17:05:22 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 13 Jul 2011 12:05:22 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
Message-ID: <CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>

On Wed, Jul 13, 2011 at 12:00 PM, Aaron Colwell <acolwell at google.com> wrote:

> On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> I had imagined that this API would let the author feed in the same data as
>> you would load from some URI. But that can't be what's happening, since in
>> some element implementations (e.g., Gecko's) loaded data is buffered
>> internally and seeking might not require any new data to be loaded.
>>
>>
>  No. The idea is to allow JavaScript to manage fetching the media data so
> various fetching strategies could be implemented without needing to change
> the browser. My initial motivation is for supporting adaptive streaming with
> this mechanism, but I think various media mashup and delivery scenarios
> could be explored with this.
>

I don't think you can do that with this API without making huge assumptions
about what the browser's demuxer, internal caching, etc are doing.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From acolwell at google.com  Wed Jul 13 09:35:58 2011
From: acolwell at google.com (Aaron Colwell)
Date: Wed, 13 Jul 2011 09:35:58 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
	<CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
Message-ID: <CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>

On Tue, Jul 12, 2011 at 5:05 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 12:00 PM, Aaron Colwell <acolwell at google.com>wrote:
>
>> On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> I had imagined that this API would let the author feed in the same data
>>> as you would load from some URI. But that can't be what's happening, since
>>> in some element implementations (e.g., Gecko's) loaded data is buffered
>>> internally and seeking might not require any new data to be loaded.
>>>
>>>
>>  No. The idea is to allow JavaScript to manage fetching the media data so
>> various fetching strategies could be implemented without needing to change
>> the browser. My initial motivation is for supporting adaptive streaming with
>> this mechanism, but I think various media mashup and delivery scenarios
>> could be explored with this.
>>
>
> I don't think you can do that with this API without making huge assumptions
> about what the browser's demuxer, internal caching, etc are doing.
>
>
I am open to suggestions. My intent was that the browser would not attempt
to cache any data passed into append(). It would just demux the buffers that
are sent in. When a seek is requested, it flushes whatever it has and waits
for more data from append().  If the web application wants to do caching it
can use the WebStorage or File APIs. If the browser's media engine needs a
certain amount of "preroll" data before it starts playback it can signal
this explicitly through new attributes or just use HAVE_FUTURE_DATA
& HAVE_ENOUGH_DATA readyStates to signal when it has enough.

Aaron


From johnmrrichards at gmail.com  Wed Jul 13 12:53:23 2011
From: johnmrrichards at gmail.com (John Richards)
Date: Wed, 13 Jul 2011 12:53:23 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
Message-ID: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

Are there plans to have an 'allow-plugins' value?

I'm assuming there will be use-cases where the only protection that is
desired is prevention of parent redirection.

Thanks


From w3c at adambarth.com  Wed Jul 13 13:31:19 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 13 Jul 2011 13:31:19 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
Message-ID: <CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>

Adding allow-plugins today would defeat the prevention of parent redirection.

The short answer is we need an API for informing plugins of the
sandbox flags and a way of confirming that the plugins understand
those bits before we can allow plugins inside sandboxed frames.

Adam


On Wed, Jul 13, 2011 at 12:53 PM, John Richards
<johnmrrichards at gmail.com> wrote:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
>
> Are there plans to have an 'allow-plugins' value?
>
> I'm assuming there will be use-cases where the only protection that is
> desired is prevention of parent redirection.
>
> Thanks
>


From julian.reschke at gmx.de  Wed Jul 13 13:55:48 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 13 Jul 2011 22:55:48 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
Message-ID: <4E1E0654.9070206@gmx.de>

On 2011-07-13 22:31, Adam Barth wrote:
> Adding allow-plugins today would defeat the prevention of parent redirection.
>
> The short answer is we need an API for informing plugins of the
> sandbox flags and a way of confirming that the plugins understand
> those bits before we can allow plugins inside sandboxed frames.

...but that API is outside the scope of what the W3C and the WhatWG 
currently do, so I think it would be great if defining this flag could 
be decoupled from progress on the plugin API layers.

Best regards, Julian


From w3c at adambarth.com  Wed Jul 13 13:58:49 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 13 Jul 2011 13:58:49 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <4E1E0654.9070206@gmx.de>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
Message-ID: <CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>

On Wed, Jul 13, 2011 at 1:55 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2011-07-13 22:31, Adam Barth wrote:
>> Adding allow-plugins today would defeat the prevention of parent
>> redirection.
>>
>> The short answer is we need an API for informing plugins of the
>> sandbox flags and a way of confirming that the plugins understand
>> those bits before we can allow plugins inside sandboxed frames.
>
> ...but that API is outside the scope of what the W3C and the WhatWG
> currently do, so I think it would be great if defining this flag could be
> decoupled from progress on the plugin API layers.

It is coupled in the sense that we can't implement the flag unless and
until such a plug-in API exists.

Adam


From julian.reschke at gmx.de  Wed Jul 13 14:13:05 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 13 Jul 2011 23:13:05 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
Message-ID: <4E1E0A61.5070205@gmx.de>

On 2011-07-13 22:58, Adam Barth wrote:
> On Wed, Jul 13, 2011 at 1:55 PM, Julian Reschke<julian.reschke at gmx.de>  wrote:
>> On 2011-07-13 22:31, Adam Barth wrote:
>>> Adding allow-plugins today would defeat the prevention of parent
>>> redirection.
>>>
>>> The short answer is we need an API for informing plugins of the
>>> sandbox flags and a way of confirming that the plugins understand
>>> those bits before we can allow plugins inside sandboxed frames.
>>
>> ...but that API is outside the scope of what the W3C and the WhatWG
>> currently do, so I think it would be great if defining this flag could be
>> decoupled from progress on the plugin API layers.
>
> It is coupled in the sense that we can't implement the flag unless and
> until such a plug-in API exists.

Yes, but we can *define* the flag in HTML and write down what it means 
with respect to plugin APIs.

Best regards, Julian


From ian at hixie.ch  Wed Jul 13 15:39:40 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Jul 2011 22:39:40 +0000 (UTC)
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <1309931809.4058.148699.camel@robslapu>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com> 
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com> 
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com> 
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
Message-ID: <Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>


In response to off-list feedback, I've renamed StreamTrack to 
MediaStreamTrack to be clearer about its relationship to the other 
interfaces.


On Wed, 1 Jun 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> 
> We are having a bit of discussion regarding the correct behaviour when 
> mandatory arguments are undefined, see this webkit bug for history: 
> https://bugs.webkit.org/show_bug.cgi?id=60622
> 
> Could we have some clarification for the below cases, please: [...]

Hopefully Aryeh and Cameron have sufficiently clarified this; please let 
me know if not.


On Wed, 8 Jun 2011, Per-Erik Brodin wrote:
> 
> The TrackList feature seems to be a good way to control the different 
> components of a Stream. Although it is said that tracks provide a way to 
> temporarily disable a local camera, due to the nature of the 
> ExclusiveTrackList it is still not possible to disable video altogether, 
> i.e. to 'pull down the curtain' in a video conference. I noticed that 
> there is a bug filed on this issue but I do not think the proposed 
> solution there is quite right. There is a state in which no tracks are 
> selected in an ExclusiveTrackList, when the selected index returned is 
> -1. A quick fix would be to allow also setting the active track to -1 in 
> order to deselect all the other tracks.

This is fixed now, hopefully. Let me know if the fix is not sufficient.

(I replaces the videoTracks and audioTracks lists with a single tracks 
list in which you can enable and disable individual tracks.)


> I think a note would be appropriate that although the label on a 
> GeneratedStream is guaranteed to be unique for the conceptual stream, 
> there are situations where one ends up with multiple Stream objects with 
> the same label. For example, if the remote peer adds a stream, then 
> removes it, then adds the same stream again, you would end up with two 
> Stream objects with the same label if a reference to the removed Stream 
> is kept. Also, if the remote peer takes a stream that it receives and 
> sends it back you will end up with a Stream object that has the same 
> label as a local GeneratedStream object.

Done.


> We prefer having a StreamRecorder that you have to stop in order get the
> recorded data (like the previous one, but with asynchronous Blob retrieval)
> and we do not understand the use cases for the current proposal where
> recording continues until the recorder is garbage collected (or the Stream
> ends) and you always get the data from the beginning of the recording. This
> also has to be tied to application quota in some way.

The current design is just the result of needing to define what happens 
when you call getRecordedData() twice in a row. Could you elaborate on 
what API you think we should have?


> The recording example does not seem correct either, it never calls 
> record() and then it calls getRecordedData() directly on the 
> GeneratedStream object.

Fixed.


> Instead of blob: we would like to use stream: for the Stream URLs so 
> that we very early on in the media engine selection can use the protocol 
> scheme to determine how the URL will be handled. Blobs are typically 
> handled in the same way as other media playback. The definition of 
> stream: could be the same as for blob:.

Why can't the UA know which blob: URLs point to streams and which point to 
blobs?


> In addStream(), the readyState of the Stream is not checked to see if it is
> ENDED, in which case adding a stream should fail (perhaps throwing a TypeError
> exception like when passing null).

The problem is that if we do that there'd be a race condition: what 
happens if the stream is ended between the time the script tests whether 
the stream is ended or not and the time the stream is passed to the 
object? I would rather that not be unreliable.

Actually, the spec doesn't currently say anything happens when a stream 
that is being transmitted just ends, either. I guess I should spec that...

...ok, now the spec is clear that an ended stream transmits blackness and 
silence. Same with if some tracks are disabled. (Blackness only if there's 
a video track; silence only if there's an audio track.)


> When a received Stream is removed its readyState is not set to ENDED 
> (and no 'ended' event is dispatched).

I've clarified this so that it is clear that the state change and event do 
happen.


> PeerConnection is an EventTarget but it still uses a callback for the 
> signaling messages and this mixture of events and callbacks is a bit 
> awkward in my opinion. If you would like to change the function that 
> handles signaling messages after calling the constructor you would have 
> to wrap a function call inside the callback to the actual signal 
> handling function, instead of just (re-)setting an onsignal (or 
> whatever) attribute listener (the event could reuse the MessageEvent 
> interface).

When would you change the callback?

My concern with making the callback an event handler is that it leads to a 
set of poor failure modes and complications in the API:

 - It's easy to not register a callback, which makes no sense. There's 
   literally never a use for create a PeerConnection without a signaling 
   channel, as far as I can tell, so making it easier to create one 
   without a callback than with seems like a bad design.

 - It's easy to register multiple callbacks. This equally makes no sense, 
   and would likely only ever be the source of bugs.

 - It makes getting the data more complicated. Instead of passing the 
   callback the string to send, we end up passing an object which has on 
   it one attribute that contains the string.


> Perhaps signalingMessage() could be renamed to 
> add/handle/process/SignalingMessage() or similar to better indicate that 
> it is used to input signaling messages received from the other peer.

processSignalingMessage() works, I guess. I'm not a huge fan of overly 
long names, but Anant suggested making it clearer too, so ok. Done.


> There is a potential problem in the exchange of SDPs in that glare 
> conditions can occur if both peers add streams simultaneously, in which 
> case there will be two different outstanding offers that none of the 
> peers are allowed to respond to according to the SDP offer-answer model. 
> Instead of using one SDP session for all media as the specification 
> suggests, we are handling the offer-answer for each stream separately to 
> avoid such conditions.

Why isn't this handled by the ICE role conflict processing rules? It seems 
like simultaneous ICE restarts would be trivially resolvable by just 
following the rules in the ICE spec. Am I missing something?


On Mon, 13 Jun 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
>
> as WebIDL has been extended with a "is nullable operator" ( 
> http://www.w3.org/TR/WebIDL/#idl-nullable-type) I wonder if the 
> MediaStreams draft can make use of it, please?
> 
> Especially navigator.getUserMedia(options, successCallback [, 
> errorCallback ] ) and PeerConnection(configuration, signalingCallback).

This is done now (thanks to heycam).


On Tue, 14 Jun 2011, Per-Erik Brodin wrote:
> 
> Maybe the null-check in step 3 under "When the PeerConnection() 
> constructor is invoked .." should not be there anymore since 
> signalingCallback is not nullable.

Fixed.


On Wed, 22 Jun 2011, Arun Ranganathan wrote:
> > 
> > Summing up, the problem with the current implementation of Blobs is 
> > that once a URI has been generated for them, by design changes are no 
> > longer reflected in the object URL. In a streaming scenario, this is 
> > not what is needed, rather a long-living Blob that can be appended is 
> > needed and 'streamed' to other parts of the browser, e.g. the<video> 
> > or<audio> element.
> >
> > The original use case was:  make an application which will download 
> > media files from a server and cache them locally, as well as playing 
> > them without making the user wait for the entire file to be 
> > downloaded, converted to a blob, then saved and played, however such 
> > an API covers many other use cases such as on-the-fly on-device 
> > decryption of streamed media content (ie live streams either without 
> > end or static large files that to download completely would be a waste 
> > when only the first couple of seconds need to be buffered and 
> > decrypted before playback can begin)
> > 
> > Some suggestions were to modify or create a new type of Blob, the 
> > StreamingBlob which can be changed without its object url changing and 
> > appended to as new data is downloaded or decoded, and using a similar 
> > process to how large files may start to be decoded/played by a browser 
> > before they are fully downloaded. Other suggestions suggested using a 
> > pull API on the Blob so browsers can request for new data 
> > asynchronously, such as in 
> > <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029998.html>
> > 
> > Some problems however that a browser may face is what to do with urls 
> > which are opened twice, and whether the object url should start from 
> > the beginning (which would be needed for decoding encrypted, on-demand 
> > audio) or start from the end (similar to `tail`, for live streaming 
> > events that need decryption, etc.).

I haven't added support for this in the spec, but based on feedback from 
roc recently I renamed Stream to MediaStream to allow Stream to be used 
for precisely the purpose you describe. That would be something to add to 
the File API spec(s), though.


> I actually think moving to a streaming mode for file reads in general is 
> desirable, but I'm not entirely sure extending Blobs is the way to go 
> for *that* use case, which honestly is the main use case I'm interested 
> in.  We may improve upon ideas after this API goes to Last Call for 
> streaming file reads; hopefully we'll do a better job than other 
> non-JavaScript APIs out there :) [1].  Blob objects as they are 
> currently specified live "in memory" and represent "in memory" File 
> objects as well.  A change to the underlying file isn't captured in the 
> Blob snapshot; moreover, if the file moves or is no longer present at 
> time of read, an error event is fired while processing a read operation.  
> The object URL may be dereferenced, but will result in a 404.

Makes sense.


> The Streaming API explored by WHATWG uses the Object URL scheme for 
> videoconferencing use cases [2], and so the scheme itself is suitable 
> for "resources" that are more dynamic than memory-resident Blob objects. 
> Segment-plays/segment dereferencing in general can be handled through 
> media fragments; the scheme can naturally be accompanied by fragment 
> identifiers.

Indeed.


On Thu, 30 Jun 2011, Aaron Colwell wrote:
> 
> I've been working on an adaptive streaming prototype that uses 
> JavaScript to fetch chunks of media and feeds them to the video tag for 
> decoding. The idea is to let the adaptation algorithm and CDN 
> interactions happen in JavaScript so that they can evolve without the 
> need for browser changes. I'm looking for some guidance about the 
> preferred method for adding this type of functionality. I'm new to this 
> process so please bear with me.

Currently this isn't supported.

Can you elaborate on why you'd rather do this by hand instead of using the 
browsers' streaming features?


> I've also been looking at the WebRTC MediaStream API and was wondering 
> if it makes more sense to create an object similar to the 
> LocalMediaStream object. This has the benefits of unifying how media 
> streams are handled independent of whether they come from a camera or a 
> JavaScript based streaming algorithm. This could also enable sending the 
> media stream through a Peer-to-peer connection instead of only allowing 
> a camera as a source. Here is an example of the type of object I'm 
> talking about.
> 
> interface GeneratedMediaStream : MediaStream {
>   void init(in DOMString type, in UInt8Array init_data);
>   void appendData(in DOMString trackId, in UInt8Array data);
>   void endOfStream();
> 
>   readonly attribute MultipleTrackList audioTracks;
>   readonly attribute ExclusiveTrackList videoTracks;
> };

I imagine we'll support something like this eventually, probably by having 
a new interface for author-generated streams, probably something like what 
roc suggests below, but we should probably get basic video and P2P streams 
working before adding something like this.


On Fri, 1 Jul 2011, Robert O'Callahan wrote:
> 
> I think MediaStreams should not be dealing with compressed data except as an
> optimization when access to decoded data is not required anywhere in the
> stream pipeline.

Indeed.


> If you want to do processing of decoded stream data (which I do --- see 
> http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html), 
> then introducing a decoder inside the stream processing graph creates 
> all sorts of complications.

Right.


> I think the natural way to support the functionality you're looking for 
> is to extend the concept of Blob URLs. Right now you can create a binary 
> Blob, mint a URL for it and set that URL as the source for a media 
> element. The only extension you need is the ability to append data to 
> the Blob while retaining the same URL; you would need to initially mark 
> the Blob as "open" to indicate to URL consumers that the data stream has 
> not ended. That extension would be useful for all sorts of things 
> because you can use those Blob URLs anywhere. An alternative would be to 
> create a new kind of object representing an appendable sequence of Blobs 
> and create an API to mint URLs for it.

Right.


On Wed, 6 Jul 2011, Shwetank Dixit wrote:
> On Fri, 18 Mar 2011 19:32:49 +0530, Lachlan Hunt wrote:
> > On 2011-03-18 05:45, Ian Hickson wrote:
> > > On Thu, 16 Sep 2010, Jonathan Dixon wrote:
> > > > Further, it could be useful to provide a way to query the video 
> > > > source as to whether the camera is oriented relative to the screen 
> > > > (if the underlying system knows; consider a phone device with both 
> > > > a main camera and self-view camera). This is needed to drive the 
> > > > decision on whether to do this horizontal flip or not. In fact, 
> > > > such an application may want to somehow indicate a preference for 
> > > > the self-view camera when multiple cameras are present in the 
> > > > selection list. c.f. a movie-making app which would prefer the 
> > > > outward facing camera.
> > > 
> > > In getUserMedia() the input is extensible; we could definitely add 
> > > "prefer-user-view" or "prefer-environment-view" flags to the method 
> > > (with better names, hopefully, but consider that 'rear' and 'front' 
> > > are misleading terms -- the front camera on a DSLR faces outward 
> > > from the user, the front camera on a mobile phone faces toward the 
> > > user). The user still has to OK the use of the device, though, so 
> > > maybe it should just be left up to the user to pick the camera? 
> > > They'll need to be able to switch it on the fly, too, which again 
> > > argues to make this a UA feature.
> > 
> > We could just add flags to the options string like this:
> > 
> > "video;view=user, audio" or "video;view=environment, audio"
> > 
> > It's worth pointing out that The HTML Media Capture draft from the DAP 
> > WG uses the terms "camera" and "camcorder" for this purpose, but I 
> > find these terms to be very ambiguous and inappropriate, and so we 
> > should not use them here.
>
> Just wanted to know whether there is any consensus on this or not? 
> Mobile phones are coming out with dual cameras (front and back facing) 
> and depending on the use case, the developer might want access to either 
> the front or back one. (For example, for a simple camera app, a back 
> facing will do, but for a web conferencing app, the front facing will be 
> required). At least, the developer should be able to specify which one 
> to enable by default, which then can be changed the user if needed.

The spec currently uses "video user" and "video environment".


> Another question is flash. As far as I have seen, there seems to be no 
> option to specify whether the camera needs to use flash or not. Is this 
> decision left up to the device? (If someone is making an app which is 
> just clicking a picture of the person, then it would be nice to have the 
> camera use flash in low light conditions).

getUserMedia() returns a video stream, so it wouldn't use a flash.


On Wed, 6 Jul 2011, Rob Manson wrote:
>
> There are also tablet devices with stereo cameras on the back and single 
> on the front too.  Stereo will become increasingly common.

getUserMedia() is intended to support returning multiple video tracks for 
this kind of thing. A video track could also just be natively 3D.

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

From robert at ocallahan.org  Wed Jul 13 20:00:07 2011
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Jul 2011 15:00:07 +1200
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
	<CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
	<CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>
Message-ID: <CAOp6jLYP8ks3cAnjahjBjfd9P_UxXOi_2OUJBjW439hcre87+Q@mail.gmail.com>

On Thu, Jul 14, 2011 at 4:35 AM, Aaron Colwell <acolwell at google.com> wrote:

> I am open to suggestions. My intent was that the browser would not attempt
> to cache any data passed into append(). It would just demux the buffers that
> are sent in. When a seek is requested, it flushes whatever it has and waits
> for more data from append().  If the web application wants to do caching it
> can use the WebStorage or File APIs. If the browser's media engine needs a
> certain amount of "preroll" data before it starts playback it can signal
> this explicitly through new attributes or just use HAVE_FUTURE_DATA
> & HAVE_ENOUGH_DATA readyStates to signal when it has enough.


OK, I sorta get the idea. I think you're defining a new interface to the
media processing pipeline that integrates with the demuxer and codecs at a
different level to regular media resource loading. (For example, all the
browser's built-in logic for seeking and buffering would have to be disabled
and/or bypassed.) As such, it would have to be carefully specified,
potentially in a container- or codec-dependent way, unlike APIs like Blobs
which work "just like" regular media resource loading and can thus work with
any container/codec.

I'm not sure what the best way to do this is, to be honest. It comes down to
the use-cases. If you want to experiment with different seeking strategies,
can't you just do that in Chrome itself? If you want scriptable adaptive
streaming (or even if you don't) then I think we want APIs for seamless
transitioning along a sequence of media resources, or between resources
loaded in parallel.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]


From annevk at opera.com  Wed Jul 13 21:49:30 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 14 Jul 2011 06:49:30 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <4E1E0A61.5070205@gmx.de>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de>
Message-ID: <op.vylecs0564w2qv@annevk-macbookpro.local>

On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke <julian.reschke at gmx.de>  
wrote:
> Yes, but we can *define* the flag in HTML and write down what it means  
> with respect to plugin APIs.

It seems much better to wait until it can actually be implemented.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From jonas at sicking.cc  Wed Jul 13 23:22:48 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 13 Jul 2011 23:22:48 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <op.vylecs0564w2qv@annevk-macbookpro.local>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de> <op.vylecs0564w2qv@annevk-macbookpro.local>
Message-ID: <CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>

On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren <annevk at opera.com> wrote:
>
> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke <julian.reschke at gmx.de> wrote:
>>
>> Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs.
>
> It seems much better to wait until it can actually be implemented.

Especially since it's not at all clear to me that a specific opt-in
mechanism is at all needed once we have the appropriate plugin APIs
implemented. And those APIs are needed anyway if we want to allow
plugins in any form in the sandbox.

/ Jonas


From julian.reschke at gmx.de  Thu Jul 14 01:16:18 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 14 Jul 2011 10:16:18 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de>
	<op.vylecs0564w2qv@annevk-macbookpro.local>
	<CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
Message-ID: <4E1EA5D2.4060702@gmx.de>

On 2011-07-14 08:22, Jonas Sicking wrote:
> On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren<annevk at opera.com>  wrote:
>>
>> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke<julian.reschke at gmx.de>  wrote:
>>>
>>> Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs.
>>
>> It seems much better to wait until it can actually be implemented.
>
> Especially since it's not at all clear to me that a specific opt-in
> mechanism is at all needed once we have the appropriate plugin APIs
> implemented. And those APIs are needed anyway if we want to allow
> plugins in any form in the sandbox.

"When the attribute is set, the content is treated as being from a 
unique origin, forms and scripts are disabled, links are prevented from 
targeting other browsing contexts, and plugins are disabled."

A browser negotiating something with plugins using that API and enabling 
them despite @sandbox would violate the above requirement, no?


From shwetankd at opera.com  Thu Jul 14 01:33:36 2011
From: shwetankd at opera.com (Shwetank Dixit)
Date: Thu, 14 Jul 2011 14:03:36 +0530
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
Message-ID: <op.vylop7byim6vpa@shwetank-dixits-macbook.local>

On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:

>
>> Another question is flash. As far as I have seen, there seems to be no
>> option to specify whether the camera needs to use flash or not. Is this
>> decision left up to the device? (If someone is making an app which is
>> just clicking a picture of the person, then it would be nice to have the
>> camera use flash in low light conditions).
> getUserMedia() returns a video stream, so it wouldn't use a flash.

Wouldn't it make sense to have a provision for flash separately then? I  
think a lot of apps would like just a picture instead of video, and in  
those cases, flash would be required. Maybe a seperate provision in the  
spec which defines whether to use flash, and if so, for how many  
miliseconds. Is that doable?
-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/


From whatwg.org at boblet.net  Thu Jul 14 02:38:09 2011
From: whatwg.org at boblet.net (Oli Studholme)
Date: Thu, 14 Jul 2011 18:38:09 +0900
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1C2FFB.5060909@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<4E16EF63.8080709@gmail.com>
	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>
	<4E1B3864.9050207@gmail.com>
	<CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>
	<4E1C2FFB.5060909@gmail.com>
Message-ID: <CAJpND8nWmviqW2g-vPpfijKEBnWqOvMkn9FGFBE4h9ri1DYw5w@mail.gmail.com>

Hi Bjartur,

On Tue, Jul 12, 2011 at 8:28 PM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> ?ann ?ri 12.j?l 2011 09:15, skrifa?i Oli Studholme:

> Datetimes will usually be presented in a localized format to humans.

I think at most user agents will offer users the option to localise
datetime attributes. I don?t think such localisation would be the
default. This is because even in one localisation there are multiple
ways to present dates, and automatically changing a short date form to
a long localised date form may break layout (which user agents avoid
wherever possible).

>> How would the user agent
>> know which way the author wants to present attribution?
>>
> By fetching and reading a linked stylesheet. I think it's easier to style
> attributes then text nodes polluted with delimiters such as "from" and "by"
> that make reordering hard.

This is an interesting idea. However I think this would be a large
increase in complexity (code & l10n) for user agents, and for little
gain. If the user agent was also translating the content then this
might be considered, but merely styling block quote attribution this
way would involve many options per language (depending on what
attributes were present and what data they displayed).

There are a *lot* of potential attributes just for citation.
http://microformats.org/wiki/citation lists 22. Even providing for all
of these will still exclude other potential block quote-related
information, such as notes, copyright etc

> More importantly, how is the author to know how the user wants attribution
> presented?

Heh. Generally users are happy with the author?s content as long as
they can read it. I think there?d be few people in the world that
would care enough to add user styles to change e.g. from a
bibliographic to an author-date system citation. For more than this
you may need to wait for the semantic web ;)

>> Again I have no idea how a user agent would follow these rules.
>> Arbitrarily showing one thing in one viewport size and something else
>> at a different size would be a bug (arbitrarily meaning without
>> author/user intervention, such as via CSS).
>
> A feature to one, a bug to another. The existence of the CSS height and
> width media features suggests that catering style to varying viewport sizes
> is desired by others than just me. I don't see why a user agent should seek
> an authors' permission to style a document for an unusually sized viewport,
> nor require users to write their own stylesheets instead of shipping
> customizable stylesheets.

However you?re advocating the user agent follow these rules without
author/user intervention. The reason that adaptive layout isn?t done
by default by user agents (with some notable exceptions in mobile) is
that it has the potential to break things, in such a way that neither
the author or user can fix.

> For a lack of a valid URI identifying myself, I used an unregistered
> uri-scheme ("kennitala") and my national ID as the scheme-specific part. The
> exact URI in question is unimportant to the example, but I see no reason to
> restrict values of cite to locators only, as opposed to identifiers in
> general. Quoting books identified by ISBN numbers seems like a good enough
> use case to me.

But what would a user agent do with an ISBN number? if there?s a URL
at least the user agent can theoretically present a link, like how the
cite attribute is supposed to work. I also just realised you used this
in your footer example for an href. This would present text styled as
a link that doesn?t respond to clicks, a usability problem.

>> This proves Jeremy's earlier point about attributes being a bad place
>> to store data. Unless you look at the source you?d never notice these
>> mistakes.
>>
> Sure I would, had I actually tried to, say, render them or validate before
> posting them on the Internet. I refrained from doing so as I knew this to be
> invalid markup, anyway. Where datetime to be a valid attribute of blockquote

You are assuming the rest of the internet?s authors are as
conscientious as you are :/ humans are very adept at making mistakes.
hidden data makes mistakes in this data far harder to identify and
correct

> No, that would be quite an odd rendering. More likely renderings:
>
> ?ann annan apr?l 1997 skrifa?i Bjartur Thorlacius:
>> Lorem ipsum
>
>
> On the second April, 1997 Bjartur Thorlacius wrote:
>> Lorem ipsum
>
> ? Lorem ipsum
> ? ? ? ?? Bjartur Thorlacius
>
> It all depends on the user's localized stylesheet.

this requires the user agent to localise the attributes before
displaying them. what about for languages which aren?t localised in
the user?s stylesheet?

>> There?s also the possibility of adding another inline element, such as
>> <credit>, which could let someone credit an author of a quote, or e.g.
>> to credit a photographer of an image together<figure> ?and
>> <figcaption>.
>>
> So <credit> would be an inline version of <footer>, to be contained in <q>?
> Would it not be more consistent to use attributes, in that case? Note that
> <figcaption> may contain <footer>s.

I?m not sure on the earlier discussion about <credit>, and actually
it?s only my assumption that it?d be inline. I?m not even sure if it
would contain all credited information (including perhaps copyright
data), or just the creator?s name. Hopefully someone will weigh in on
this?

>> While something like<a> ?and<cite> ?in a<footer> ?could work for
>> citation, I still don?t have a good idea about citing explicitly when
>> the citation is inline (on the last line of the block quote), or for
>> <q>.
>>
> I do: use the same attributes as for <blockquote>.
> Referencing people as works as I did in my examples is probably
> bad (read: terrible) style. There should be a sepearate @author attribute
> for attributing an author, distinct from the @cite attribute for citing the
> work.

what about for notes on a blockquote, such as ?emphasis mine?? you?d
need another attribute. what about for when you?d like to contain
HTML, such as ?<em>emphasis</em> mine?? attributes prevent this use
case.

> On a third thought, using a <footer> child of <blockquote> doesn't seem so
> confusing after all, but it'd be even less confusing to HTML newcomers were
> it named e.g. <credit>. But then it would not be an appropriate element for
> "fat footers", whatever they are. I don't see what citations and "fat
> footers" have in common.

in graphic design a footer contains supplementary information about
the content it follows. the spec initially disallowed ?fat footers?,
but the naming and common usage would have led to people using them
for fat footers regardless of the spec. they still contain
supplementary information about their sectioning element or sectioning
root. This semantic connection seems stronger to me than one based on
arbitrary size

peace - oli studholme


From karld at opera.com  Thu Jul 14 03:49:56 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 06:49:56 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
Message-ID: <CAE46406-D675-4428-B6B8-8511352AB696@opera.com>


Le 8 juil. 2011 ? 07:20, Jeremy Keith a ?crit :
> 1) Oli has shown the real-world use cases for attribution *within* blockquotes.

using that for years (almost every day), an example
http://www.la-grange.net/2011/06/05/fruit

<blockquote cite="urn:isbn:978-2-07-07533-7">
    <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
    <p>? <q>M?me si l'on vient me chercher<br/>
        Comment, abandonnant la ros?e<br/>
        De pareil lotus,<br/>
        Retournerai-je<br/>
        Dans le monde changeant et frivole ?</q> ?</p>
    <p>et j'envoyais ce p?tale.</p>
    <p class="source">
        <cite class="auteur">Shonagon, Sei</cite>, 
        <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
</blockquote>


mentioned here 
http://lists.w3.org/Archives/Public/www-html/2005Jun/0201

My favorite issue being when there is a mix of cite in the prose and blockquotes, there is no mechanism to associate the right cite with the right blockquote and this is happening often when you write about things referring to different sources.
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Dec/0016


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From jkorpela at cs.tut.fi  Thu Jul 14 04:09:06 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 14 Jul 2011 14:09:06 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
Message-ID: <4E1ECE52.7090506@cs.tut.fi>

14.07.2011 13:49, Karl Dubost wrote:

> using that for years (almost every day), an example
> http://www.la-grange.net/2011/06/05/fruit
>
> <blockquote cite="urn:isbn:978-2-07-07533-7">
>      <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
>      <p>?<q>M?me si l'on vient me chercher<br/>
>          Comment, abandonnant la ros?e<br/>
>          De pareil lotus,<br/>
>          Retournerai-je<br/>
>          Dans le monde changeant et frivole ?</q>  ?</p>
>      <p>et j'envoyais ce p?tale.</p>
>      <p class="source">
>          <cite class="auteur">Shonagon, Sei</cite>,
>          <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
> </blockquote>

That?s quite good, though I think <footer class="source"> would be in 
principle better than <p class="source">, though using <footer> still 
requires some precautions in practice (I mean ?teaching? it to old IE 
using document.createElement('footer') in JavaScript, so that your 
styling will take effect).

Microdata or microformats might be used to standardize the use of 
specific attributes to be used, like class="credits", class="author", 
class="title" etc., if desired. But I don?t think that?s particularly 
important.

(I don't like to nitpick on the author identification, but wouldn?t
<cite class="auteur" lang="jp-Latn">Sh?nagon, Sei</cite> be better?)

> My favorite issue being when there is a mix of cite in the prose and blockquotes,
 > there is no mechanism to associate the right cite with the right 
blockquote

It would be nice to be able to associate credits with quotations at the 
markup level, but in practice, presenting credits visibly (or audibly or 
touchably) is much more important. No law requires us to provide credits 
that way, but laws do require us to provide credits the way they are 
normally provided in good style (or in a better way).

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From svartman95 at gmail.com  Thu Jul 14 05:58:58 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 12:58:58 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAJpND8nWmviqW2g-vPpfijKEBnWqOvMkn9FGFBE4h9ri1DYw5w@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<4E16EF63.8080709@gmail.com>	<3FBE9F40-5CED-4B0A-8B82-98A1B86C2B01@adactio.com>	<4E1B3864.9050207@gmail.com>	<CAJpND8=MBsw73M1njcE9wyLig=hyZxacXpQaLQQjDhj4mG8wNw@mail.gmail.com>	<4E1C2FFB.5060909@gmail.com>
	<CAJpND8nWmviqW2g-vPpfijKEBnWqOvMkn9FGFBE4h9ri1DYw5w@mail.gmail.com>
Message-ID: <4E1EE812.6010208@gmail.com>

?ann fim 14.j?l 2011 09:38, skrifa?i Oli Studholme:
> in graphic design a footer contains supplementary information about
> the content it follows. the spec initially disallowed ?fat footers?,
> but the naming and common usage would have led to people using them
> for fat footers regardless of the spec. they still contain
> supplementary information about their sectioning element or sectioning
> root. This semantic connection seems stronger to me than one based on
> arbitrary size
>
Would it not be less confusing to forbid 'fat footers' and rename footer 
-> credit?


From svartman95 at gmail.com  Thu Jul 14 06:10:06 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 13:10:06 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1ECE52.7090506@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi>
Message-ID: <4E1EEAAE.3050701@gmail.com>

?ann fim 14.j?l 2011 11:09, skrifa?i Jukka K. Korpela:
> 14.07.2011 13:49, Karl Dubost wrote:
>> <blockquote cite="urn:isbn:978-2-07-07533-7">
>> <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
>> <p>?<q>M?me si l'on vient me chercher<br/>
>> Comment, abandonnant la ros?e<br/>
>> De pareil lotus,<br/>
>> Retournerai-je<br/>
>> Dans le monde changeant et frivole ?</q> ?</p>
>> <p>et j'envoyais ce p?tale.</p>
>> <p class="source">
>> <cite class="auteur">Shonagon, Sei</cite>,
>> <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
>> </blockquote>
Yes, but for usability reasons the cite[@class=titre] should represent a 
hyperlink to the cited book. Is an user agent to find a cite descendant 
of <blockquote> and make it represent a hyperlink to the cited resource 
(identified by the URI in the cite attribute of blockquote)?

> (I don't like to nitpick on the author identification, but wouldn?t
> <cite class="auteur" lang="jp-Latn">Sh?nagon, Sei</cite> be better?)
I don't think author names are allowed in <cite> in HTML 5.


From timeless at gmail.com  Thu Jul 14 06:23:00 2011
From: timeless at gmail.com (timeless)
Date: Thu, 14 Jul 2011 09:23:00 -0400
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <op.vylop7byim6vpa@shwetank-dixits-macbook.local>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
	<op.vylop7byim6vpa@shwetank-dixits-macbook.local>
Message-ID: <CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>

I'd expect a web app to have no idea about device camera
specifications and thus to not be able to properly specify a flash
duration. I don't see how such a thing is valuable.

If a user is in a movie theater, or a museum, it's quite likely they
won't notice a web app is forcing a flash. Let the user control flash
through a useragent only or host application only mode. I believe the
hazards of exposing flash duration outweigh any benefits. The only
application class I know of built using control of camera flash is
"flash-light", and that's both a hack and not guaranteed to be
workable for all possible flash technologies.

On 7/14/11, Shwetank Dixit <shwetankd at opera.com> wrote:
> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
>
>>
>>> Another question is flash. As far as I have seen, there seems to be no
>>> option to specify whether the camera needs to use flash or not. Is this
>>> decision left up to the device? (If someone is making an app which is
>>> just clicking a picture of the person, then it would be nice to have the
>>> camera use flash in low light conditions).
>> getUserMedia() returns a video stream, so it wouldn't use a flash.
>
> Wouldn't it make sense to have a provision for flash separately then? I
> think a lot of apps would like just a picture instead of video, and in
> those cases, flash would be required. Maybe a seperate provision in the
> spec which defines whether to use flash, and if so, for how many
> miliseconds. Is that doable?
> --
> Shwetank Dixit
> Web Evangelist,
> Site Compatibility / Developer Relations / Core Engineering Group
> Member - W3C Mobile Web for Social Development (MW4D) Group
> Member - Web Standards Project (WaSP) - International Liaison Group
> Opera Software - www.opera.com
>
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>

-- 
Sent from my mobile device


From jonas at sicking.cc  Thu Jul 14 08:01:52 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 14 Jul 2011 08:01:52 -0700
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <4E1EA5D2.4060702@gmx.de>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de> <op.vylecs0564w2qv@annevk-macbookpro.local>
	<CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
	<4E1EA5D2.4060702@gmx.de>
Message-ID: <CA+c2ei9sYhpzvMMK+nSxaLByvromXVQzCeD1so8zJ3CGRKjLUw@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:16 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2011-07-14 08:22, Jonas Sicking wrote:
>>
>> On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren<annevk at opera.com>
>> ?wrote:
>>>
>>> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke<julian.reschke at gmx.de>
>>> ?wrote:
>>>>
>>>> Yes, but we can *define* the flag in HTML and write down what it means
>>>> with respect to plugin APIs.
>>>
>>> It seems much better to wait until it can actually be implemented.
>>
>> Especially since it's not at all clear to me that a specific opt-in
>> mechanism is at all needed once we have the appropriate plugin APIs
>> implemented. And those APIs are needed anyway if we want to allow
>> plugins in any form in the sandbox.
>
> "When the attribute is set, the content is treated as being from a unique
> origin, forms and scripts are disabled, links are prevented from targeting
> other browsing contexts, and plugins are disabled."
>
> A browser negotiating something with plugins using that API and enabling
> them despite @sandbox would violate the above requirement, no?

True. I would be fine with removing the plugin requirement. Or
changing it such that it states that plugins can only be loaded if
it's done in a manner that ensures that all other requirements are
still fulfilled. Or just dealing with this once there actually are
plugins and plugin APIs which could be loaded while still fulfilling
the other requirements.

/ Jonas


From acolwell at google.com  Thu Jul 14 09:08:41 2011
From: acolwell at google.com (Aaron Colwell)
Date: Thu, 14 Jul 2011 09:08:41 -0700
Subject: [whatwg] Proposal for a MediaSource API that allows sending
 media data to a HTMLMediaElement
In-Reply-To: <CAOp6jLYP8ks3cAnjahjBjfd9P_UxXOi_2OUJBjW439hcre87+Q@mail.gmail.com>
References: <CAA0c1bCZWGWZG+hGK60Bgm0L6wEitihJubs1+73HctcnGoymFQ@mail.gmail.com>
	<CAOp6jLaf2JV3cEdkTHNLb7Gcv5ofNF_dS7PsjY1bERdFJN3sFw@mail.gmail.com>
	<CAA0c1bA8sKZ0JVf6yqfbTwby-5J4_Yi=9_hUq3QfhHDhtnG7LQ@mail.gmail.com>
	<CAOp6jLYo=nRztdT-ppe+A2t9mxg920kT=5ct-ND4kGGH2xAKsg@mail.gmail.com>
	<CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
	<CAOp6jLZ4BvBd3pAuvOUe66nL-ARLyD+VzuFD7HNStJE0+vqR7Q@mail.gmail.com>
	<CAA0c1bCukbqg8ZSF_k_oJSskxuWPGWJyTNrKeBSvvzCWquZSaQ@mail.gmail.com>
	<CAOp6jLYvjWD-PX8NMWcRy_DhH_pDigxOWYrYJd3nuPAWJJ+m9g@mail.gmail.com>
	<CAA0c1bB4W4Ea4hYoqrvJ6ciS7S-dDvbEr8rzFwZB+bSsh7+NBQ@mail.gmail.com>
	<CAOp6jLZQXRx-jVUx=UVEwSEi+A_Lwk35Kw6WVJNOjMBXLkRuvA@mail.gmail.com>
	<CAA0c1bDX7-FewnVJX6pUHqE-m0jL5Ckq9613=8-FMy7-ZR9a-w@mail.gmail.com>
	<CAOp6jLYP8ks3cAnjahjBjfd9P_UxXOi_2OUJBjW439hcre87+Q@mail.gmail.com>
Message-ID: <CAA0c1bB9hWxysKZ4OFQHrio4d6CtpQr-OcNMROXk=yF3Yi5quw@mail.gmail.com>

On Wed, Jul 13, 2011 at 8:00 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Jul 14, 2011 at 4:35 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> I am open to suggestions. My intent was that the browser would not attempt
>> to cache any data passed into append(). It would just demux the buffers that
>> are sent in. When a seek is requested, it flushes whatever it has and waits
>> for more data from append().  If the web application wants to do caching it
>> can use the WebStorage or File APIs. If the browser's media engine needs a
>> certain amount of "preroll" data before it starts playback it can signal
>> this explicitly through new attributes or just use HAVE_FUTURE_DATA
>> & HAVE_ENOUGH_DATA readyStates to signal when it has enough.
>
>
> OK, I sorta get the idea. I think you're defining a new interface to the
> media processing pipeline that integrates with the demuxer and codecs at a
> different level to regular media resource loading. (For example, all the
> browser's built-in logic for seeking and buffering would have to be disabled
> and/or bypassed.)


Yes.


> As such, it would have to be carefully specified, potentially in a
> container- or codec-dependent way, unlike APIs like Blobs which work "just
> like" regular media resource loading and can thus work with any
> container/codec.
>

My hope is that the data passed to append will basically look like the "live
streaming" form of containers like Ogg & WebM so this isn't totally foreign
to the existing browser code. We'd probably have to spec the level of
support for Ogg chaining and multiple WebM segments but I don't think that
should be too bad. Seeking is where the trickiness happens and I was just
planning on making it look like a new "live" stream whose starting timestamp
indicates the actual point seeked to.

I was tempted to create an API that just passed in compressed video/audio
frames and made JavaScript do all of the demuxing, but I thought people
might find that too radical.


>
> I'm not sure what the best way to do this is, to be honest. It comes down
> to the use-cases. If you want to experiment with different seeking
> strategies, can't you just do that in Chrome itself? If you want scriptable
> adaptive streaming (or even if you don't) then I think we want APIs for
> seamless transitioning along a sequence of media resources, or between
> resources loaded in parallel.
>
>
I think the best course of action is for me to get my prototype in a state
where others can play with it and I can demonstrate some of the uses that
I'm trying to enable. I think that will make this a little more concrete.
 I'll keep this list posted on my progress.

Thanks for your help,
Aaron


From ifette at google.com  Thu Jul 14 11:45:21 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 11:45:21 -0700
Subject: [whatwg] a rel=attachment
Message-ID: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>

Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is to set a
content-disposition header. *However, sometimes it is not possible for the
page author to have control over the response headers sent by the
server.*(A related example is offline apps, which may wish to provide
the user with
a way to "download" a file stored locally using the filesystem API but again
can't set any headers.) It would be nice to provide the page author with a
client side mechanism to trigger a download.

After mulling this over with some application developers who are trying to
use this functionality, it seems like adding a "rel" attribute to the <a>
tag would be a straightforward, minimally invasive way to address this use
case. <a rel=attachment href=blah.pdf> would indicate that the browser
should treat this link as if the response came with a content-disposition:
attachment header, and offer to download/save the file for the user.

-Ian


From jackalmage at gmail.com  Thu Jul 14 11:49:44 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 11:49:44 -0700
Subject: [whatwg] Microdata - Handling the case where a string is upgraded
	to an object
Message-ID: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>

Some IRC discussion this morning concerned the scenario where an API
starts by exposing a property as a string, but later wants to change
it to be a complex object.

This appears to be a reasonably common scenario.  For example, a
vocabulary with a "name" property may start with it being a string,
and then later change to an object exposing "firstname"/"lastname"/etc
properties.  A vocabulary for a music library may start by having
"track" as a string, then later expanding it to expose the track
title, the individual artist, the running time, etc.

In a very similar vein, the CSSOM is currently defined to always
return property values as strings.  We want to instead return complex
objects that expose useful information and interfaces specialized on
the value's type, however.  For compat reasons, we have to use an
entirely different accessor in order to expose this type of thing.

It seems that this may be a useful problem to solve in Microdata.  We
can expose either an attribute or a privileged property name for the
object's "name"/"title"/"string representation".  Then, when using the
.items accessor, objects can be returned with a custom .toString that
returns that value, so they can be used as strings in legacy code.

Thoughts?

~TJ


From kevinmarks at gmail.com  Thu Jul 14 11:59:02 2011
From: kevinmarks at gmail.com (Kevin Marks)
Date: Thu, 14 Jul 2011 11:59:02 -0700
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
Message-ID: <CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>

There is another common pattern, seen in blogging a lot, of putting
the citation at the top eg
As <cite class="vcard"><a href="http://www.gyford.com/phil/"
class="url" rel="acquaintance met colleague"><abbr title="Phil Gyford"
class="fn">Phil</abbr></a></cite> wrote about the <a
href="http://www.gyford.com/phil/writing/2009/04/28/geocities.php">ugly
and neglected fragments</a> of Geocities:</p>

<blockquote>
  <p>GeoCities is an awful, ugly, decrepit mess. And this is why it
will be sorely missed. It?s not only a fine example of the amateur web
vernacular but much of it is an increasingly rare example of a
<em>period</em> web vernacular. GeoCities sites show what normal,
non-designer, people will create if given the tools available around
the turn of the millennium.</p>
</blockquote>

(from jeremy) or pretty much any post here:

http://www.theatlantic.com/ta-nehisi-coates/

Would a <header> pattern in the blockquote work for this?

If I was writing a detector for this pattern, <a> followed by a colon
and  <blockquote> would do it pretty reliably...

On Fri, Jul 8, 2011 at 4:20 AM, Jeremy Keith <jeremy at adactio.com> wrote:
>
> Oli wrote:
> > I?ve outlined the problem and some potential solutions (with their
> > pros and cons) in:
> > ?http://oli.jp/2011/blockquote/
>
> Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/
>
> Oli continues:
> > I think the blockquote spec should be changed to allow the inclusion
> > of notes and attribution (quote metadata), perhaps by the addition of
> > a sentence like:
> > ??Block quotes may also contain annotations or attribution, inline or
> > in an optional footer element?
> > This would change blockquote from being purely source content, to
> > being source content with possible metadata inline or in a footer.
> > However I don?t think that?s a problem, as these things increase the
> > value of the quoted content. I think a spec change is necessary to
> > accommodate common quoting practices.
>
> This sounds good to me.
>
> 1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the "Pave the cowpaths" principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material):
>
> http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths
>
> "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
>
>
> 2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle "Solve real problems."
>
> http://www.w3.org/TR/html-design-principles/#solve-real-problems
>
> "Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today."
>
>
> 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle "Avoid needless complexity."
>
> http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity
>
> "Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand."
>
>
> 4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle "Support existing content."
>
> http://www.w3.org/TR/html-design-principles/#support-existing-content
>
> "The benefit of the proposed change should be weighed against the likely cost of breaking content"
>
> Jeremy
>
> --
> Jeremy Keith
>
> a d a c t i o
>
> http://adactio.com/
>
>


From ifette at google.com  Thu Jul 14 12:00:16 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 12:00:16 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CAF4kx8eo97CYxPULzvy3goaMXR_Ns2yCqfvVPQ_269ip9+KFMA@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>

> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
> After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.
>
> -Ian
>

I should also point out that there was a similar proposal from Dennis
Joachimsthaler last year. There was a fair amount of discussion on the
thread back and forth; near the end Hixie's recommendation [1] was to
propose this as a rel= attribute and push forward with implementation. That
is essentially what we intend to do.

[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028148.html

-Ian


From karld at opera.com  Thu Jul 14 12:03:43 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 15:03:43 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <00DACDFE-FA6B-4DA2-BDD6-1A73ACB9EC12@opera.com>


Le 14 juil. 2011 ? 14:45, Ian Fette (????????) a ?crit :
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example).

Which current websites?

> it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.



Are you then proposing to reverse the contextual click on the link to give the option, "view in the browser". All browsers have currently implemented "save this link as"?

It may please some users. As a user, I will place this in the category of super annoying features. It then means I would need a preference in the browser to disable it. 

Then it is at least 3 modifications to implement it.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From ifette at google.com  Thu Jul 14 12:08:19 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 12:08:19 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <00DACDFE-FA6B-4DA2-BDD6-1A73ACB9EC12@opera.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<00DACDFE-FA6B-4DA2-BDD6-1A73ACB9EC12@opera.com>
Message-ID: <CAF4kx8cSKqj+B0AWayhFchjFXiRDZeJBUY2Xg7ZKq6X-w29XAQ@mail.gmail.com>

On Thu, Jul 14, 2011 at 12:03 PM, Karl Dubost <karld at opera.com> wrote:

>
> Le 14 juil. 2011 ? 14:45, Ian Fette (????????) a ?crit :
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example).
>
> Which current websites?
>
> Take gmail as one example off the top of my head. If any of these files are
present as an attachment I get an option to view or download.



> > it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
>
>
> Are you then proposing to reverse the contextual click on the link to give
> the option, "view in the browser". All browsers have currently implemented
> "save this link as"?
>
> It may please some users. As a user, I will place this in the category of
> super annoying features. It then means I would need a preference in the
> browser to disable it.
>
> Then it is at least 3 modifications to implement it.
>


Not for all links, no, only links that have rel=attachment. And I would
assume that on such a link, yes, perhaps a "view inline" right click option
may make sense. I wouldn't expect this to be used on anywhere near a
majority of links, but an author can already try to craft a download link --
it's just that in many cases it's either requiring them to jump through
hoops or impossible (e.g. offline apps).


>
> --
> Karl Dubost - http://dev.opera.com/
> Developer Relations & Tools, Opera Software
>
>


From andy at pigsonthewing.org.uk  Thu Jul 14 12:15:03 2011
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu, 14 Jul 2011 20:15:03 +0100
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CABiXOE=9Dy7usKGF9_j827=YGjSfCTtv_S9TtmeDj_KB_1y5gg@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>:
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the
> server.*(A related example is offline apps, which may wish to provide
> the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
> After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.

How would this be different to the already-available rel="enclosure" ?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk


From ifette at google.com  Thu Jul 14 12:22:43 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 12:22:43 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABiXOE=9Dy7usKGF9_j827=YGjSfCTtv_S9TtmeDj_KB_1y5gg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABiXOE=9Dy7usKGF9_j827=YGjSfCTtv_S9TtmeDj_KB_1y5gg@mail.gmail.com>
Message-ID: <CAF4kx8dNZyfmg0YsxAHusF1SaJp=oogNx8LHQhmC1As1pF5Zzg@mail.gmail.com>

2011/7/14 Andy Mabbett <andy at pigsonthewing.org.uk>

> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> > page author to have control over the response headers sent by the
> > server.*(A related example is offline apps, which may wish to provide
> > the user with
> > a way to "download" a file stored locally using the filesystem API but
> again
> > can't set any headers.) It would be nice to provide the page author with
> a
> > client side mechanism to trigger a download.
> >
> > After mulling this over with some application developers who are trying
> to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
> How would this be different to the already-available rel="enclosure" ?
>

It seems quite similar, except that afaik no browser yet acts on enclosure.
I don't want to get into bikeshedding discussions, both enclosure and
attachment have precedent, I simply want to implement this :)


>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>


From svartman95 at gmail.com  Thu Jul 14 12:26:20 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 19:26:20 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
Message-ID: <CAOKKrgNzTvZWxeY641q+z0NYOYArd-AV1vHbu+VyZSQtd6QXSA@mail.gmail.com>

On 7/14/11, Kevin Marks <kevinmarks at gmail.com> wrote:
> There is another common pattern, seen in blogging a lot, of putting
> the citation at the top eg
> As <cite class="vcard"><a href="http://www.gyford.com/phil/"
> class="url" rel="acquaintance met colleague"><abbr title="Phil Gyford"
> class="fn">Phil</abbr></a></cite> wrote about the <a
> href="http://www.gyford.com/phil/writing/2009/04/28/geocities.php">ugly
> and neglected fragments</a> of Geocities:</p>
>
> <blockquote>
>   <p>GeoCities is an awful, ugly, decrepit mess. And this is why it
> will be sorely missed. It?s not only a fine example of the amateur web
> vernacular but much of it is an increasingly rare example of a
> <em>period</em> web vernacular. GeoCities sites show what normal,
> non-designer, people will create if given the tools available around
> the turn of the millennium.</p>
> </blockquote>
>
> (from jeremy) or pretty much any post here:
>
> http://www.theatlantic.com/ta-nehisi-coates/
>
> Would a <header> pattern in the blockquote work for this?
>
> If I was writing a detector for this pattern, <a> followed by a colon
> and  <blockquote> would do it pretty reliably...
>
Ideally, the same markup should be used to mark citations up whether
they're displayed one way or another. Whether to render author name(s)
before or after the quotation is a matter of style.


From svartman95 at gmail.com  Thu Jul 14 12:35:41 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 19:35:41 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CAOKKrgNxQt_WXZ_88HO_kV65uH=SnSQ=W2C9V3si97uFJ2KuxA@mail.gmail.com>

On 7/14/11, Ian Fette (????????) <ifette at google.com> wrote:
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the
> server.*(A related example is offline apps, which may wish to provide
> the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
As already stated you can use rel="enclosure". Alternatively, you can
specify the type attribute with the appropriate value and let the user
agent offer to write it to permanent storage.


From karld at opera.com  Thu Jul 14 12:35:49 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 15:35:49 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
Message-ID: <9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>


Le 14 juil. 2011 ? 14:59, Kevin Marks a ?crit :
> If I was writing a detector for this pattern, <a> followed by a colon
> and  <blockquote> would do it pretty reliably...

yup unfortunately there are also many cases where you have more names in an introducing paragraph. It is happening when I'm writing, and the issue is then to tie the right person with the right blockquote/q

I like the pattern id/for pattern of forms. We could imagine

<p>
<span for="quoteA" class="author">Sir John Typo</span> 
has written plenty of a wonderful thing 
in <cite for="quoteA">Amazing title</cite> very similar to those in
<span for="quoteB" class="author">Susan Spellchecker</span>'s writings

<blockquote id="quoteA">
[?]
</blockquote>

compare to <cite for="quoteB">Amazing title</cite>

<blockquote id="quoteB">
</blockquote>


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From glenn at zewt.org  Thu Jul 14 12:36:13 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 14 Jul 2011 15:36:13 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>

> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
>

This has been raised a couple times:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
was derailed partway through)

I've wanted this several times and I'm strongly in favor of it.

After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
>

This isn't enough; the filename needs to be overridable as well, as it is
with Content-Disposition.  My recommendation has been:

<a href=image.jpg download>
<a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>

where the first is equivalent to Content-Disposition: attachment, and the
second is equivalent to Content-Disposition: attachment;
filename=picture.jpg.

-- 
Glenn Maynard


From tantek at cs.stanford.edu  Thu Jul 14 12:51:17 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 12:51:17 -0700
Subject: [whatwg] proposal: extend <time> to markup durations
Message-ID: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>

Some in the microformats community have been making good use of the
<time> element, e.g. for publishing hCalendar, and implementing
consuming/converting hCalendar [1] with good success.

It would be great if the <time> element could support expressing
durations as well for the use cases as needed by the hMedia and hAudio
microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal, examples, faq, discussion (please contribute)

http://wiki.whatwg.org/wiki/Time_element#duration

Thanks,

Tantek

[1] http://microformats.org/wiki/h2vx#HTML5_support

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5


From ifette at google.com  Thu Jul 14 13:13:33 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 14 Jul 2011 13:13:33 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
Message-ID: <CAF4kx8eMH0ThXo4KEBPFRCyLZKJ2oZmSRxE7cqHwopaTMb_fjQ@mail.gmail.com>

The download=filename seems like a nice proposal (assuming that the filename
is optional, and if not specified it just takes whatever the name would
otherwise be). It also neatly solves the filename issue without cluttering
the a tag with tons of options.

On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>
> Many websites wish to offer a file for download, even though it could
>> potentially be viewed inline (take images, PDFs, or word documents as an
>> example). Traditionally the only way to achieve this is to set a
>> content-disposition header. *However, sometimes it is not possible for the
>>
>
> This has been raised a couple times:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through)
>
> I've wanted this several times and I'm strongly in favor of it.
>
> After mulling this over with some application developers who are trying to
>> use this functionality, it seems like adding a "rel" attribute to the <a>
>> tag would be a straightforward, minimally invasive way to address this use
>> case. <a rel=attachment href=blah.pdf> would indicate that the browser
>>
>
> This isn't enough; the filename needs to be overridable as well, as it is
> with Content-Disposition.  My recommendation has been:
>
> <a href=image.jpg download>
> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>
>
> where the first is equivalent to Content-Disposition: attachment, and the
> second is equivalent to Content-Disposition: attachment;
> filename=picture.jpg.
>
> --
> Glenn Maynard
>
>


From darin at chromium.org  Thu Jul 14 13:16:57 2011
From: darin at chromium.org (Darin Fisher)
Date: Thu, 14 Jul 2011 13:16:57 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
Message-ID: <CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>

On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> >
>
> This has been raised a couple times:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
> was derailed partway through)
>
> I've wanted this several times and I'm strongly in favor of it.
>

Yes, it seems very useful.



>
> After mulling this over with some application developers who are trying to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> >
>
> This isn't enough; the filename needs to be overridable as well, as it is
> with Content-Disposition.  My recommendation has been:
>
> <a href=image.jpg download>
> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>
>
> where the first is equivalent to Content-Disposition: attachment, and the
> second is equivalent to Content-Disposition: attachment;
> filename=picture.jpg.
>
>
This is an interesting variation!  I like that it addresses the issue of
providing a name for the download.  Using the term "download" here is also
nice.

I know that there is also a proposal to add a FileSaver API.  I like that as
well, _but_ it is very nice to be able to simply decorate an anchor tag.  In
many cases, that will be a lot simpler for developers than using JavaScript
to construct a FileSaver.  I think it makes sense to implement both.

On the other thread, Michal Zalewski raised a concern about giving
client-side JS the power to name files.  It looks like that discussion did
not conclude, but I will note that even without the proposal here to name
the download, an attacker could still have control over the downloaded
filename.  They could either manufacture a file using the FileSystem API,
and then get a filesystem: URL to that file, or they could simply use a
server to produce an URL with a C-D header of their choosing.  It seems like
we are well past the point of trying to limit a web page authors ability to
influence the downloaded filename.  Fortunately, however, user agents can
protect the user from potentially harmful downloads.  Chrome for instance
asks the user to confirm the download of a EXE file before we ever write a
file to the filesystem with a .exe extension.

-Darin


From tantek at cs.stanford.edu  Thu Jul 14 13:32:15 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 13:32:15 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
Message-ID: <CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>

2011/7/14 Darin Fisher <darin at chromium.org>:
> On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>>
>> > Many websites wish to offer a file for download, even though it could
>> > potentially be viewed inline (take images, PDFs, or word documents as an
>> > example). Traditionally the only way to achieve this is to set a
>> > content-disposition header. *However, sometimes it is not possible for
>> the
>> >
>>
>> This has been raised a couple times:
>>
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>>
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
>> was derailed partway through)
>>
>> I've wanted this several times and I'm strongly in favor of it.
>>
>
> Yes, it seems very useful.

Indeed, and has been pointed out, already specified (since 2005) and
implemented as well for HTML:

http://microformats.org/wiki/rel-enclosure

re-using the "enclosure" term from the Atom format (thus minimal bikeshedding)


>> After mulling this over with some application developers who are trying to
>> > use this functionality, it seems like adding a "rel" attribute to the <a>
>> > tag would be a straightforward, minimally invasive way to address this
>> use
>> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
>> >
>>
>> This isn't enough; the filename needs to be overridable as well, as it is
>> with Content-Disposition. ?My recommendation has been:
>>
>> <a href=image.jpg download>
>> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>
>>
>> where the first is equivalent to Content-Disposition: attachment, and the
>> second is equivalent to Content-Disposition: attachment;
>> filename=picture.jpg.
>>
>>
> This is an interesting variation! ?I like that it addresses the issue of
> providing a name for the download. ?Using the term "download" here is also
> nice.

Agreed.

I've captured the suggestion on a brainstorming page:

http://microformats.org/wiki/rel-enclosure-brainstorming

Feel free to contribute or iterate.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5


From darin at chromium.org  Thu Jul 14 13:46:38 2011
From: darin at chromium.org (Darin Fisher)
Date: Thu, 14 Jul 2011 13:46:38 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
Message-ID: <CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:32 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> 2011/7/14 Darin Fisher <darin at chromium.org>:
> > On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
> >
> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>
> >>
> >> > Many websites wish to offer a file for download, even though it could
> >> > potentially be viewed inline (take images, PDFs, or word documents as
> an
> >> > example). Traditionally the only way to achieve this is to set a
> >> > content-disposition header. *However, sometimes it is not possible for
> >> the
> >> >
> >>
> >> This has been raised a couple times:
> >>
> >>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
> >>
> >>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
> >> was derailed partway through)
> >>
> >> I've wanted this several times and I'm strongly in favor of it.
> >>
> >
> > Yes, it seems very useful.
>
> Indeed, and has been pointed out, already specified (since 2005) and
> implemented as well for HTML:
>
> http://microformats.org/wiki/rel-enclosure
>
> re-using the "enclosure" term from the Atom format (thus minimal
> bikeshedding)
>
>
> >> After mulling this over with some application developers who are trying
> to
> >> > use this functionality, it seems like adding a "rel" attribute to the
> <a>
> >> > tag would be a straightforward, minimally invasive way to address this
> >> use
> >> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> >> >
> >>
> >> This isn't enough; the filename needs to be overridable as well, as it
> is
> >> with Content-Disposition.  My recommendation has been:
> >>
> >> <a href=image.jpg download>
> >> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg
> download=picture.jpg>
> >>
> >> where the first is equivalent to Content-Disposition: attachment, and
> the
> >> second is equivalent to Content-Disposition: attachment;
> >> filename=picture.jpg.
> >>
> >>
> > This is an interesting variation!  I like that it addresses the issue of
> > providing a name for the download.  Using the term "download" here is
> also
> > nice.
>
> Agreed.
>
> I've captured the suggestion on a brainstorming page:
>
> http://microformats.org/wiki/rel-enclosure-brainstorming
>
> Feel free to contribute or iterate.
>
> Thanks,
>
> Tantek
>
>
Why do you feel it is important to specify rel=enclosure in addition to the
download attribute?

Thanks,
-Darin


From tantek at cs.stanford.edu  Thu Jul 14 13:48:18 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 13:48:18 -0700
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
	<9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
Message-ID: <CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>

In agreement with Jeremy, I too have found the blockquote/q cite
attribute to be nearly as ignored as the longdesc attribute, despite
having conducted talks and written tutorials about how to use the
cite="" attribute (makes me think that the non-visible-effect-URL
attributes on elements should be considered an anti-pattern, evidenced
by the fact that they (cite, longdesc, profile etc.) have all failed
to get any meaningful uptake among web developers).

On slightly a more positive note:

On Thu, Jul 14, 2011 at 12:35, Karl Dubost <karld at opera.com> wrote:
>
> Le 14 juil. 2011 ? 14:59, Kevin Marks a ?crit :
>> If I was writing a detector for this pattern, <a> followed by a colon
>> and ?<blockquote> would do it pretty reliably...
>
> yup unfortunately there are also many cases where you have more names in an introducing paragraph. It is happening when I'm writing, and the issue is then to tie the right person with the right blockquote/q
>
> I like the pattern id/for pattern of forms. We could imagine
>
> <p>
> <span for="quoteA" class="author">Sir John Typo</span>
> has written plenty of a wonderful thing
> in <cite for="quoteA">Amazing title</cite> very similar to those in
> <span for="quoteB" class="author">Susan Spellchecker</span>'s writings
>
> <blockquote id="quoteA">
> [?]
> </blockquote>
>
> compare to <cite for="quoteB">Amazing title</cite>
>
> <blockquote id="quoteB">
> </blockquote>

I really like this pattern.

<label for="input-id"> is a known working and in use pattern.

Thus I feel much more confident advocating use of the parallel:

<cite for="quote-id">

With one concern - multiple blockquotes. Thus the for attribute should
be a space separated set of IDREFs. E.g. this pattern (often seen on
blog posts analyzing articles and other blog posts)

<cite for="quote1 quote2">Some quoted title of a work</cite>
<blockquote id="quote1"> one quotation </blockquote>
<p> .. intervening commentary .. </p>
<blockquote id="quote2"> another quotation </blockquote>
<p> .. more commentary ..</p>

Though that example is vulnerable to bad copy/paste errors. It
requires two markup updates (done consistently) for each copy/paste: a
new id on each new blockquote, and having to update the original cite
element for each additional blockquote.


That example redone with today's cite attribute would be:

<cite id="cite1">Some quoted title of a work</cite>
<blockquote cite="#cite1"> one quotation </blockquote>
<p> .. intervening commentary .. </p>
<blockquote cite="#cite1"> another quotation </blockquote>
<p> .. more commentary ..</p>

which is then much more copy/paste proof if/when the author adds more
blockquotes from the same source that they're commenting on - fewer
bits of markup (none) to update.

So I don't know. Perhaps <cite for> handles the 80/20 one cite / one
quote case better and that's good enough to add it, and then perhaps
we keep the old cite="" attribute for the one cite / multiple quote
case?

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5


From tantek at cs.stanford.edu  Thu Jul 14 13:52:11 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 13:52:11 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>
Message-ID: <CAOACb=LGnySWvH0G+Qf4NC0yMP-_ovxS2_uthHk413LH+QJHow@mail.gmail.com>

On Thu, Jul 14, 2011 at 13:46, Darin Fisher <darin at chromium.org> wrote:
>
>
> On Thu, Jul 14, 2011 at 1:32 PM, Tantek ?elik <tantek at cs.stanford.edu>
> wrote:
>>
>> 2011/7/14 Darin Fisher <darin at chromium.org>:
>> > On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
>> >
>> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>> >>
>> >> > Many websites wish to offer a file for download, even though it could
>> >> > potentially be viewed inline (take images, PDFs, or word documents as
>> >> > an
>> >> > example). Traditionally the only way to achieve this is to set a
>> >> > content-disposition header. *However, sometimes it is not possible
>> >> > for
>> >> the
>> >> >
>> >>
>> >> This has been raised a couple times:
>> >>
>> >>
>> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>> >>
>> >>
>> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
>> >> was derailed partway through)
>> >>
>> >> I've wanted this several times and I'm strongly in favor of it.
>> >>
>> >
>> > Yes, it seems very useful.
>>
>> Indeed, and has been pointed out, already specified (since 2005) and
>> implemented as well for HTML:
>>
>> http://microformats.org/wiki/rel-enclosure
>>
>> re-using the "enclosure" term from the Atom format (thus minimal
>> bikeshedding)
>>
>>
>> >> After mulling this over with some application developers who are trying
>> >> to
>> >> > use this functionality, it seems like adding a "rel" attribute to the
>> >> > <a>
>> >> > tag would be a straightforward, minimally invasive way to address
>> >> > this
>> >> use
>> >> > case. <a rel=attachment href=blah.pdf> would indicate that the
>> >> > browser
>> >> >
>> >>
>> >> This isn't enough; the filename needs to be overridable as well, as it
>> >> is
>> >> with Content-Disposition. ?My recommendation has been:
>> >>
>> >> <a href=image.jpg download>
>> >> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg
>> >> download=picture.jpg>
>> >>
>> >> where the first is equivalent to Content-Disposition: attachment, and
>> >> the
>> >> second is equivalent to Content-Disposition: attachment;
>> >> filename=picture.jpg.
>> >>
>> >>
>> > This is an interesting variation! ?I like that it addresses the issue of
>> > providing a name for the download. ?Using the term "download" here is
>> > also
>> > nice.
>>
>> Agreed.
>>
>> I've captured the suggestion on a brainstorming page:
>>
>> http://microformats.org/wiki/rel-enclosure-brainstorming
>>
>> Feel free to contribute or iterate.
>>
>> Thanks,
>>
>> Tantek
>>
>
> Why do you feel it is important to specify rel=enclosure in addition to the
> download attribute?
> Thanks,
> -Darin

Other way around.

rel="enclosure" is sufficient for today's use cases because authors
simply name the file accordingly on their server and then
implementations simply use the last segment of the URL as the filename
- presto 80/20 case solved (and solved 6 years ago with no
modification needed to HTML for it to be valid).

Having to specify a "download" attribute that reflects a filename
different from the last segment of the URL is the minority case, but
still sufficient to justify addition of the attribute.

Also the empty download attribute doesn't work as it is supposed to be
equivalent to download="download" which would simply name the file
"download" which is unlikely what author or user want.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5


From glenn at zewt.org  Thu Jul 14 13:53:19 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 14 Jul 2011 16:53:19 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
Message-ID: <CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>

2011/7/14 Darin Fisher <darin at chromium.org>

> I know that there is also a proposal to add a FileSaver API.  I like that
> as well, _but_ it is very nice to be able to simply decorate an anchor tag.
>  In many cases, that will be a lot simpler for developers than using
> JavaScript to construct a FileSaver.  I think it makes sense to implement
> both.
>

FileSaver is useful in its own right, but it's not a great fit for this.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html

That reminds me of something download=filename can't do: assign a filename
while leaving it inline, so "save as" and other operations can have a
specified filename.  That would require two separate properties.  One case
I've come across is <img>, where I want to display an image, but provide a
different filename for save-as.  Separating the filename would allow this to
be applied generically both links and inline resources: <img
src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>.

In that case, rel=enclosure would probably make sense.

On the other thread, Michal Zalewski raised a concern about giving
> client-side JS the power to name files.
>

That subthread just seemed to be asking whether browsers should implement
Content-Disposition, which didn't seem relevant--they already have, for
years.

Separately, there was a security question raised about the ability to serve
a file off of a third-party site with a different filename than was
intended.  For example, uploading a file which is both an executable trojan
and a valid JPEG to an image hosting site, and linking to it externally,
overriding its filename to .EXE.  The question there isn't about being able
to serve executables--you can always do that--but being able to serve
executables that appear to be from the image hosting site.  Arguably, it
could 1: cause users to trust the file because it appears to be from a site
they recognize, or 2: cause the site to be blamed for the trojan.

I mention it so people don't have to scour the previous threads for it, but
I think it's uncompelling.  It just seems like something UI designers would
need to take into consideration.  (In my opinion, the trust and blame for
saving a file to disk should be applied to the host *linking* the file, and
not from the site hosting the file, which makes the above irrelevant.)

-- 
Glenn Maynard


From darin at chromium.org  Thu Jul 14 13:58:32 2011
From: darin at chromium.org (Darin Fisher)
Date: Thu, 14 Jul 2011 13:58:32 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
Message-ID: <CAP0-QpsBZu_xWY3eELnTDcKUVrforC+_0+nbZ3RQ4NCmMQHawA@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Darin Fisher <darin at chromium.org>
>
>> I know that there is also a proposal to add a FileSaver API.  I like that
>> as well, _but_ it is very nice to be able to simply decorate an anchor tag.
>>  In many cases, that will be a lot simpler for developers than using
>> JavaScript to construct a FileSaver.  I think it makes sense to implement
>> both.
>>
>
> FileSaver is useful in its own right, but it's not a great fit for this.
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html
>
> That reminds me of something download=filename can't do: assign a filename
> while leaving it inline, so "save as" and other operations can have a
> specified filename.  That would require two separate properties.  One case
> I've come across is <img>, where I want to display an image, but provide a
> different filename for save-as.  Separating the filename would allow this to
> be applied generically both links and inline resources: <img
> src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>.
>
> In that case, rel=enclosure would probably make sense.
>

Yeah, that makes a lot of sense.  I'm fine with using rel=enclosure too.


>
> On the other thread, Michal Zalewski raised a concern about giving
>> client-side JS the power to name files.
>>
>
> That subthread just seemed to be asking whether browsers should implement
> Content-Disposition, which didn't seem relevant--they already have, for
> years.
>
> Separately, there was a security question raised about the ability to serve
> a file off of a third-party site with a different filename than was
> intended.  For example, uploading a file which is both an executable trojan
> and a valid JPEG to an image hosting site, and linking to it externally,
> overriding its filename to .EXE.  The question there isn't about being able
> to serve executables--you can always do that--but being able to serve
> executables that appear to be from the image hosting site.  Arguably, it
> could 1: cause users to trust the file because it appears to be from a site
> they recognize, or 2: cause the site to be blamed for the trojan.
>
> I mention it so people don't have to scour the previous threads for it, but
> I think it's uncompelling.  It just seems like something UI designers would
> need to take into consideration.  (In my opinion, the trust and blame for
> saving a file to disk should be applied to the host *linking* the file, and
> not from the site hosting the file, which makes the above irrelevant.)
>
>
Agreed.  I suspect that users will associate a download with whatever host
they see in the location bar.

-Darin


From jackalmage at gmail.com  Thu Jul 14 13:59:35 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 13:59:35 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
Message-ID: <CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:32 PM, Tantek ?elik <tantek at cs.stanford.edu> wrote:
> Indeed, and has been pointed out, already specified (since 2005) and
> implemented as well for HTML:
>
> http://microformats.org/wiki/rel-enclosure
>
> re-using the "enclosure" term from the Atom format (thus minimal bikeshedding)

"enclosure" is a completely opaque name.  I have no idea how it is
meant to refer to "download the linked resource instead of navigating
to it".  If I think about it in terms of Atom I can *kinda* imagine
it, but it feels like a bad term there, and it would be an even worse
term in HTML.

A boolean @download attribute is much clearer and more direct.  If
you're using @download to name the file as well, then adding a @rel
value is unneeded.

~TJ


From karld at opera.com  Thu Jul 14 14:18:00 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 17:18:00 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
	<9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
	<CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
Message-ID: <19BA895C-998E-492A-A356-0F8BC9227E49@opera.com>


Le 14 juil. 2011 ? 16:48, Tantek ?elik a ?crit :
> cite="" attribute (makes me think that the non-visible-effect-URL
> attributes on elements

Yup. :) and there are ways to improve what the browser doesn't do :) 
(though I really think the browser should)
I made a prototype for this

https://github.com/karlcow/QuoteLink
https://addons.opera.com/addons/extensions/details/quotelink/

any suggestions for improving are welcome.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From karld at opera.com  Thu Jul 14 14:25:29 2011
From: karld at opera.com (Karl Dubost)
Date: Thu, 14 Jul 2011 17:25:29 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <2C226A9A-E24F-49E6-8341-C1B378361FFF@opera.com>


Le 14 juil. 2011 ? 14:45, Ian Fette (????????) a ?crit :
> <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.

A random thought just occured to me (maybe dumb)
But is it a relation qualifier or in fact a target?
In http://dev.w3.org/html5/spec/browsers.html#valid-browsing-context-name-or-keyword

    A valid browsing context name or keyword is any string
    that is either a valid browsing context name or that is
    an ASCII case-insensitive match for one of: _blank,
    _self, _parent, or _top.
                    
what about adding 

<a href="foo.pdf" target="_download">Save a Tree, Eat a beaver</a>


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From jackalmage at gmail.com  Thu Jul 14 14:35:40 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 14:35:40 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAOACb=LGnySWvH0G+Qf4NC0yMP-_ovxS2_uthHk413LH+QJHow@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAP0-QpvRMzPcCbwJq_qg-QyPqOeVbdzhL=Q4Y05_TNOHxRgbUg@mail.gmail.com>
	<CAOACb=LGnySWvH0G+Qf4NC0yMP-_ovxS2_uthHk413LH+QJHow@mail.gmail.com>
Message-ID: <CAAWBYDC=93kHX88LTNQB1gqqc4NTPpZZ1UcBwqQxdOeb6NBqow@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:52 PM, Tantek ?elik <tantek at cs.stanford.edu> wrote:
> Also the empty download attribute doesn't work as it is supposed to be
> equivalent to download="download" which would simply name the file
> "download" which is unlikely what author or user want.

This is incorrect.  If you omit an attribute's value it becomes the
empty string.  See this testcase:

<!DOCTYPE html>
<body foo>
</body>
<script>
alert(document.body.getAttribute('foo'));
</script>

(In SGML languages, omitting an attribute's value was *actually*
omitting the attribute name, and the name was inferred from looking in
the DTD for what attribute had that as a possible enumerated value.
This is why XHTML1 requires boolean attributes to be written as
foo='foo'.  XHTML5, though, prefers the form foo='', as that makes the
value identical to what it would be as an HTML boolean attribute.)

~TJ


From ian at hixie.ch  Thu Jul 14 14:36:36 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Jul 2011 21:36:36 +0000 (UTC)
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>

On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
>
> Some in the microformats community have been making good use of the 
> <time> element, e.g. for publishing hCalendar, and implementing 
> consuming/converting hCalendar [1] with good success.
> [1] http://microformats.org/wiki/h2vx#HTML5_support
> 
> It would be great if the <time> element could support expressing 
> durations as well for the use cases as needed by the hMedia and hAudio 
> microformats as well as other use-cases (Wikipedia, IMDB).
> 
> Simple proposal, examples, faq, discussion (please contribute)
> 
> http://wiki.whatwg.org/wiki/Time_element#duration

I haven't studied the above yet, but I just wanted to bring up a trial 
balloon for a possible alternative solution: drop <time> and replace it 
with a generic solution.

There are several use cases for <time>:

A. Easier styling of dates and times from CSS.

B. A way to mark up the publication date/time for an article (e.g. for 
conversion to Atom).

C. A way to mark up machine-readable times and dates for use in 
Microformats or microdata.

Use cases A and B do not seem to have much traction.

Use case C applies to more than just dates, and the lack of solution for 
stuff outside dates and times is being problematic to many communities.

Proposal: we dump use cases A and B, and pivot <time> on use case C, 
changing it to <data> and making it like the <abbr> for machine-readable 
data, primarily for use by Microformats and HTML's microdata feature.


(I've also filed this as a bug here:
   http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240
I generally prefer to only have issues discussed either in e-mail or in a 
bug, but Tantek informs me that for technical reasons he can't discuss 
this on the bug and his input is more important to me than convention, 
thus my bringing this up here again!)

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

From jackalmage at gmail.com  Thu Jul 14 14:44:15 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 14:44:15 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
Message-ID: <CAAWBYDCEJcie1aiS=6syQFQxGmM6+M1NT9LsbuP2aO6AAKgQVQ@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard <glenn at zewt.org> wrote:
> That reminds me of something download=filename can't do: assign a filename
> while leaving it inline, so "save as" and other operations can have a
> specified filename. ?That would require two separate properties. ?One case
> I've come across is <img>, where I want to display an image, but provide a
> different filename for save-as. ?Separating the filename would allow this to
> be applied generically both links and inline resources: <img
> src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>.

Optimizing for the user choosing to right-click=>Save seems like a
much more niche case than linking to a file that should be downloaded.

Plus, you could address it by just wrapping the <img> in an <a>:

<a href=uglyurl.jpg download=prettyurl.jpg><img src=uglyurl.jpg></a>

Alternately, there's nothing saying that @download can't be useful on
<img> directly.  It would still be embedded normally, but @download
would set the download filename the same way that it does on <a>.  (It
seems more obvious to me that the download filename is in @download
than @filename - the latter seems likely to confused people into
thinking that it's involved somehow in linking to the image, or that
you're required to set the filename on all images).

~TJ


From jackalmage at gmail.com  Thu Jul 14 14:51:37 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 14 Jul 2011 14:51:37 -0700
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>

On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
>> Some in the microformats community have been making good use of the
>> <time> element, e.g. for publishing hCalendar, and implementing
>> consuming/converting hCalendar [1] with good success.
>> [1] http://microformats.org/wiki/h2vx#HTML5_support
>>
>> It would be great if the <time> element could support expressing
>> durations as well for the use cases as needed by the hMedia and hAudio
>> microformats as well as other use-cases (Wikipedia, IMDB).
>>
>> Simple proposal, examples, faq, discussion (please contribute)
>>
>> http://wiki.whatwg.org/wiki/Time_element#duration
>
> I haven't studied the above yet, but I just wanted to bring up a trial
> balloon for a possible alternative solution: drop <time> and replace it
> with a generic solution.
>
> There are several use cases for <time>:
>
> A. Easier styling of dates and times from CSS.
>
> B. A way to mark up the publication date/time for an article (e.g. for
> conversion to Atom).
>
> C. A way to mark up machine-readable times and dates for use in
> Microformats or microdata.
>
> Use cases A and B do not seem to have much traction.
>
> Use case C applies to more than just dates, and the lack of solution for
> stuff outside dates and times is being problematic to many communities.
>
> Proposal: we dump use cases A and B, and pivot <time> on use case C,
> changing it to <data> and making it like the <abbr> for machine-readable
> data, primarily for use by Microformats and HTML's microdata feature.

I'm fine with this, but as I expressed when this was discussed
earlier, I think this should be more explicitly aimed at Microdata,
with something like <itemdata @itemprop @data>...</itemdata>.

This makes it less immediately applicable to Microformats, but in my
opinion Microformats should switch to using Microdata as their
embedding syntax, as that would solve their "you have to write a
custom parser for each vocab" problem.

(I want to address usecase A at some point, but it's a complicated
problem that I don't have anywhere near the bandwidth for.  It doesn't
necessarily require <time>, though - <itemdata> would work just fine
if CSS specified a particular date format that the data had to be in.)

~TJ


From svartman95 at gmail.com  Thu Jul 14 14:55:32 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Thu, 14 Jul 2011 21:55:32 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <2C226A9A-E24F-49E6-8341-C1B378361FFF@opera.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<2C226A9A-E24F-49E6-8341-C1B378361FFF@opera.com>
Message-ID: <CAOKKrgOqcVg2rh-4r0Rz0g6zd4nCeBTo=bAv_k8h3=yb8EpEmQ@mail.gmail.com>

On 7/14/11, Karl Dubost <karld at opera.com> wrote:
> what about adding
>
> <a href="foo.pdf" target="_download">Save a Tree, Eat a beaver</a>
>
This seems like the best solution to me. A filename hint has two use
cases: a suggestion for a local identifier, and providing a filename
extension for systems that use them to identify file types with
incomplete or nonexistent /etc/mime.type media type mappings. I'll
only name so many pictures "pic.jpg", so I suggest using the
descriptive (and thus verbose) value of the title attribute. The worst
problem will be encoding the name on filesystems such as FAT.

<a href="//samplecdn.example/pix/2011/7/14/party/cake"
title="S?kkula?ikaka me? ?s" target="_download">Afm?liskaka m?n</a>


From ian at hixie.ch  Thu Jul 14 15:21:58 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Jul 2011 22:21:58 +0000 (UTC)
Subject: [whatwg] Styling <details>
In-Reply-To: <4D9BBA29.3040107@lachy.id.au>
References: <4D9BBA29.3040107@lachy.id.au>
Message-ID: <Pine.LNX.4.64.1107142204470.2079@ps20323.dreamhostps.com>


(This isn't the final reply on this thread, but I thought I should give a 
heads-up as to the general direction I am expecting us to go in here.)

On Wed, 6 Apr 2011, Lachlan Hunt wrote:
>
>   We've been experimenting with the styling of the details element, 
> trying to figure out the most sensible way style it.  We have tried to 
> find a solution that behaves the way authors expect, provides for easy 
> restyling by authors and avoiding the troubles associated with magic 
> styles that can't be expressed in CSS.
> 
> The rendering section of the spec is currently very inadequate and does 
> not describe accurate styles.  Also, the sample XBL binding given in the 
> XBL 2.0 draft is also inadequate for a number of reasons.

I think the long term solution here is some sort of widget definition 
binding language like XBL. I don't think it makes sense to do it purely in 
CSS. Discolsure widgets have all kinds of subtle behaviours like animation 
during disclosure, hover effects on the triangle, etc. Some systems use a 
"More..." or "Details..." button, some use a triangle, some use +/-.

On the short term, I would recommend using the 'icon' property to allow 
authors to override the icon.

I agree that what the spec says is currently inadequate, but without a 
binding language, I don't think it makes sense to spend time trying to 
improve it, since any improvement would be a stop-gap measure.

The same applies to pretty much all the other form controls.

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


From glenn at zewt.org  Thu Jul 14 15:45:35 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 14 Jul 2011 18:45:35 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAWBYDCEJcie1aiS=6syQFQxGmM6+M1NT9LsbuP2aO6AAKgQVQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CABirCh86Hx+4ZmjANsMaNitojF55wTu0SXr-Hr16bYL2f=44vw@mail.gmail.com>
	<CAAWBYDCEJcie1aiS=6syQFQxGmM6+M1NT9LsbuP2aO6AAKgQVQ@mail.gmail.com>
Message-ID: <CABirCh-bOafsmhoXfTgU2ZuFVqt58zWjm4gxtUmqy4FR8FPmFA@mail.gmail.com>

On Thu, Jul 14, 2011 at 5:44 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

>  Optimizing for the user choosing to right-click=>Save seems like a
> much more niche case than linking to a file that should be downloaded.
>
> Plus, you could address it by just wrapping the <img> in an <a>:
>
> <a href=uglyurl.jpg download=prettyurl.jpg><img src=uglyurl.jpg></a>
>

I don't want to turn my images into links--and in some cases the images are
already links to something else, or use click for other site UI.

A similar and probably more common use case is links to files which can be
viewed usefully in the browser, and are also often saved to disk; very
frequently PDFs.  Using <a href=ugly.pdf download=pretty.pdf> would obstruct
users who want to view the link in the browser.

I don't feel very strongly about this, and download=filename is clean and
straightforward, but we should at least consider the use cases of specifying
a filename without implying C-D: attachment.

-- 
Glenn Maynard


From tantek at cs.stanford.edu  Thu Jul 14 18:24:12 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 18:24:12 -0700
Subject: [whatwg] Styling <details>
In-Reply-To: <Pine.LNX.4.64.1107142204470.2079@ps20323.dreamhostps.com>
References: <4D9BBA29.3040107@lachy.id.au>
	<Pine.LNX.4.64.1107142204470.2079@ps20323.dreamhostps.com>
Message-ID: <CAOACb=Kqj_x-sxcvfKx06qoNMwg2eRoNfUC8bWcA82qUL90buA@mail.gmail.com>

On Thu, Jul 14, 2011 at 15:21, Ian Hickson <ian at hixie.ch> wrote:
>
> (This isn't the final reply on this thread, but I thought I should give a
> heads-up as to the general direction I am expecting us to go in here.)
>
> On Wed, 6 Apr 2011, Lachlan Hunt wrote:
>>
>> ? We've been experimenting with the styling of the details element,
>> trying to figure out the most sensible way style it. ?We have tried to
>> find a solution that behaves the way authors expect, provides for easy
>> restyling by authors and avoiding the troubles associated with magic
>> styles that can't be expressed in CSS.
>>
>> The rendering section of the spec is currently very inadequate and does
>> not describe accurate styles. ?Also, the sample XBL binding given in the
>> XBL 2.0 draft is also inadequate for a number of reasons.
>
> I think the long term solution here is some sort of widget definition
> binding language like XBL. I don't think it makes sense to do it purely in
> CSS. Discolsure widgets have all kinds of subtle behaviours like animation
> during disclosure, hover effects on the triangle, etc. Some systems use a
> "More..." or "Details..." button, some use a triangle, some use +/-.
>
> On the short term, I would recommend using the 'icon' property to allow
> authors to override the icon.

Agreed.

FYI: http://dev.w3.org/csswg/css3-ui/#icon

Feel free to follow-up feedback on that to www-style at w3.org.

> I agree that what the spec says is currently inadequate, but without a
> binding language, I don't think it makes sense to spend time trying to
> improve it, since any improvement would be a stop-gap measure.
>
> The same applies to pretty much all the other form controls.

Also agreed.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5


From tantek at cs.stanford.edu  Thu Jul 14 19:17:07 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu, 14 Jul 2011 19:17:07 -0700
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
	<CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>
Message-ID: <CAOACb=+KUk8fa9P8Zx_WSwoT-rfDth05-1pcFiET8WnS6-24Yw@mail.gmail.com>

On Thu, Jul 14, 2011 at 14:51, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
>>> Some in the microformats community have been making good use of the
>>> <time> element, e.g. for publishing hCalendar, and implementing
>>> consuming/converting hCalendar [1] with good success.
>>> [1] http://microformats.org/wiki/h2vx#HTML5_support
>>>
>>> It would be great if the <time> element could support expressing
>>> durations as well for the use cases as needed by the hMedia and hAudio
>>> microformats as well as other use-cases (Wikipedia, IMDB).
>>>
>>> Simple proposal, examples, faq, discussion (please contribute)
>>>
>>> http://wiki.whatwg.org/wiki/Time_element#duration
>>
>> I haven't studied the above yet, but I just wanted to bring up a trial
>> balloon for a possible alternative solution: drop <time> and replace it
>> with a generic solution.
>>
>> There are several use cases for <time>:
>>
>> A. Easier styling of dates and times from CSS.
>>
>> B. A way to mark up the publication date/time for an article (e.g. for
>> conversion to Atom).
>>
>> C. A way to mark up machine-readable times and dates for use in
>> Microformats or microdata.
>>
>> Use cases A and B do not seem to have much traction.


Use case A hasn't been a priority for anyone in the CSSWG no.

However, use case B is being incrementally adopted, both as specified
for pubdate, e.g.:
* https://singpolyma.net/blog/
* http://adactio.com/journal/

and using <time> with the hAtom microformat in particular rather than
pubdate (thus avoiding DRY violations with the help of the
microformats value class pattern)
* http://tantek.com/

There's probably more out there - but there are a few real world
example you can try out.


>> Use case C applies to more than just dates, and the lack of solution for
>> stuff outside dates and times is being problematic to many communities.

True. However the primary real-world use case of C has been hCalendar events.
Publishing example at http://tantek.com/
And consuming/parsing implementation: http://dev.h2vx.com/ics/

I'd say use cases "more than just dates" require open documentation on
a public wiki, otherwise we're designing from "theoretical needs"
which are pretty low priority IIRC.


>> Proposal: we dump use cases A and B, and pivot <time> on use case C,
>> changing it to <data> and making it like the <abbr> for machine-readable
>> data, primarily for use by Microformats and HTML's microdata feature.
>
> I'm fine with this,

I'm not and I think it's a mistake because <data> (and the <abbr>
pattern before that when liberally applied) leads to encouraging lazy
double-encoding of data which is a DRY violation (and thus bad for
{meta}data accuracy/quality over time).

Instead I think the <time> element approach is correct.

First prove the need for double-encoding on a case by case basis, and
then create an element for each proven data-type use-case.

E.g. next on this list IMHO would be a  <number> element for example,
since it's clear from some of the examples where quantities or numbers
are involved - e.g. the hReview-aggregate microformat, that publishers
use human/locale/design-specific numbers

e.g.
<number value="10000">10,000</number>
<number value="10000">10.000</number>
<number value="10000">10k</number>

etc.

Obvious FAQ:

"Won't we end up with a billion new tags?" (actual expression from
IRC, not deliberate strawman)

No we won't.

No matter how you slice it there will be a very limited number of
specific data types that require dual representation (evidence: all
existing schema languages have a small fixed number of atomic scalar
types).

I would be surprised if more than half dozen or so data-type-specific
elements were added ever for this, I could be mistaken, but I'd rather
be proven wrong by evidence demonstrating 5-6 are not enough, than
overgeneralizing now.


> but as I expressed when this was discussed
> earlier, I think this should be more explicitly aimed at Microdata,
> with something like <itemdata @itemprop @data>...</itemdata>.
> This makes it less immediately applicable to Microformats...

A @data *global* attribute would work equally well for Microdata,
microformats, and RDFa, and yes would be preferred over a <data>
element, so no need to worry there.


> but in my
> opinion Microformats should switch to using Microdata as their
> embedding syntax, as that would solve their "you have to write a
> custom parser for each vocab" problem.

Simpler and more incremental (based on existing practice) solution to
the customize-parser-per-microformat-problem already under way here:

http://microformats.org/wiki/microformats-2

Certainly not as fully specified as microdata yet, but I expect all
the same RDF/JSON generation algorithms will work - and the syntax
will be simpler for typical developers and typical web pages.


> (I want to address usecase A at some point, but it's a complicated
> problem that I don't have anywhere near the bandwidth for. ?It doesn't
> necessarily require <time>, though - <itemdata> would work just fine
> if CSS specified a particular date format that the data had to be in.)

Agreed on all counts. I proposed a language/locale specific
"date-style" property (akin to "list-style-type") in a CSS WG meeting
years ago (2003 or 2004 I think) but it didn't generate sufficient
interest at the time (nor since).

Thanks,

Tantek
-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5


From brucel at opera.com  Fri Jul 15 01:07:32 2011
From: brucel at opera.com (Bruce Lawson)
Date: Fri, 15 Jul 2011 09:07:32 +0100
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <CAOACb=+KUk8fa9P8Zx_WSwoT-rfDth05-1pcFiET8WnS6-24Yw@mail.gmail.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
	<CAAWBYDBt0RUHr4mFeu6nJkVQUnxukv5JOquqknHAdmNeseN3Bg@mail.gmail.com>
	<CAOACb=+KUk8fa9P8Zx_WSwoT-rfDth05-1pcFiET8WnS6-24Yw@mail.gmail.com>
Message-ID: <op.vynh6uveh8on37@bruce-pc>

On Fri, 15 Jul 2011 03:17:07 +0100, Tantek ?elik <tantek at cs.stanford.edu>  
wrote:

> On Thu, Jul 14, 2011 at 14:51, Tab Atkins Jr. <jackalmage at gmail.com>  
> wrote:
>> On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:

>>>
>>> I haven't studied the above yet, but I just wanted to bring up a trial
>>> balloon for a possible alternative solution: drop <time> and replace it
>>> with a generic solution.
>>>
>>> There are several use cases for <time>:
>>>
>>> A. Easier styling of dates and times from CSS.
>>>
>>> B. A way to mark up the publication date/time for an article (e.g. for
>>> conversion to Atom).
>>>
>>> C. A way to mark up machine-readable times and dates for use in
>>> Microformats or microdata.
>>>
>>> Use cases A and B do not seem to have much traction.

I think it's too early to tell whether there is "traction". I wonder  
whether any of the new semantics (article, nav, section, header etc) have  
much traction yet, simply because they don't yet have many obvious  
"consumers" - eg, browsers, crawlers, search engines [as far as we know]  
aren't making use of them yet. Also, developers are still understandably  
getting used to the more whizzbang aspects of HTML like canvas, video etc.

>
>>> Proposal: we dump use cases A and B, and pivot <time> on use case C,
>>> changing it to <data> and making it like the <abbr> for  
>>> machine-readable
>>> data, primarily for use by Microformats and HTML's microdata feature.

I disagree.

Opera has just begun to support <time> in Opera 11.50 (demo  
http://people.opera.com/miket/2011/5/time.html) [Disclosure: Opera is my  
employer but I'm speaking for myself here, not representing them].

We're seeing <time> used "In the wild", for example on recipes  
http://www.jennybristow.com/category/recipes/, reddit  
http://www.reddit.com/ ("submitted 5 hours ago"), http://smashsummit.com/,  
the default 2011 WordPress theme  
http://theme.wordpress.com/themes/twentyeleven/ and consequently many  
WordPress blogs

We also see schema.org encouraging the use of <time>  
http://schema.org/docs/gs.html#advanced_dates and given the importance of  
Bing, Yahoo and Google it;s fair to assume that web developers will adopt  
these patterns.

In my opinion, rather than dump <time>, we should consider changing the  
spec so the schema.org use-cases such as time periods

<time itemprop="cookTime" datetime="PT1H30M">1 1/2 hrs</time>

and "fuzzy" dates like 2011-11 for November 2011 are acceptable: there  
have been previous mails to the WG from wikipedia authors, genealogists  
and those working on museum websites stating that the utility of the  
current <time> element is diminished because of the requirement for  
precise dates which isn't always possible for historians.


-- 
Hang loose and stay groovy,

Bruce Lawson
www.brucelawson.co.uk (personal)
www.twitter.com/brucel


From julian.reschke at gmx.de  Fri Jul 15 01:08:48 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 15 Jul 2011 10:08:48 +0200
Subject: [whatwg] Iframe Sandbox Attribute - allow-plugins?
In-Reply-To: <CA+c2ei9sYhpzvMMK+nSxaLByvromXVQzCeD1so8zJ3CGRKjLUw@mail.gmail.com>
References: <CAOfGMjjOCyziLOiSgPgn3KaiWgGM_0XhW9p_LZ3bC_ABskDLCg@mail.gmail.com>
	<CAJE5ia-vbPhDXZ17VtxA9zVs5D_fCYzfniqhr+YLwVxCN4E0cQ@mail.gmail.com>
	<4E1E0654.9070206@gmx.de>
	<CAJE5ia9HxSZz7OzC_7W0M57ZFMPJUTQDw=9yiUeBmiTmaGGmvA@mail.gmail.com>
	<4E1E0A61.5070205@gmx.de>
	<op.vylecs0564w2qv@annevk-macbookpro.local>
	<CA+c2ei-MtdMNZqax5OVt+xrauJpwFt-xvAPhbr14qyOUr_01+w@mail.gmail.com>
	<4E1EA5D2.4060702@gmx.de>
	<CA+c2ei9sYhpzvMMK+nSxaLByvromXVQzCeD1so8zJ3CGRKjLUw@mail.gmail.com>
Message-ID: <4E1FF590.4070403@gmx.de>

On 2011-07-14 17:01, Jonas Sicking wrote:
> ...
> True. I would be fine with removing the plugin requirement. Or
> changing it such that it states that plugins can only be loaded if
> it's done in a manner that ensures that all other requirements are
> still fulfilled. Or just dealing with this once there actually are
> plugins and plugin APIs which could be loaded while still fulfilling
> the other requirements.
> ...

Well, the spec is in W3C LC. So if we think this requirement needs to be 
rephrased then it should be brought up as a problem.

Best regards, Julian


From jkorpela at cs.tut.fi  Fri Jul 15 07:50:00 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Fri, 15 Jul 2011 17:50:00 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E1EEAAE.3050701@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
Message-ID: <4E205398.9000905@cs.tut.fi>

14.07.2011 16:10, Bjartur Thorlacius wrote:

> ?ann fim 14.j?l 2011 11:09, skrifa?i Jukka K. Korpela:
>> 14.07.2011 13:49, Karl Dubost wrote:
>>> <blockquote cite="urn:isbn:978-2-07-07533-7">
>>> <p>Sur un p?tale de lotus, j'?crivis ces quelques vers :</p>
>>> <p>?<q>M?me si l'on vient me chercher<br/>
>>> Comment, abandonnant la ros?e<br/>
>>> De pareil lotus,<br/>
>>> Retournerai-je<br/>
>>> Dans le monde changeant et frivole ?</q> ?</p>
>>> <p>et j'envoyais ce p?tale.</p>
>>> <p class="source">
>>> <cite class="auteur">Shonagon, Sei</cite>,
>>> <cite class="titre">Notes de chevet</cite>, p.64, Unesco, NRF, 1966.</p>
>>> </blockquote>
> Yes, but for usability reasons the cite[@class=titre] should represent a
> hyperlink to the cited book.

Should it? Even when the book has no URL? If you expect urn:isbn:? to 
work anytime soon in any significant browser, you?re very optimistic.

Browsers currently treat <cite> just like <i> (except that it has a 
different name). There is no sign of advance functionality emerging. It 
does not matter how usable something is when it does not exist at all.

> Is an user agent to find a cite descendant
> of <blockquote> and make it represent a hyperlink to the cited resource
> (identified by the URI in the cite attribute of blockquote)?

That would be rather pointless.

If there is an online resource to link to, you can simply make the title 
a link to it, explicitly. Then you can also style the link to desired, 
and it will stand out as a link (unless the author styles it badly).

I forgot to mention that the ISBN number should be included visibly in 
the credits, especially because it is usually the simplest and sometimes 
the only reasonable way to identify a book unambiguously (and can be 
copied and pasted into a suitable bibliographic search form). It?s 
metadata, but metadata that need not and should not be hidden but 
presented in textual content. At most it might be included into elements 
that are not initially displayed but become available when the user so 
requests?possibly some day via the <details> element if browsers 
implement it well.

The cite attribute in <blockquote> should really be moved to the 
non-recommended part of HTML. It hardly ever serves a useful purpose, 
and it tends to mislead authors into including important information 
_only_ in the attribute, which has no browser support worth mentioning 
(despite having been in HTML for over 13 years).

>> (I don't like to nitpick on the author identification, but wouldn?t
>> <cite class="auteur" lang="jp-Latn">Sh?nagon, Sei</cite> be better?)
> I don't think author names are allowed in <cite> in HTML 5.

They aren?t, but HTML5 linters (?validators?) won?t report the issue, as 
they don?t understand the meanings of words.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From ap at webkit.org  Fri Jul 15 09:08:57 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 15 Jul 2011 09:08:57 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
Message-ID: <397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>


14.07.2011, ? 13:59, Tab Atkins Jr. ???????(?):

>> re-using the "enclosure" term from the Atom format (thus minimal bikeshedding)
> 
> "enclosure" is a completely opaque name.  I have no idea how it is
> meant to refer to "download the linked resource instead of navigating
> to it".  If I think about it in terms of Atom I can *kinda* imagine
> it, but it feels like a bad term there, and it would be an even worse
> term in HTML.
> 
> A boolean @download attribute is much clearer and more direct.  If
> you're using @download to name the file as well, then adding a @rel
> value is unneeded.


What meaning will this attribute have on a platform that simply doesn't expose the notion of a file?

I think that this attribute could be quite confusing, and it will likely become more confusing with time, as more platforms arise that have creative ways of presenting data to users. 

It also doesn't naturally help understanding that it's just poor man's Content-Disposition:attachment. From this point of view, I like Ian's original proposal (rel=attachment) more.

- WBR, Alexey Proskuryakov



From svartman95 at gmail.com  Fri Jul 15 09:44:04 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Fri, 15 Jul 2011 16:44:04 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E205398.9000905@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
Message-ID: <CAOKKrgOwzOYGPLfCDGD9z9TDeUpEs2zLL60j3pDi+05rG7JymA@mail.gmail.com>

On 7/15/11, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 14.07.2011 16:10, Bjartur Thorlacius wrote:
>> I don't think author names are allowed in <cite> in HTML 5.
>
> They aren?t, but HTML5 linters (?validators?) won?t report the issue, as
> they don?t understand the meanings of words.
That doesn't make it any more valid.


From svartman95 at gmail.com  Fri Jul 15 09:56:10 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Fri, 15 Jul 2011 16:56:10 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E205398.9000905@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
Message-ID: <CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>

On 7/15/11, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> Should it? Even when the book has no URL? If you expect urn:isbn:? to
> work anytime soon in any significant browser, you?re very optimistic.
>
Wikipedia and Amazon (among others) have all the mechanisms already.
Such ISBN handlers could even be registered by JavaScripts.

> Browsers currently treat <cite> just like <i> (except that it has a
> different name). There is no sign of advance functionality emerging. It
> does not matter how usable something is when it does not exist at all.
>
<Cite> is not nearly as useful as @cite.

> I forgot to mention that the ISBN number should be included visibly in
> the credits, especially because it is usually the simplest and sometimes
> the only reasonable way to identify a book unambiguously (and can be
> copied and pasted into a suitable bibliographic search form). It?s
So you're saying that users should rather search for the term ISBN,
select the following number, copy it, remove/add hyphens as necessary
and then paste it to a suitable bibliographic search form? Instead of
registering a suitable bibliographic search form once, and having the
user agent do the hard work in a click or two?

> metadata, but metadata that need not and should not be hidden but
> presented in textual content. At most it might be included into elements
> that are not initially displayed but become available when the user so
> requests?possibly some day via the <details> element if browsers
> implement it well.
>
But browsers need to be told that that number close to the quotation
is an ISBN. And if you always hide it in <details>, user agents may be
compelled to expand it by default, making it unusable for e.g. hiding
answers to a quiz.

> The cite attribute in <blockquote> should really be moved to the
> non-recommended part of HTML. It hardly ever serves a useful purpose,
> and it tends to mislead authors into including important information
> _only_ in the attribute, which has no browser support worth mentioning
> (despite having been in HTML for over 13 years).
>
Before you said <cite> was implemented as <i>, and your point is that
the cite attribute is useless? They're barely related, @cite contains
an URI, that an user agent might be able to use in an automated
fashion. <Cite> contains a human-readable name of a work. That'll
rarely be machine-readable.


From ifette at google.com  Fri Jul 15 10:05:53 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 10:05:53 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
Message-ID: <CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>

On Fri, Jul 15, 2011 at 9:08 AM, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> 14.07.2011, ? 13:59, Tab Atkins Jr. ???????(?):
>
> >> re-using the "enclosure" term from the Atom format (thus minimal
> bikeshedding)
> >
> > "enclosure" is a completely opaque name.  I have no idea how it is
> > meant to refer to "download the linked resource instead of navigating
> > to it".  If I think about it in terms of Atom I can *kinda* imagine
> > it, but it feels like a bad term there, and it would be an even worse
> > term in HTML.
> >
> > A boolean @download attribute is much clearer and more direct.  If
> > you're using @download to name the file as well, then adding a @rel
> > value is unneeded.
>
>
> What meaning will this attribute have on a platform that simply doesn't
> expose the notion of a file?
>

I would assume the platform would treat <a href="blah.php?id=123"
download="blah.pdf"> the same way as if it had followed a link to blah.php
and received a Content-Disposition: attachment; filename=blah.pdf header.
It's not introducing any new problems, and I would expect the behaviour to
be consistent.


>
> I think that this attribute could be quite confusing, and it will likely
> become more confusing with time, as more platforms arise that have creative
> ways of presenting data to users.
>
>
I agree we don't want to prevent creative UI in the future / platforms that
don't necessarily deal with files in the traditional way. However I don't
think this actually introduces any new problems, it just allows something
that can already be specified in server-side code to be specified in
client-side code.


> It also doesn't naturally help understanding that it's just poor man's
> Content-Disposition:attachment. From this point of view, I like Ian's
> original proposal (rel=attachment) more.
>

Yes and no - both are sort of a poor man's Content-Disposition :) The
question is whether we need to handle filename, and the proposal of
download=filename at least maps content-disposition fully and compactly.


>
> - WBR, Alexey Proskuryakov
>
>


From shwetankd at opera.com  Fri Jul 15 10:55:55 2011
From: shwetankd at opera.com (Shwetank Dixit)
Date: Fri, 15 Jul 2011 23:25:55 +0530
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
 and other feedback
In-Reply-To: <CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
	<op.vylop7byim6vpa@shwetank-dixits-macbook.local>
	<CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>
Message-ID: <op.vyn9fc1qim6vpa@shwetank-dixits-macbook.local>

On Thu, 14 Jul 2011 18:53:00 +0530, timeless <timeless at gmail.com> wrote:

> I'd expect a web app to have no idea about device camera
> specifications and thus to not be able to properly specify a flash
> duration. I don't see how such a thing is valuable.
>
> If a user is in a movie theater, or a museum, it's quite likely they
> won't notice a web app is forcing a flash. Let the user control flash
> through a useragent only or host application only mode. I believe the
> hazards of exposing flash duration outweigh any benefits. The only
> application class I know of built using control of camera flash is
> "flash-light", and that's both a hack and not guaranteed to be
> workable for all possible flash technologies.

Just like, just allowing the web app to use the camera as it is will not  
make sense, and presumably, user agents will implement a authorization by  
the user before the app gains access to the camera (something like 'This  
application requests access to the camera. Allow for now/Always  
Allow/Never Allow/Close' just like you do in geolocation right now) ...  
just like that, you could do it for flash, where the app only gains access  
to it if the user allows it. If that is the implementation, i do not think  
there would be much hazards in allowing flash access.

Apart from helping capture images/video in low light conditions, there are  
a few other use cases for flash such as the flash light thing you  
mentioned, as well as a possible S.O.S type app.

I'm fine if the consensus is that the device/user agent will handle the  
issue of flash by showing some sort of control where the user can click  
between 'flash on/off/auto'. That will cover *most* of the use cases,  
which is recording images/video in low light conditions. If so, then it  
might be good to specify that somewhere in the spec just to make things a  
bit clearer?

>
> On 7/14/11, Shwetank Dixit <shwetankd at opera.com> wrote:
>> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
>>
>>>
>>>> Another question is flash. As far as I have seen, there seems to be no
>>>> option to specify whether the camera needs to use flash or not. Is  
>>>> this
>>>> decision left up to the device? (If someone is making an app which is
>>>> just clicking a picture of the person, then it would be nice to have  
>>>> the
>>>> camera use flash in low light conditions).
>>> getUserMedia() returns a video stream, so it wouldn't use a flash.
>>
>> Wouldn't it make sense to have a provision for flash separately then? I
>> think a lot of apps would like just a picture instead of video, and in
>> those cases, flash would be required. Maybe a seperate provision in the
>> spec which defines whether to use flash, and if so, for how many
>> miliseconds. Is that doable?
>> --
>> Shwetank Dixit
>> Web Evangelist,
>> Site Compatibility / Developer Relations / Core Engineering Group
>> Member - W3C Mobile Web for Social Development (MW4D) Group
>> Member - Web Standards Project (WaSP) - International Liaison Group
>> Opera Software - www.opera.com
>>
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>
>


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/


From glenn at zewt.org  Fri Jul 15 11:24:05 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 15 Jul 2011 14:24:05 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
Message-ID: <CABirCh8kc6Pup-BMYDvKbowwpq=Otp3Xh2v0SN+8YYqOu54Q1A@mail.gmail.com>

2011/7/15 Ian Fette (????????) <ifette at google.com>

> Yes and no - both are sort of a poor man's Content-Disposition :) The
> question is whether we need to handle filename, and the proposal of
> download=filename at least maps content-disposition fully and compactly.
>

Not fully; it lacks an equivalent for "Content-Disposition: inline;
filename=file".

-- 
Glenn Maynard


From ian at hixie.ch  Fri Jul 15 11:34:07 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 18:34:07 +0000 (UTC)
Subject: [whatwg] Geolocation - Browser usability issues with regards to
 asking user permission
In-Reply-To: <4D9F03D5.6020407@opera.com>
References: <BANLkTik3cvtph_w0hJ9GqYWj-kXpUBBhKQ@mail.gmail.com>
	<BANLkTimh8OKy6GK7YMT1yYpm=M0UPdvG7A@mail.gmail.com>
	<4D9F03D5.6020407@opera.com>
Message-ID: <Pine.LNX.4.64.1107142232160.2079@ps20323.dreamhostps.com>

On Wed, 6 Apr 2011, Andrew de Andrade wrote:
>
> Depending on the browser and device, permission will be asked either in 
> a bar across the top of the browser (Firefox and Chrome on the desktop) 
> or with a modal dialog (Safari on the desktop and on the iPhone). [...]
> 
> As the creator of a site that uses geolocation, these two different 
> implementations of the permissions dialog concerns me. In my tests with 
> users, I've noticed that with Firefox and Chrome, many users don't 
> notice the bar across the top and thus features of the web application 
> end up crippled because the app doesn't have access to the user's 
> location and this degrades the user experience.

As with all user interface choices browser vendors have to make, some work 
better than others. Different goals can result in different choices, too; 
for example, it might be the goal of one user agent to make it clear to 
the user that they should share their location, while another user agent 
might decide that it's better to the user have to explicitly look for a 
way to share their location, since then they won't do it by mistake.


> [Proposal:]
> 2) The HTML5 specification defines how browsers should implement this 
> consistently --> either a bar across the top OR modal dialog box, but 
> not both.

It's user interface: we're not going to specify it. This is the kind of 
thing browsers can compete on.

In any case, it's impractical: If we said it should be a non-modal 
graphical bar, how would a browser that doesn't have a screen but instead 
reads everything out using speech synthesis do it? If we said it had to be 
a red icon, what about browsers targeting cultures where the colour "red" 
is considered offensive? If we said that the user agent should offer the 
option to give the user's location or no location, what about users that 
want to lie about their location? There are just too many possible 
variables here to define the UI, even if we wanted to.


> 3) Each browser chooses their default interface approach (bar or modal 
> dialog), but the Geolocation API specification allows for the webapp 
> developer to override this default.

This doesn't work because those options might not be available in the 
first place. What if the operating system the browser is running on 
doesn't have the concept of a modal dialog? What if it's a line-driven 
text browser, with no concept of a non-modal alert?


> Those apps for which location is essencial for the user experience can 
> choose to always display a modal dialog box before the user proceeds to 
> use the webapp.

What if the user never wants a dialog?


On Wed, 6 Apr 2011, Peter Kasting wrote:
> 
> If users don't notice or understand the geolocation prompts in a 
> particular browser, I think the appropriate response is to provide 
> feedback to the browser vendor that users are not successfully 
> navigating their UI.

Indeed.


On Fri, 8 Apr 2011, Rich Tibbett wrote:
> Biju wrote:
> > What I want from browser vendors is make 
> > navigator.geolocation.getCurrentPosition and 
> > navigator.geolocation.watchPosition ONLY callable from a CLICK event. 
> > I thought we all learned lesson from window.open popups
> 
> window.open is still entirely underspecified in standards when it comes 
> to its behavior in trusted vs. non-trusted click event invocation. The 
> first thing somebody would need to is document how window.open works 
> according to different modes of invocation. Then at least we would have 
> a model to be able to discuss for other similar scenarios.

The HTML spec defines this, but in a somewhat wishy-washy way intended to 
allow UAs to experiment with different constraints. Is this something that 
needs defining more precisely?

In general I haven't specified this in detail because the model of 
trusting user clicks doesn't work (due to clickjacking attacks).

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


From jonas at sicking.cc  Fri Jul 15 11:39:15 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Jul 2011 11:39:15 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
Message-ID: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>

2011/7/14 Ian Fette (????????) <ifette at google.com>:
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the
> server.*(A related example is offline apps, which may wish to provide
> the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
> After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the <a>
> tag would be a straightforward, minimally invasive way to address this use
> case. <a rel=attachment href=blah.pdf> would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.

We've discussed a different solution to the same problem at mozilla.
The solution we discussed was allowing FileSaver to in addition to
taking a blob argument, allow it to take a url argument.

One concern which was brought up was the ability to cause the user to
download a file from a third party site. I.e. this would allow
evil.com to trick the user into downloading an email from the users
webmail, or download a page from their bank which contains all their
banking information. It might be easier to then trick the user into
re-uploading the saved file to evil.com since from a user's
perspective, it looked like the file came from evil.com

Another possible attack goes something like:
1. evil.com tricks the user into downloading sensitive data from bank.com
2. evil.com then asks the user to download a html from evil.com and
open the newly downloaded file
3. the html file contains script which reads the contents from the
file downloaded from bank.com and sends it back to evil.com

Step 1 and 2 require the user to answer "yes" to a dialog displayed by
the browser. However it's well known that users very often hit
whichever button they suspect will make the dialog go away, rather
than actually read the contents of the dialog.
Step 3 again requires the user to answer "yes" to a dialog displayed
by the browser in at least some browsers. Same caveat applies though.

One very simple remedy to this would be to require CORS opt-in for
cross-site downloads. For same-site downloads no special opt-in would
be required of course.

It's also possible that it would be ok to do this without any opt-ins
since there are a good number of actions that the user has to take in
all these scenarios. Definitely something that I'd be ok with
discussing with our security team.

Tentatively I would feel safer with the CORS option though. And again,
for same-site downloads this isn't a problem at all, but I suspect
that in many cases the file to be downloaded is hosted on a separate
server.

Oh, and I don't have strong opinions at this time on if rel=attachment
or FileSaver or both should be the way to trigger this functionality.

/ Jonas


From ifette at google.com  Fri Jul 15 11:40:27 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 11:40:27 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh8kc6Pup-BMYDvKbowwpq=Otp3Xh2v0SN+8YYqOu54Q1A@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
	<CABirCh8kc6Pup-BMYDvKbowwpq=Otp3Xh2v0SN+8YYqOu54Q1A@mail.gmail.com>
Message-ID: <CAF4kx8cDgGevMoXXCiyvTMsg26Gy_T6fTbBmjL+n=X9-U+bQbw@mail.gmail.com>

On Fri, Jul 15, 2011 at 11:24 AM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/15 Ian Fette (????????) <ifette at google.com>
>
> Yes and no - both are sort of a poor man's Content-Disposition :) The
>> question is whether we need to handle filename, and the proposal of
>> download=filename at least maps content-disposition fully and compactly.
>>
>
> Not fully; it lacks an equivalent for "Content-Disposition: inline;
> filename=file".
>
>
Ok, not fully, but at least covering what I would view to be the important
use cases that are actually used in practice.


> --
> Glenn Maynard
>
>


From ian at hixie.ch  Fri Jul 15 11:43:25 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 18:43:25 +0000 (UTC)
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
 algorithm
In-Reply-To: <BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>

On Fri, 8 Apr 2011, Tab Atkins Jr. wrote:
>
> In the legacy color parsing algorithm 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value>, 
> steps 5 and 6 concern CSS color names - 'transparent' should raise an 
> error, and color names should be respected.  All other CSS color 
> syntaxes, though, such as the rgba() function, are just passed through 
> to the rest of the algorithm and appropriately mangled.
> 
> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we just 
> try to parse it as a CSS color.  If we succeed, we use that color.  
> Otherwise, we chunk it into the legacy parsing algorithm and do what the 
> spec says.  So, for example, <font color=rgba(255,0,0,.5)>foo</font> is 
> actually displayed as partially-transparent red instead of dark green 
> (following the algorithm mangles the string into #050).
> 
> Could we change those two steps to just say "If keyword is a valid CSS 
> color value, then return the simple color corresponding to that value."?  
> (I guess, to fully match Webkit, you need to change the definition of 
> "simple color" to take alpha into account.)

On Fri, 8 Apr 2011, Boris Zbarsky wrote:
> 
> But it does match other UAs....
> 
> Do you have web compat data here?
> 
> I would much rather stick with color parsing as defined in HTML4 modulo 
> the "not a color name, treat it as a hex color even if it doesn't start 
> with '#'" quirk than replace the "is it a color name?" test with a "does 
> it parse as a CSS color?" test.

On Wed, 13 Apr 2011, Philip Taylor wrote:
> 
> I don't know if this is relevant or useful but anyway: 
> http://philip.html5.org/data/font-colors.txt has some basic data for 
> <font color> values, http://philip.html5.org/data/bgcolors.txt for <body 
> bgcolor>. (Each line is the number of URLs that value was found on (from 
> the set from http://philip.html5.org/data/dotbot-20090424.txt), followed 
> by the XML-encoded value.)

Looks like there are values that would be affected by this change.

I've left it as-is. I think compat here is vastly more important than 
adding new capabilities, since this is only used for legacy features.

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


From jackalmage at gmail.com  Fri Jul 15 11:51:53 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 15 Jul 2011 11:51:53 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
	algorithm
In-Reply-To: <Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
	<Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>

On Fri, Jul 15, 2011 at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 8 Apr 2011, Tab Atkins Jr. wrote:
>> In the legacy color parsing algorithm
>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value>,
>> steps 5 and 6 concern CSS color names - 'transparent' should raise an
>> error, and color names should be respected. ?All other CSS color
>> syntaxes, though, such as the rgba() function, are just passed through
>> to the rest of the algorithm and appropriately mangled.
>>
>> This doesn't match Webkit's behavior. ?Instead of steps 5 and 6, we just
>> try to parse it as a CSS color. ?If we succeed, we use that color.
>> Otherwise, we chunk it into the legacy parsing algorithm and do what the
>> spec says. ?So, for example, <font color=rgba(255,0,0,.5)>foo</font> is
>> actually displayed as partially-transparent red instead of dark green
>> (following the algorithm mangles the string into #050).
>>
>> Could we change those two steps to just say "If keyword is a valid CSS
>> color value, then return the simple color corresponding to that value."?
>> (I guess, to fully match Webkit, you need to change the definition of
>> "simple color" to take alpha into account.)
>
> On Fri, 8 Apr 2011, Boris Zbarsky wrote:
>>
>> But it does match other UAs....
>>
>> Do you have web compat data here?
>>
>> I would much rather stick with color parsing as defined in HTML4 modulo
>> the "not a color name, treat it as a hex color even if it doesn't start
>> with '#'" quirk than replace the "is it a color name?" test with a "does
>> it parse as a CSS color?" test.
>
> On Wed, 13 Apr 2011, Philip Taylor wrote:
>>
>> I don't know if this is relevant or useful but anyway:
>> http://philip.html5.org/data/font-colors.txt has some basic data for
>> <font color> values, http://philip.html5.org/data/bgcolors.txt for <body
>> bgcolor>. (Each line is the number of URLs that value was found on (from
>> the set from http://philip.html5.org/data/dotbot-20090424.txt), followed
>> by the XML-encoded value.)
>
> Looks like there are values that would be affected by this change.
>
> I've left it as-is. I think compat here is vastly more important than
> adding new capabilities, since this is only used for legacy features.

I recently patched WebKit to match the spec anyway, so that's fine.  ^_^

I'll note, though, that the spec algorithm seems to be Firefox's
behavior, which differs in a few significant points from IE's.  In
particular, IE doesn't strip whitespace from the color, doesn't have
the same "truncate at 128 bytes" behavior, and doesn't recognize a
3-digit hex color as a CSS color (instead parsing it with legacy
rules).

I doubt it matters too much, but was there any particular reason you
went with Firefox over IE here?

~TJ


From dbaron at dbaron.org  Fri Jul 15 11:57:18 2011
From: dbaron at dbaron.org (L. David Baron)
Date: Fri, 15 Jul 2011 11:57:18 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
 algorithm
In-Reply-To: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
Message-ID: <20110715185718.GA23248@pickering.dbaron.org>

On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote:
> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we
> just try to parse it as a CSS color.

As I pointed out in
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html
this isn't compatible with doing the following simultaneously:
 * using the algorithm given, which converts the values to colors at
   parse time
 * correctly handling dynamic changes of system appearance for the
   system color values

Correctly handling dynamic changes of system appearance here would
be a significant amount of work even if the algorithm here changed,
and I'd really rather not add that support for a legacy feature, nor
would I like to have an inconsistency between CSS and HTML as to
whether system colors are dynamically updated.

-David

-- 
?   L. David Baron                         http://dbaron.org/   ?
?   Mozilla Corporation               http://www.mozilla.com/   ?


From ifette at google.com  Fri Jul 15 11:58:35 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 11:58:35 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
Message-ID: <CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>

2011/7/15 Jonas Sicking <jonas at sicking.cc>

> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> > page author to have control over the response headers sent by the
> > server.*(A related example is offline apps, which may wish to provide
> > the user with
> > a way to "download" a file stored locally using the filesystem API but
> again
> > can't set any headers.) It would be nice to provide the page author with
> a
> > client side mechanism to trigger a download.
> >
> > After mulling this over with some application developers who are trying
> to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
> We've discussed a different solution to the same problem at mozilla.
> The solution we discussed was allowing FileSaver to in addition to
> taking a blob argument, allow it to take a url argument.
>
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com
>
> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file
> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com
>
> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.
> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.
>
> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.
>
> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.
>
> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.
>
> Oh, and I don't have strong opinions at this time on if rel=attachment
> or FileSaver or both should be the way to trigger this functionality.
>
> / Jonas
>

I agree FileSaver is useful and has its place, but I don't think it negates
the need for something like rel=attachment or download=filename. For one,
FileSaver currently operates on blobs and as you mention would have to be
modified to handle URLs or streams more generally. Second, it would force
developers to use javascript links and/or set up click listeners and so
forth, which could be annoying for users (losing the ability to copy the URL
etc).

I don't understand why we would add CORS as a requirement for this. You can
already link to things from another origin, the fact that they may be
downloaded rather than displayed and then the user somehow tricked to upload
them seems like a rather remote concern...  if I now want to link to a
StarCraft 2 patch and give the browser a hint that it's a download (so that
maybe in the future the browser might be able to have more intelligent UI
when I hover over it, or at least not pop up a new window that just then
spawns a download) requiring CORS seems quite overkill, especially if the
response would have triggered a download anyways.

I guess the interesting question is "If the response would not have
otherwise triggered a download, and the request is cross-origin, should that
require CORS" and personally I would say no, this is still a remote enough
concern that I would not worry about it.

-Ian


From jackalmage at gmail.com  Fri Jul 15 12:01:40 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 15 Jul 2011 12:01:40 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
	algorithm
In-Reply-To: <20110715185718.GA23248@pickering.dbaron.org>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<20110715185718.GA23248@pickering.dbaron.org>
Message-ID: <CAAWBYDDrj6uUJz5rBr+4fxPtmozfAZEiM9fqb6Ld0rQorbcBgw@mail.gmail.com>

On Fri, Jul 15, 2011 at 11:57 AM, L. David Baron <dbaron at dbaron.org> wrote:
> On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote:
>> This doesn't match Webkit's behavior. ?Instead of steps 5 and 6, we
>> just try to parse it as a CSS color.
>
> As I pointed out in
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html
> this isn't compatible with doing the following simultaneously:
> ?* using the algorithm given, which converts the values to colors at
> ? parse time
> ?* correctly handling dynamic changes of system appearance for the
> ? system color values
>
> Correctly handling dynamic changes of system appearance here would
> be a significant amount of work even if the algorithm here changed,
> and I'd really rather not add that support for a legacy feature, nor
> would I like to have an inconsistency between CSS and HTML as to
> whether system colors are dynamically updated.

WebKit now matches the spec (and Firefox) anyway, so the issue is moot.

~TJ


From jonas at sicking.cc  Fri Jul 15 13:09:17 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Jul 2011 13:09:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
Message-ID: <CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>

2011/7/15 Ian Fette (????????) <ifette at google.com>:
> 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>
>> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
>> > Many websites wish to offer a file for download, even though it could
>> > potentially be viewed inline (take images, PDFs, or word documents as an
>> > example). Traditionally the only way to achieve this is to set a
>> > content-disposition header. *However, sometimes it is not possible for
>> the
>> > page author to have control over the response headers sent by the
>> > server.*(A related example is offline apps, which may wish to provide
>> > the user with
>> > a way to "download" a file stored locally using the filesystem API but
>> again
>> > can't set any headers.) It would be nice to provide the page author with
>> a
>> > client side mechanism to trigger a download.
>> >
>> > After mulling this over with some application developers who are trying
>> to
>> > use this functionality, it seems like adding a "rel" attribute to the <a>
>> > tag would be a straightforward, minimally invasive way to address this
>> use
>> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
>> > should treat this link as if the response came with a
>> content-disposition:
>> > attachment header, and offer to download/save the file for the user.
>>
>> We've discussed a different solution to the same problem at mozilla.
>> The solution we discussed was allowing FileSaver to in addition to
>> taking a blob argument, allow it to take a url argument.
>>
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party site. I.e. this would allow
>> evil.com to trick the user into downloading an email from the users
>> webmail, or download a page from their bank which contains all their
>> banking information. It might be easier to then trick the user into
>> re-uploading the saved file to evil.com since from a user's
>> perspective, it looked like the file came from evil.com
>>
>> Another possible attack goes something like:
>> 1. evil.com tricks the user into downloading sensitive data from bank.com
>> 2. evil.com then asks the user to download a html from evil.com and
>> open the newly downloaded file
>> 3. the html file contains script which reads the contents from the
>> file downloaded from bank.com and sends it back to evil.com
>>
>> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> the browser. However it's well known that users very often hit
>> whichever button they suspect will make the dialog go away, rather
>> than actually read the contents of the dialog.
>> Step 3 again requires the user to answer "yes" to a dialog displayed
>> by the browser in at least some browsers. Same caveat applies though.
>>
>> One very simple remedy to this would be to require CORS opt-in for
>> cross-site downloads. For same-site downloads no special opt-in would
>> be required of course.
>>
>> It's also possible that it would be ok to do this without any opt-ins
>> since there are a good number of actions that the user has to take in
>> all these scenarios. Definitely something that I'd be ok with
>> discussing with our security team.
>>
>> Tentatively I would feel safer with the CORS option though. And again,
>> for same-site downloads this isn't a problem at all, but I suspect
>> that in many cases the file to be downloaded is hosted on a separate
>> server.
>>
>> Oh, and I don't have strong opinions at this time on if rel=attachment
>> or FileSaver or both should be the way to trigger this functionality.
>>
>> / Jonas
>>
>
> I agree FileSaver is useful and has its place, but I don't think it negates
> the need for something like rel=attachment or download=filename. For one,
> FileSaver currently operates on blobs and as you mention would have to be
> modified to handle URLs or streams more generally. Second, it would force
> developers to use javascript links and/or set up click listeners and so
> forth, which could be annoying for users (losing the ability to copy the URL
> etc).

As stated, I don't have a strong preference here. I suspect ultimately
we'll end up wanting both a markup based and an API based solution
here.

> I guess the interesting question is "If the response would not have
> otherwise triggered a download, and the request is cross-origin, should that
> require CORS" and personally I would say no, this is still a remote enough
> concern that I would not worry about it.

Indeed, that is the interesting question.

I know that I would personally feel a lot more comfortable if the site
opted in to allowing downloads of the resource in question. But it's
quite possible that I'm overly paranoid.

Though one thing to keep in mind is sites that explicitly state that a
resource should *not* reach the users disk. This is today often done
using "Cache-Control: no-store". Seems scary to allow such content to
be saved based on a cross-site request.

/ Jonas


From julian.reschke at gmx.de  Fri Jul 15 13:15:17 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 15 Jul 2011 22:15:17 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
Message-ID: <4E209FD5.80805@gmx.de>

On 2011-07-15 19:05, Ian Fette (????????) wrote:
> ..
>> It also doesn't naturally help understanding that it's just poor man's
>> Content-Disposition:attachment. From this point of view, I like Ian's
>> original proposal (rel=attachment) more.
>>
>
> Yes and no - both are sort of a poor man's Content-Disposition :) The
> question is whether we need to handle filename, and the proposal of
> download=filename at least maps content-disposition fully and compactly.
> ...

Well, one difference is that C-D is under the control of the owner of 
the resource being linked to (ideally), while attributes set somewhere 
else might not.

So there is a security-related aspect to this.

Best regards, Julian


From ian at hixie.ch  Fri Jul 15 13:18:04 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 20:18:04 +0000 (UTC)
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
 algorithm
In-Reply-To: <CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
	<Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
	<CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107152014060.3775@ps20323.dreamhostps.com>

On Fri, 15 Jul 2011, Tab Atkins Jr. wrote:
> 
> I'll note, though, that the spec algorithm seems to be Firefox's 
> behavior, which differs in a few significant points from IE's.  In 
> particular, IE doesn't strip whitespace from the color, doesn't have the 
> same "truncate at 128 bytes" behavior, and doesn't recognize a 3-digit 
> hex color as a CSS color (instead parsing it with legacy rules).
> 
> I doubt it matters too much, but was there any particular reason you 
> went with Firefox over IE here?

See:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372

Basically, it looks like IE does strip whitespace in some cases, the main 
difference is that it doesn't handle #123 the same as #112233. Since that 
would introduce an incompatibility with CSS, and since there was no 
interop on that case, I figured (based on input from Aryeh and dbaron) we 
might as well go with the sane behaviour.

Interop isn't perfect here so there's not really any winning whatever we do.

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


From ian at hixie.ch  Fri Jul 15 13:24:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 20:24:10 +0000 (UTC)
Subject: [whatwg] <details>, <summary> and styling
In-Reply-To: <235E71A0BBF14725854030F4C04807B6@JukanPC>
References: <op.vs3w0wvrm3w6te@kunnskapet.oslo.osa>
	<235E71A0BBF14725854030F4C04807B6@JukanPC>
Message-ID: <Pine.LNX.4.64.1107152021360.2079@ps20323.dreamhostps.com>

On Mon, 11 Apr 2011, Jukka K. Korpela wrote:
> Wilhelm Joys Andersen wrote:
> > 
> >    "If there is no child summary element [of the details element], the
> >    user agent should provide its own legend (e.g. "Details")." [1]
> > 
> > How exactly should this legend be provided?
> 
> Since the situation raises implementation difficulties, it would be best 
> to make the summary element required in a details element, i.e. to force 
> authors to provide a summary.

It is required. That doesn't force authors to do anything, though.


> But it appears to be an undue burden to require browsers to provide a 
> default legend, which would need to be different for different 
> languages.

Making it required doesn't help user agents deal with pages where it is 
omitted.


> A key issue with the details element is that it does not degrade well. 
> It's difficult to say how much this could be improved. In any case, the 
> fact that the details themselves - the content of the details element 
> excluding the summary element - do not constitute an element makes 
> things rather difficult.

It's easy to wrap them in an element for fallback purposes.

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


From ian at hixie.ch  Fri Jul 15 13:33:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 20:33:10 +0000 (UTC)
Subject: [whatwg] <summary> and <details> elements' specification
In-Reply-To: <9EA7F4E9AAAA49A9BD020B51637172D8@JukanPC>
References: <op.vtrz90t3rkwrfs@herring.wroclaw.osa>
	<4DA30906.4060305@opera.com>
	<50CD6C4370FA48AFB0B377923E8B9F00@JukanPC>
	<BANLkTikzVb97vCFf5eReJmJVjHS=jey8Uw@mail.gmail.com>
	<9EA7F4E9AAAA49A9BD020B51637172D8@JukanPC>
Message-ID: <Pine.LNX.4.64.1107152026340.2079@ps20323.dreamhostps.com>

On Mon, 11 Apr 2011, Tomasz Jamroszczak wrote:
> 
> Instead of making <summary> inside <details> working as <legend> inside 
> <fieldset>, we can throw away the <details> tag and make <summary> work 
> like <label> element with form element.  There's no need for "open" 
> attribute, instead already existing "hidden" attribute can be used on 
> any HTML element. Clicking on <summary> adds or removes "hidden" 
> attribute from element with given id.
> 
> 	Here's default UA style:
> 
> summary {
>  display: list-item;
>  list-style-type: -o-disclosure-closed;
> }
> [hidden] {
>  display: none;
> }
> 
> 	Here's example HTML:
> 
> <summary for="detailsId">This is summary. Click to show/close
> details.</summary>
> <div id="detailsId" hidden>...</div>

I don't think this really captures the way disclosure widgets work. On 
platforms that support them natively, the disclosure widget, the summary, 
and the details are all one unit.


> Pros:
> 1. Simple to understand by web page authors - its representation and semantics
> play well together.

It's not clear to me that it's any clearer -- in particular, for="" is 
especially bug prone.


> 2. No XBL involved.

We'd still have to have a binding for the animation effects.


> 3. Nicely rendered by browsers not supporting <summary> tag.

Isn't it the same as on browsers that don't support <details>?


> 4. No quirky rendering.

Not sure what you mean here. Why would anything have quirky rendering?


> 5. Less keywords to memorize by web authors, reusing existing keywords 
> in semantically correct way.

It trades <summary> and <details> for <summary>, for="", id="", and 
hidden="". I'm not sure that's much simpler.


> Cons:
> 6. Error-prone for web developers using copy-and-paste method.

That's a big con. :-)


On Tue, 12 Apr 2011, Jukka K. Korpela wrote:
> 
> Just as <label> could have been defined to be paired with (by default) 
> its next sibling or, perhaps better, with the next input field, 
> <summary> could be defined to be paired with its next sibling or, 
> perhaps better, with the next <details> element, by default.

This kind of magic association is, IMHO, very confusing for authors and 
not at all good language design.


> The element name "summary" is somewhat odd, and would appear even more 
> odd if liberated from appearing inside <details>. This element is really 
> meant to be a control for rendering vs. not rendering the contents of 
> the <details> element, and its contents is just a label for the control. 
> The example at 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element 
> is accompanied with the note "In these examples, the summary really just 
> summarises what the controls can change, and not the actual values, 
> which is less than ideal." In reality, the example seems to correspond 
> to _normal_ expected use of <details>, so the name "summary" is 
> misleading. Perhaps <control> would be better, but as it's really a 
> special kind of control only, how about <open>?

The idea is to encourage people to give a summary.

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


From ian at hixie.ch  Fri Jul 15 14:01:38 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jul 2011 21:01:38 +0000 (UTC)
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<21B04E943C1341F0A867C1234DB30723@JukanPC>
	<BANLkTi=_8R2CRbTcXSFtSVAsD66682rznQ@mail.gmail.com>
	<A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
Message-ID: <Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>

On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
>
> I was surprised at seeing that the Finnish-language version of Google 
> Chrome 11 beta accepts a number with a comma, such as "4,2", in <input 
> type="number">. It silently converts the comma to a full stop, "4.2".
> 
> This looked like a useful feature at first sight, as decimal comma is 
> standard in Finnish as in most human languages. But this seems to 
> violate the rules, since <input type="number"> is defined as allowing a 
> "valid floating point number" (the definition of which clearly allows 
> FULL STOP as the only decimal separator) only and, moreover, there is 
> prescribed error processing: an error shall be returned, and the value 
> sanitization algorithm shall set the value to the empty string; ref.: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
>
> So the Google Chrome implementation is in error here, right?

No, it's exactly right. You are confusing the UI with the submitted value.


On Thu, 14 Apr 2011, Old?ich Vete?n?k wrote:
> 
> I am afraid that if the decimal separator (in rendering) doesn't behave 
> the way people expect it to, it will mean web developers will have to 
> deal with clients saying "We wan't to be able to enter a comma." The 
> "dealing" might mean not using <input type="number"> at all, which is 
> something we might not want...

That is a risk, it is true.


On Fri, 15 Apr 2011, Aryeh Gregor wrote:
> 
> I didn't read the whole thread, but: authors with specific needs will 
> always want to roll their own inputs for most of these things, and 
> that's fine.  If <input type=number> satisfies 80% of the use-cases, 
> that's fine.  As more authors start using the new input types, we'll get 
> feedback about what the most-requested features are, and we can consider 
> adding them at that time.  Trying to add more features to the new form 
> stuff is premature when we only have one really good implementation 
> (IMO: Gecko's), and that implementation is partial. The time to talk 
> about new features is when we have some amount of stability and 
> interoperability in existing features.

Indeed.


On Mon, 18 Apr 2011, Jukka K. Korpela wrote:
> 
> My original observation was that Google Chrome accepts a number with 
> decimal comma. It does that quite independently of the language. As far 
> as specifications go, it could just as well _only_ accept decimal comma. 
> Would that be perfectly suitable?

Per spec, yes.

Of course, it would be a pretty poor user experience. But that's just a UI 
issue. What it _should_ do is magically guess what the user meant and just 
do the right thing. Failing that, an approximation based on the user's 
preferences and locale, and the page's locale and style sheets.



On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
> 
> In general with the new input types, we have the problem that when they 
> are not supported but degrade to <input type="text">, the user would 
> need instructions on data format, e.g. saying that decimal point be used 
> or that a color be specified as #hhhhhh - and these would look stupid 
> when they are not needed. But this can probably be handled reasonably 
> using scripts that test for the support first. Or maybe it would be more 
> robust, transitionally, to include the instructions and <input 
> type="text"> in markup, with client-side scripting then trying to set 
> the state to, say, "number", and when successful, removing the 
> instructions (or replacing them with some different instructions).

Indeed.

Much discussion on this topic happened when we started on this work in 
2004 and 2005, I highly recommend perusing the archives around that time.


On Thu, 14 Apr 2011, John Tamplin wrote:
> 
> The entire web application, which includes both client and server-side 
> code, must have the same idea about what locale the user is using.  If 
> the app provides a drop-down box or preference setting to choose a 
> different locale, as most localized apps do, the web browser has to be 
> using the same locale for any native locale processing it uses.  
> Otherwise, you run a serious risk of having incorrect data -- if a user 
> types "10,000" in a field when they think they are using a locale with a 
> comma as the decimal separator, does the app receive that as 10000 or 
> 10.000?  If the app is running in en-US because the user requested it or 
> their system locale isn't supported by the app, and the browser sends 
> "10.000" as the value because the system locale is "de", then that is a 
> problem.

Indeed. To solve this, we need help from CSS. That's one of the reasons we 
created <output> in HTML.

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

From jackalmage at gmail.com  Fri Jul 15 14:09:15 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 15 Jul 2011 14:09:15 -0700
Subject: [whatwg] Accept full CSS colors in the legacy color parsing
	algorithm
In-Reply-To: <Pine.LNX.4.64.1107152014060.3775@ps20323.dreamhostps.com>
References: <BANLkTi=4cTDgDZi8011i9DotyGeQtdNjHw@mail.gmail.com>
	<4D9F7D8F.90907@mit.edu>
	<BANLkTimNmJ2E6h2iqQmWzTXDPNs1KBwrJQ@mail.gmail.com>
	<Pine.LNX.4.64.1107151842180.2079@ps20323.dreamhostps.com>
	<CAAWBYDDCLUv1w-HMSrwbyWM7jgu=CGx=7AKj3xLy4pM08J6C1w@mail.gmail.com>
	<Pine.LNX.4.64.1107152014060.3775@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDD=fY7f283qBR3UjM7VCxY4PeAn6DPb7g3KnahR9pfDsA@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:18 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 15 Jul 2011, Tab Atkins Jr. wrote:
>> I'll note, though, that the spec algorithm seems to be Firefox's
>> behavior, which differs in a few significant points from IE's. ?In
>> particular, IE doesn't strip whitespace from the color, doesn't have the
>> same "truncate at 128 bytes" behavior, and doesn't recognize a 3-digit
>> hex color as a CSS color (instead parsing it with legacy rules).
>>
>> I doubt it matters too much, but was there any particular reason you
>> went with Firefox over IE here?
>
> See:
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372
>
> Basically, it looks like IE does strip whitespace in some cases, the main
> difference is that it doesn't handle #123 the same as #112233. Since that
> would introduce an incompatibility with CSS, and since there was no
> interop on that case, I figured (based on input from Aryeh and dbaron) we
> might as well go with the sane behaviour.
>
> Interop isn't perfect here so there's not really any winning whatever we do.

That's fine.  I was just curious.  Like I said, WebKit now matches the
spec, so whatever.

~TJ


From ifette at google.com  Fri Jul 15 14:32:54 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 14:32:54 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E209FD5.80805@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CABirCh-aFGVLtd68M5Q2GHSoj2JyYB-KRwkb2teXMhattVOW3g@mail.gmail.com>
	<CAP0-QpuYeE+TVXghdQTdrWj66CGH+gjZu1SuwpVpp8SP5rBy4w@mail.gmail.com>
	<CAOACb=+W97KYpR8msqiNsV2ErRdD_AL3SyDXqJS+UkweOb=weQ@mail.gmail.com>
	<CAAWBYDCHFmWJ_kBLVWi_QC5PxMgihVmqdTO7u0_v1CggyfymPw@mail.gmail.com>
	<397AAA2E-C850-43D6-9D9E-235B731741D1@webkit.org>
	<CAF4kx8cNJe+EfEpg7t1OXB_Ke+VQu3sPmC4aRqAtgU9J+=jkVg@mail.gmail.com>
	<4E209FD5.80805@gmx.de>
Message-ID: <CAF4kx8dTi6T+j5SbLbfuJyG7yYbfLaNNpEKTTk9ztAO5iLZgNg@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:15 PM, Julian Reschke <julian.reschke at gmx.de>wrote:

> On 2011-07-15 19:05, Ian Fette (????????) wrote:
>
>> ..
>>
>>> It also doesn't naturally help understanding that it's just poor man's
>>> Content-Disposition:**attachment. From this point of view, I like Ian's
>>> original proposal (rel=attachment) more.
>>>
>>>
>> Yes and no - both are sort of a poor man's Content-Disposition :) The
>> question is whether we need to handle filename, and the proposal of
>> download=filename at least maps content-disposition fully and compactly.
>> ...
>>
>
> Well, one difference is that C-D is under the control of the owner of the
> resource being linked to (ideally), while attributes set somewhere else
> might not.
>
> So there is a security-related aspect to this.
>
> Best regards, Julian
>

So, in the interest of making progress, what if we tried...

download=filename

for same origin it's always downloaded (includes filesystem api from that
origin)
for cross-origin it's downloaded if we get a positive CORS response and/or
we get a content-disposition attachment
for cross-origin if we don't get positive CORS response OR
content-disposition:attachment we don't download

We can always start conservative and broaden out.

-Ian


From darin at chromium.org  Fri Jul 15 14:34:29 2011
From: darin at chromium.org (Darin Fisher)
Date: Fri, 15 Jul 2011 14:34:29 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
Message-ID: <CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> 2011/7/15 Ian Fette (????????) <ifette at google.com>:
> > 2011/7/15 Jonas Sicking <jonas at sicking.cc>
> >
> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
> >> > Many websites wish to offer a file for download, even though it could
> >> > potentially be viewed inline (take images, PDFs, or word documents as
> an
> >> > example). Traditionally the only way to achieve this is to set a
> >> > content-disposition header. *However, sometimes it is not possible for
> >> the
> >> > page author to have control over the response headers sent by the
> >> > server.*(A related example is offline apps, which may wish to provide
> >> > the user with
> >> > a way to "download" a file stored locally using the filesystem API but
> >> again
> >> > can't set any headers.) It would be nice to provide the page author
> with
> >> a
> >> > client side mechanism to trigger a download.
> >> >
> >> > After mulling this over with some application developers who are
> trying
> >> to
> >> > use this functionality, it seems like adding a "rel" attribute to the
> <a>
> >> > tag would be a straightforward, minimally invasive way to address this
> >> use
> >> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> >> > should treat this link as if the response came with a
> >> content-disposition:
> >> > attachment header, and offer to download/save the file for the user.
> >>
> >> We've discussed a different solution to the same problem at mozilla.
> >> The solution we discussed was allowing FileSaver to in addition to
> >> taking a blob argument, allow it to take a url argument.
> >>
> >> One concern which was brought up was the ability to cause the user to
> >> download a file from a third party site. I.e. this would allow
> >> evil.com to trick the user into downloading an email from the users
> >> webmail, or download a page from their bank which contains all their
> >> banking information. It might be easier to then trick the user into
> >> re-uploading the saved file to evil.com since from a user's
> >> perspective, it looked like the file came from evil.com
> >>
> >> Another possible attack goes something like:
> >> 1. evil.com tricks the user into downloading sensitive data from
> bank.com
> >> 2. evil.com then asks the user to download a html from evil.com and
> >> open the newly downloaded file
> >> 3. the html file contains script which reads the contents from the
> >> file downloaded from bank.com and sends it back to evil.com
> >>
> >> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> >> the browser. However it's well known that users very often hit
> >> whichever button they suspect will make the dialog go away, rather
> >> than actually read the contents of the dialog.
> >> Step 3 again requires the user to answer "yes" to a dialog displayed
> >> by the browser in at least some browsers. Same caveat applies though.
> >>
> >> One very simple remedy to this would be to require CORS opt-in for
> >> cross-site downloads. For same-site downloads no special opt-in would
> >> be required of course.
> >>
> >> It's also possible that it would be ok to do this without any opt-ins
> >> since there are a good number of actions that the user has to take in
> >> all these scenarios. Definitely something that I'd be ok with
> >> discussing with our security team.
> >>
> >> Tentatively I would feel safer with the CORS option though. And again,
> >> for same-site downloads this isn't a problem at all, but I suspect
> >> that in many cases the file to be downloaded is hosted on a separate
> >> server.
> >>
> >> Oh, and I don't have strong opinions at this time on if rel=attachment
> >> or FileSaver or both should be the way to trigger this functionality.
> >>
> >> / Jonas
> >>
> >
> > I agree FileSaver is useful and has its place, but I don't think it
> negates
> > the need for something like rel=attachment or download=filename. For one,
> > FileSaver currently operates on blobs and as you mention would have to be
> > modified to handle URLs or streams more generally. Second, it would force
> > developers to use javascript links and/or set up click listeners and so
> > forth, which could be annoying for users (losing the ability to copy the
> URL
> > etc).
>
> As stated, I don't have a strong preference here. I suspect ultimately
> we'll end up wanting both a markup based and an API based solution
> here.
>
> > I guess the interesting question is "If the response would not have
> > otherwise triggered a download, and the request is cross-origin, should
> that
> > require CORS" and personally I would say no, this is still a remote
> enough
> > concern that I would not worry about it.
>
> Indeed, that is the interesting question.
>
> I know that I would personally feel a lot more comfortable if the site
> opted in to allowing downloads of the resource in question. But it's
> quite possible that I'm overly paranoid.
>
> Though one thing to keep in mind is sites that explicitly state that a
> resource should *not* reach the users disk. This is today often done
> using "Cache-Control: no-store". Seems scary to allow such content to
> be saved based on a cross-site request.
>
> / Jonas
>


This security concern is very interesting.  I had not considered it before.

Putting that aside for a moment, I'm glad to hear that you also support
there being some declarative method of triggering a download.  Which of
the proposals are you leaning toward?

Personally, I'm most fond of the @download=filename method.  Reason:

1)  Unlike rel=something, @download is feature detectable at runtime via
("download" in document.createElement("a")).

2)  Unlike rel=something, @download provides a way to specify the name
of the file to save.  This makes the feature useful with data: URLs and
blob:
URLs (that are not backed by a single file).  This is valuable to me because
I can imagine wanting to save the contents of a <canvas>, and that probably
involves saving the data URL that you get from toDataURL().

3)  The target=_download idea is interesting, but I'm not sure we can safely
introduce new target values, and this also suffers from not providing a way
to
specify the downloaded filename.

4)  The idea of using both a rel=something and an attribute to specify the
file
name could work too, but it seems a bit overly verbose.  I'm not sure I see
enough benefit from this.  The idea of providing a name for <img> tags that
might be downloaded manually by the user is interesting, but it feels like a
far less interesting problem to solve.  If our solution solves this too,
then great,
but I wouldn't necessarily make it a requirement to solve this problem too.

Anyways, what do you think?  I'd really like to reach some consensus on what
the declarative method should look like.

Whatever security restrictions we come up with will need to apply to
FileSaver
too assuming FileSaver ends up taking an URL (and a filename!).

Thanks!
-Darin


From jonas at sicking.cc  Fri Jul 15 16:00:03 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Jul 2011 16:00:03 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
Message-ID: <CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>

2011/7/15 Darin Fisher <darin at chromium.org>:
> On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> 2011/7/15 Ian Fette (????????) <ifette at google.com>:
>> > 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>> >
>> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
>> >> > Many websites wish to offer a file for download, even though it could
>> >> > potentially be viewed inline (take images, PDFs, or word documents as
>> >> > an
>> >> > example). Traditionally the only way to achieve this is to set a
>> >> > content-disposition header. *However, sometimes it is not possible
>> >> > for
>> >> the
>> >> > page author to have control over the response headers sent by the
>> >> > server.*(A related example is offline apps, which may wish to provide
>> >> > the user with
>> >> > a way to "download" a file stored locally using the filesystem API
>> >> > but
>> >> again
>> >> > can't set any headers.) It would be nice to provide the page author
>> >> > with
>> >> a
>> >> > client side mechanism to trigger a download.
>> >> >
>> >> > After mulling this over with some application developers who are
>> >> > trying
>> >> to
>> >> > use this functionality, it seems like adding a "rel" attribute to the
>> >> > <a>
>> >> > tag would be a straightforward, minimally invasive way to address
>> >> > this
>> >> use
>> >> > case. <a rel=attachment href=blah.pdf> would indicate that the
>> >> > browser
>> >> > should treat this link as if the response came with a
>> >> content-disposition:
>> >> > attachment header, and offer to download/save the file for the user.
>> >>
>> >> We've discussed a different solution to the same problem at mozilla.
>> >> The solution we discussed was allowing FileSaver to in addition to
>> >> taking a blob argument, allow it to take a url argument.
>> >>
>> >> One concern which was brought up was the ability to cause the user to
>> >> download a file from a third party site. I.e. this would allow
>> >> evil.com to trick the user into downloading an email from the users
>> >> webmail, or download a page from their bank which contains all their
>> >> banking information. It might be easier to then trick the user into
>> >> re-uploading the saved file to evil.com since from a user's
>> >> perspective, it looked like the file came from evil.com
>> >>
>> >> Another possible attack goes something like:
>> >> 1. evil.com tricks the user into downloading sensitive data from
>> >> bank.com
>> >> 2. evil.com then asks the user to download a html from evil.com and
>> >> open the newly downloaded file
>> >> 3. the html file contains script which reads the contents from the
>> >> file downloaded from bank.com and sends it back to evil.com
>> >>
>> >> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> >> the browser. However it's well known that users very often hit
>> >> whichever button they suspect will make the dialog go away, rather
>> >> than actually read the contents of the dialog.
>> >> Step 3 again requires the user to answer "yes" to a dialog displayed
>> >> by the browser in at least some browsers. Same caveat applies though.
>> >>
>> >> One very simple remedy to this would be to require CORS opt-in for
>> >> cross-site downloads. For same-site downloads no special opt-in would
>> >> be required of course.
>> >>
>> >> It's also possible that it would be ok to do this without any opt-ins
>> >> since there are a good number of actions that the user has to take in
>> >> all these scenarios. Definitely something that I'd be ok with
>> >> discussing with our security team.
>> >>
>> >> Tentatively I would feel safer with the CORS option though. And again,
>> >> for same-site downloads this isn't a problem at all, but I suspect
>> >> that in many cases the file to be downloaded is hosted on a separate
>> >> server.
>> >>
>> >> Oh, and I don't have strong opinions at this time on if rel=attachment
>> >> or FileSaver or both should be the way to trigger this functionality.
>> >>
>> >> / Jonas
>> >>
>> >
>> > I agree FileSaver is useful and has its place, but I don't think it
>> > negates
>> > the need for something like rel=attachment or download=filename. For
>> > one,
>> > FileSaver currently operates on blobs and as you mention would have to
>> > be
>> > modified to handle URLs or streams more generally. Second, it would
>> > force
>> > developers to use javascript links and/or set up click listeners and so
>> > forth, which could be annoying for users (losing the ability to copy the
>> > URL
>> > etc).
>>
>> As stated, I don't have a strong preference here. I suspect ultimately
>> we'll end up wanting both a markup based and an API based solution
>> here.
>>
>> > I guess the interesting question is "If the response would not have
>> > otherwise triggered a download, and the request is cross-origin, should
>> > that
>> > require CORS" and personally I would say no, this is still a remote
>> > enough
>> > concern that I would not worry about it.
>>
>> Indeed, that is the interesting question.
>>
>> I know that I would personally feel a lot more comfortable if the site
>> opted in to allowing downloads of the resource in question. But it's
>> quite possible that I'm overly paranoid.
>>
>> Though one thing to keep in mind is sites that explicitly state that a
>> resource should *not* reach the users disk. This is today often done
>> using "Cache-Control: no-store". Seems scary to allow such content to
>> be saved based on a cross-site request.
>>
>> / Jonas
>
>
> This security concern is very interesting.  I had not considered it before.
> Putting that aside for a moment, I'm glad to hear that you also support
> there being some declarative method of triggering a download.  Which of
> the proposals are you leaning toward?
> Personally, I'm most fond of the @download=filename method.  Reason:
> 1)  Unlike rel=something, @download is feature detectable at runtime via
> ("download" in document.createElement("a")).
> 2)  Unlike rel=something, @download provides a way to specify the name
> of the file to save.  This makes the feature useful with data: URLs and
> blob:
> URLs (that are not backed by a single file).  This is valuable to me because
> I can imagine wanting to save the contents of a <canvas>, and that probably
> involves saving the data URL that you get from toDataURL().
> 3)  The target=_download idea is interesting, but I'm not sure we can safely
> introduce new target values, and this also suffers from not providing a way
> to
> specify the downloaded filename.
> 4)  The idea of using both a rel=something and an attribute to specify the
> file
> name could work too, but it seems a bit overly verbose.  I'm not sure I see
> enough benefit from this.  The idea of providing a name for <img> tags that
> might be downloaded manually by the user is interesting, but it feels like a
> far less interesting problem to solve.  If our solution solves this too,
> then great,
> but I wouldn't necessarily make it a requirement to solve this problem too.
> Anyways, what do you think?  I'd really like to reach some consensus on what
> the declarative method should look like.

I agree! I like the @download attribute the best so far for basically
the same reasons you enumerate. It's also a very memorable name.

It definitely is an interesting usecase that Glenn brought up about
being able to specify a save-as name without otherwise modifying the
behavior of a reference. However that seems like a much more rare
usecase and so not the one we should optimize for.

Another UI feature that this all would allow is the ability to
drag-out-to-save. I.e. if the user drags a <a href="..."
download="..."> to the desktop, the browser can treat that as a saving
action.

> Whatever security restrictions we come up with will need to apply to
> FileSaver
> too assuming FileSaver ends up taking an URL (and a filename!).

Absolutely!

I think that the model Ian summarized in his last email is a good one.
Same-origin is always allowed, cross-origin is only allowed if there
is CORS or content-disposition: attachment.

/ Jonas


From glenn at zewt.org  Fri Jul 15 16:43:45 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 15 Jul 2011 19:43:45 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
Message-ID: <CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>

2011/7/15 Jonas Sicking <jonas at sicking.cc>

> It definitely is an interesting usecase that Glenn brought up about
> being able to specify a save-as name without otherwise modifying the
> behavior of a reference. However that seems like a much more rare
> usecase and so not the one we should optimize for.
>

Bear in mind that "optimize for" doesn't mean "support at all"; if
download=filename is used, it seems unlikely that there will ever be *any*
client-side way to supply the filename without implying attachment, which is
a very different thing than "not optimizing for it".

I don't feel strongly enough about this to press it further, but <a
href=ugly download filename=pretty> also seems fairly clean, and avoids
combining parameters that really are orthogonal to one another.

-- 
Glenn Maynard


From tantek at cs.stanford.edu  Fri Jul 15 17:38:19 2011
From: tantek at cs.stanford.edu (=?utf-8?B?VGFudGVrIMOHZWxpaw==?=)
Date: Sat, 16 Jul 2011 00:38:19 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com><CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com><CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com><CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com><CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com><CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com><CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
Message-ID: <1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>

Agreed with Glenn, narrowing the semantic solves this problem neatly:

* filename="" attribute - what to name the file if saved by the user (by whatever means)
* existing rel="enclosure" spec - download the link when clicked/activated.

So the author can choose to do one, or the other, or both. Clean, simple, orthogonal.

Tantek
-----Original Message-----
From: Glenn Maynard <glenn at zewt.org>
Sender: whatwg-bounces at lists.whatwg.org
Date: Fri, 15 Jul 2011 19:43:45 
To: Jonas Sicking<jonas at sicking.cc>
Cc: whatwg<whatwg at whatwg.org>; Darin Fisher<darin at chromium.org>; <ifette at google.com>
Subject: Re: [whatwg] a rel=attachment

2011/7/15 Jonas Sicking <jonas at sicking.cc>

> It definitely is an interesting usecase that Glenn brought up about
> being able to specify a save-as name without otherwise modifying the
> behavior of a reference. However that seems like a much more rare
> usecase and so not the one we should optimize for.
>

Bear in mind that "optimize for" doesn't mean "support at all"; if
download=filename is used, it seems unlikely that there will ever be *any*
client-side way to supply the filename without implying attachment, which is
a very different thing than "not optimizing for it".

I don't feel strongly enough about this to press it further, but <a
href=ugly download filename=pretty> also seems fairly clean, and avoids
combining parameters that really are orthogonal to one another.

-- 
Glenn Maynard

From pkasting at google.com  Fri Jul 15 18:20:54 2011
From: pkasting at google.com (Peter Kasting)
Date: Fri, 15 Jul 2011 18:20:54 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
Message-ID: <CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>

On Fri, Jul 15, 2011 at 5:38 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> * existing rel="enclosure" spec - download the link when clicked/activated.


I object to rel="enclosure" purely on naming grounds.  It is completely
unintuitive.  I don't find the fact that a spec exists for it a compelling
reason to use it.  (Specs exist for lots of things, many of them bad.)

PK


From tantek at cs.stanford.edu  Fri Jul 15 18:25:27 2011
From: tantek at cs.stanford.edu (=?utf-8?B?VGFudGVrIMOHZWxpaw==?=)
Date: Sat, 16 Jul 2011 01:25:27 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com><CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com><CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com><CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com><CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com><CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com><CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com><1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry><CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
Message-ID: <1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>

Specs *and* publishers/consumers/implementations of rel-enclosure exist (see aforementioned wiki page). And the name is based on re-using the existing term with the same semantic from the Atom spec.

Sorry but the paint on that bikeshed dried a long time ago in an IETF working group far away. ;)

Tantek

-----Original Message-----
From: Peter Kasting <pkasting at google.com>
Date: Fri, 15 Jul 2011 18:20:54 
To: <tantek at cs.stanford.edu>
Cc: Glenn Maynard<glenn at zewt.org>; <whatwg-bounces at lists.whatwg.org>; Jonas Sicking<jonas at sicking.cc>; whatwg<whatwg at whatwg.org>; Darin Fisher<darin at chromium.org>; <ifette at google.com>
Subject: Re: [whatwg] a rel=attachment

On Fri, Jul 15, 2011 at 5:38 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> * existing rel="enclosure" spec - download the link when clicked/activated.


I object to rel="enclosure" purely on naming grounds.  It is completely
unintuitive.  I don't find the fact that a spec exists for it a compelling
reason to use it.  (Specs exist for lots of things, many of them bad.)

PK


From pkasting at google.com  Fri Jul 15 18:30:17 2011
From: pkasting at google.com (Peter Kasting)
Date: Fri, 15 Jul 2011 18:30:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
	<CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
	<1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>
Message-ID: <CAAHOzFBkTurVKkjpB0hBu+-W3DUWnk0TPP=5wSFqN6VA0+1+zQ@mail.gmail.com>

On Fri, Jul 15, 2011 at 6:25 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:

> ** Specs *and* publishers/consumers/implementations of rel-enclosure exist
> (see aforementioned wiki page).


The list on the wiki page, which I assume is non-exhaustive, is
extraordinarily uncompelling.


> And the name is based on re-using the existing term with the same semantic
> from the Atom spec.
>

Don't care.  Atom feeds and HTML pages are very different things.  Basically
I echo all of Tab's annoyances with this.

PK


From kevinmarks at gmail.com  Fri Jul 15 18:53:46 2011
From: kevinmarks at gmail.com (Kevin Marks)
Date: Fri, 15 Jul 2011 18:53:46 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAHOzFBkTurVKkjpB0hBu+-W3DUWnk0TPP=5wSFqN6VA0+1+zQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
	<CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
	<1101558601-1310779529-cardhu_decombobulator_blackberry.rim.net-702562387-@b27.c18.bise6.blackberry>
	<CAAHOzFBkTurVKkjpB0hBu+-W3DUWnk0TPP=5wSFqN6VA0+1+zQ@mail.gmail.com>
Message-ID: <CAD6ztsodRBKAa__ydxjp_WHH8spm-DnE9P2yDM59RFbM-8a=Wg@mail.gmail.com>

Enclosure is precisely this use case.

You can go back and grep
http://www.imc.org/atom-syntax/entire-arch.txt for enclosure for the
discussion if you like. After much debate, rel="enclosure" was used to
replace RSS's <enclosure> element, preserving the name.

This will lead you back via the RSS specs to this post by Dave Winer in 2001:

http://www.thetwowayweb.com/payloadsforrss

which makes the same analogy with email that you're using for "attachment"

The original example RSS file there:

http://static.userland.com/gems/backend/gratefulDead.xml

Is usefully rendered by Firefox and Safari, by translating the XML
file into an HTML representation that makes sense to users, and allows
subscription to it.

The same is true for any Atom or RSS feed containing podcasts.

Sadly, Chrome just shows a document dump of the XML tree, useless to anyone.

On Fri, Jul 15, 2011 at 6:30 PM, Peter Kasting <pkasting at google.com> wrote:
> On Fri, Jul 15, 2011 at 6:25 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:
>
>> ** Specs *and* publishers/consumers/implementations of rel-enclosure exist
>> (see aforementioned wiki page).
>
>
> The list on the wiki page, which I assume is non-exhaustive, is
> extraordinarily uncompelling.

Indeed, that could do with updating with newer examples and references
to oterh support.

>
>
>> And the name is based on re-using the existing term with the same semantic
>> from the Atom spec.
>>
>
> Don't care. ?Atom feeds and HTML pages are very different things. ?Basically
> I echo all of Tab's annoyances with this.
>

Atom/RSS Feeds are seen as useful HTML sources by many browser implementations.


From ifette at google.com  Fri Jul 15 18:59:17 2011
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 15 Jul 2011 18:59:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
Message-ID: <CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>

On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>
>> It definitely is an interesting usecase that Glenn brought up about
>> being able to specify a save-as name without otherwise modifying the
>> behavior of a reference. However that seems like a much more rare
>> usecase and so not the one we should optimize for.
>>
>
> Bear in mind that "optimize for" doesn't mean "support at all"; if
> download=filename is used, it seems unlikely that there will ever be *any*
> client-side way to supply the filename without implying attachment, which is
> a very different thing than "not optimizing for it".
>
> I don't feel strongly enough about this to press it further, but <a
> href=ugly download filename=pretty> also seems fairly clean, and avoids
> combining parameters that really are orthogonal to one another.
>

I really don't see the importance of the "name the thing that isn't going to
be downloaded" usecase; there are countless edge cases that we could concern
ourselves with in HTML but that few users will ever hit, this is one. (I
also suspect a user sophisticated enough to actually save something, e.g.
right click save as, is sophisticated enough to be able to type their own
filename.)I think it's better overall to keep the semantics as clean and
simple as possible. I suggest we move forward with <a href=blah
download=filename> with the origin considerations mentioned in the previous
email and move on.




>
> --
> Glenn Maynard
>
>


From jkorpela at cs.tut.fi  Fri Jul 15 21:52:51 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sat, 16 Jul 2011 07:52:51 +0300
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<21B04E943C1341F0A867C1234DB30723@JukanPC>
	<BANLkTi=_8R2CRbTcXSFtSVAsD66682rznQ@mail.gmail.com>
	<A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
	<Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>
Message-ID: <4E211923.1080608@cs.tut.fi>

16.07.2011 00:01, Ian Hickson wrote:

> Much discussion on this topic happened when we started on this work in
> 2004 and 2005, I highly recommend perusing the archives around that time.

Authors and implementors will need to be able to understand the topic 
without checking discussions archives, so the specs should say at least 
a little about the issue that the rules for user?s input may be quite 
different from the rules for the as stored and forwared. And users will 
be confused anyway, when user interfaces work oddly.

> On Thu, 14 Apr 2011, John Tamplin wrote:
>>
>> The entire web application, which includes both client and server-side
>> code, must have the same idea about what locale the user is using.  If
>> the app provides a drop-down box or preference setting to choose a
>> different locale, as most localized apps do, the web browser has to be
>> using the same locale for any native locale processing it uses.
>> Otherwise, you run a serious risk of having incorrect data -- if a user
>> types "10,000" in a field when they think they are using a locale with a
>> comma as the decimal separator, does the app receive that as 10000 or
>> 10.000?  If the app is running in en-US because the user requested it or
>> their system locale isn't supported by the app, and the browser sends
>> "10.000" as the value because the system locale is "de", then that is a
>> problem.
>
> Indeed. To solve this, we need help from CSS. That's one of the reasons we
> created<output>  in HTML.

This is about data representation and localization, not about optional 
stylistic suggestions, so CSS is a wrong way to deal with the issue. It 
will probably cause _further_ confusion.

I?m afraid the new input types for numeric data and for dates and times, 
even when implemented in browsers, will be of very limited usefulness 
and will cause more damage than good, unless the localization issues 
will be properly addressed.

It is part of the risk that they often _seemingly_ work. For example, an 
author would use <input type=number> and test the software thoroughly by 
his own standards, but the standards don?t include testing with the 
system?s UI language being other than English. So things seem to work 
until someone tries to put a bid of 10,000 dollars but gets it turned to 
10 dollars and loses, or makes a date for 7/4/2012 and gets it 
interpreted as April 7 when he meant July 4, or vice versa.

I?m afraid many authors will start using the new types eagerly when 
browser support comes sufficiently widespread. It looks so much better, 
cooler, and easier than parsing data yourself or requiring the user to 
type data in specifically instructed format. But it?s a dangerous illusion.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From andy at pigsonthewing.org.uk  Sat Jul 16 03:46:39 2011
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat, 16 Jul 2011 11:46:39 +0100
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<1282434534-1310776703-cardhu_decombobulator_blackberry.rim.net-1066365337-@b27.c18.bise6.blackberry>
	<CAAHOzFBmD5V4OKPG-xH4uZj-dNxgsEMnbEOL0rnU5=6NpEnSnw@mail.gmail.com>
Message-ID: <CABiXOE=mi46nqBQyiuoaY60o9Pi5RfsVZ99bggfTMbuhkHP2NA@mail.gmail.com>

On 16 July 2011 02:20, Peter Kasting <pkasting at google.com> wrote:
> On Fri, Jul 15, 2011 at 5:38 PM, Tantek ?elik <tantek at cs.stanford.edu>wrote:
>
>> * existing rel="enclosure" spec - download the link when clicked/activated.

> I object to rel="enclosure" purely on naming grounds. ?It is completely
> unintuitive. ?I don't find the fact that a spec exists for it a compelling
> reason to use it. ?(Specs exist for lots of things, many of them bad.)

The above bullet-point is also at odds with:

     http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html

in which it was claimed in August 2008 that rel="enclosure" is also
for streaming media:

    "... that hyperlink is intended to be downloaded (and/or streamed) and
     cached (and/or buffered)"

That said, it appears that the definition of rel="enclosure" at:

    http://microformats.org/wiki/rel-enclosure

was never updated to account for that, and this hAudio still has the issue:

   http://microformats.org/wiki/haudio-issues#D4:_2008-01-10__rel-enclosure_does_not_allow_for_links_to_streaming_files

which the August 2008 statement was suposedly intended to rectify.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk


From darin at chromium.org  Sat Jul 16 13:48:43 2011
From: darin at chromium.org (Darin Fisher)
Date: Sat, 16 Jul 2011 13:48:43 -0700
Subject: [whatwg] a rel=attachment
Message-ID: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>

rel=anything makes me sad as it will mean more UA sniffing.  The fallback
behavior of loading the href inline could be dangerous.
On Jul 15, 2011 5:38 PM, "Tantek ?elik" <tantek at cs.stanford.edu> wrote:


From timeless at gmail.com  Sat Jul 16 22:26:20 2011
From: timeless at gmail.com (timeless)
Date: Sun, 17 Jul 2011 01:26:20 -0400
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <op.vyn9fc1qim6vpa@shwetank-dixits-macbook.local>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
	<op.vylop7byim6vpa@shwetank-dixits-macbook.local>
	<CAACrNNc8K27L2NGnSdMcjd0O3Go9Dd7r=Q8TFdO4cN4BCeV12g@mail.gmail.com>
	<op.vyn9fc1qim6vpa@shwetank-dixits-macbook.local>
Message-ID: <CAACrNNeU=Yo4eFrRz9UQZXh9Q5hB33NXMH0Nsu-ctH5UwBjfsw@mail.gmail.com>

On Fri, Jul 15, 2011 at 1:55 PM, Shwetank Dixit <shwetankd at opera.com> wrote:
> Just like, just allowing the web app to use the camera as it is will not
> make sense, and presumably, user agents will implement a authorization by
> the user before the app gains access to the camera (something like 'This
> application requests access to the camera. Allow for now/Always Allow/Never
> Allow/Close' just like you do in geolocation right now) ... just like that,
> you could do it for flash, where the app only gains access to it if the user
> allows it. If that is the implementation, i do not think there would be much
> hazards in allowing flash access.

Ignoring that there are in fact dangers for 'always allow' in the
location case. let's consider that it's probably the average choice of
a user (for geolocation, and you're suggesting the same ui for here,
thus it's probably what users will select without understanding any
risks).

if the user does choose always allow for this app, and later they're
in a museum or some other interesting location, suddenly they're in
trouble, even though originally when they allowed the thing it was ok.
that ui is not a good idea for this. the right approach is to just let
the user use their camera normally. the camera will manage flash (it
has to).


From jkorpela at cs.tut.fi  Sun Jul 17 07:09:54 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sun, 17 Jul 2011 17:09:54 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>
	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>
Message-ID: <4E22ED32.5080807@cs.tut.fi>

15.07.2011 19:56, Bjartur Thorlacius wrote:

> On 7/15/11, Jukka K. Korpela<jkorpela at cs.tut.fi>  wrote:
>> Should it? Even when the book has no URL? If you expect urn:isbn:? to
>> work anytime soon in any significant browser, you?re very optimistic.
>>
> Wikipedia and Amazon (among others) have all the mechanisms already.
> Such ISBN handlers could even be registered by JavaScripts.

Pardon? The issue is browser support to urn:isbn:?, not mechanisms that 
map ISBNs to some URLs in some system.

>> Browsers currently treat<cite>  just like<i>  (except that it has a
>> different name). There is no sign of advance functionality emerging. It
>> does not matter how usable something is when it does not exist at all.
>>
> <Cite>  is not nearly as useful as @cite.

<cite> is useful for using italics in a manner that makes you feel more 
structural. The cite attribute is completely useless unless you set up 
some processing of your own, just as a site could use for the foobar 
attribute (or data-foobar)

> So you're saying that users should rather search for the term ISBN,
> select the following number, copy it, remove/add hyphens as necessary
> and then paste it to a suitable bibliographic search form?

No, I?m saying that a proper quotation cites a book unambiguously, and 
ISBNs are a useful tool there and should then appear in content proper, 
not hidden in an attribute that browsers ignore. It?s wishful thinking 
to say that cite attributes magically turn ISBN numbers to cool queries 
or links. If a browser, or some client-side JavaScript, can do something 
like that to a cite attribute, it could equally well do that to content 
like ?ISBN? followed by a number of a certain type. That would be much 
more useful.

> But browsers need to be told that that number close to the quotation
> is an ISBN.

The string ?ISBN? is sufficient evidence of that.

> Before you said<cite>  was implemented as<i>, and your point is that
> the cite attribute is useless?

Yes.

 > They're barely related,

They are both supposed to be used for citations. I think <cite> is 
actually used quite a lot, though not always consistently, whereas the 
cite attribute mostly occurs in W3C and related documents.

 > @cite contains
> an URI, that an user agent might be able to use in an automated
> fashion.

Might be able, but doesn?t. Can you mention one browser that actually 
does something useful with it? And it isn?t a particularly new feature 
in specifications; browser vendors have had plenty of time to implement it.

> <Cite> contains a human-readable name of a work. That'll
> rarely be machine-readable.

HTML documents are always machine-readable. (Well, you _might_ just 
write HTML on a paper with a pen?)

Association of a URL of the quoted work with a blockquote element is not 
_required_. Human-readable indication of the quoted work and its author 
is a legal requirement as well as a matter of appropriateness, so it 
should have priority over any kind of linking. When there is markup for 
such indications, and even now that there isn?t, you can always _link_ 
to the quoted work?if you have something to link to.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From karld at opera.com  Sun Jul 17 07:25:54 2011
From: karld at opera.com (Karl Dubost)
Date: Sun, 17 Jul 2011 10:25:54 -0400
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E205398.9000905@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
Message-ID: <D811034D-B188-483E-A4C9-F69C0E8DC1B2@opera.com>


Le 15 juil. 2011 ? 10:50, Jukka K. Korpela a ?crit :
> Should it? Even when the book has no URL? If you expect urn:isbn:? to work anytime soon in any significant browser, you?re very optimistic.

in QuoteLink, I do a trick, eventually I should enable the provider of your choice.
But basically

if (cite.startsWith("urn:isbn:")) {
                isbn = cite.substring(9).replace(/\-/g, "");
                cite = "http://openlibrary.org/isbn/" + isbn;
            }

You could replace the openlibrary provider, by wikipedia, olcl, etc.
If we had a good model for describing authors, title, etc, we could even have a pre-populated form, giving the information for things which are not yet existent in Open Library. The first persons clicking on the link would have the opportunity to add the book. 



[1]: https://github.com/karlcow/QuoteLink
[2]: https://addons.opera.com/addons/extensions/details/quotelink/

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software



From nils at dieweltistgarnichtso.net  Sun Jul 17 08:07:09 2011
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Jul 2011 17:07:09 +0200
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E22ED32.5080807@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>
	<4E1ECE52.7090506@cs.tut.fi> <4E1EEAAE.3050701@gmail.com>
	<4E205398.9000905@cs.tut.fi>
	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>
	<4E22ED32.5080807@cs.tut.fi>
Message-ID: <20110717170709.73ed9b15@desudesudesu>

"Jukka K. Korpela" <jkorpela at cs.tut.fi> schrieb am Sun, 17 Jul 2011
17:09:54 +0300:

> 15.07.2011 19:56, Bjartur Thorlacius wrote:
> > [?]
> >
> > But browsers need to be told that that number close to the quotation
> > is an ISBN.
> 
> The string ?ISBN? is sufficient evidence of that.

Someone would need to standardize ?ISBN sniffing behaviour? for UAs
then. Could you make a proposal?

> [?]
> 
>  > @cite contains
> > an URI, that an user agent might be able to use in an automated
> > fashion.
> 
> Might be able, but doesn?t. Can you mention one browser that actually 
> does something useful with it? And it isn?t a particularly new
> feature in specifications; browser vendors have had plenty of time to
> implement it.

Are any reasons for not doing anything with that information known?
Probably a more basic issue: Is the cite attribute actually used?

> > <Cite> contains a human-readable name of a work. That'll
> > rarely be machine-readable.
> 
> HTML documents are always machine-readable. (Well, you _might_ just 
> write HTML on a paper with a pen?)

This is a category error. ?Machine-readable? in this context does not
mean ?digital information?. Fact: A scanned PDF of a printed out table
of expenses (yes, these occur) may not be ?machine-readable? in the
sense Bjartur Thorlacius used here. An ATOM feed certainly is.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From jkorpela at cs.tut.fi  Sun Jul 17 11:36:36 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sun, 17 Jul 2011 21:36:36 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <20110717170709.73ed9b15@desudesudesu>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>
	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>	<4E22ED32.5080807@cs.tut.fi>
	<20110717170709.73ed9b15@desudesudesu>
Message-ID: <4E232BB4.9020604@cs.tut.fi>

17.07.2011 18:07, Nils Dagsson Moskopp wrote:

>>> But browsers need to be told that that number close to the quotation
>>> is an ISBN.
>>
>> The string ?ISBN? is sufficient evidence of that.
>
> Someone would need to standardize ?ISBN sniffing behaviour? for UAs
> then. Could you make a proposal?

I think it would be rather trivial. The string ?ISBN? followed by 
something that matches the syntax of ISBN numbers, perhaps allowing some 
variation in punctuation, could be treated as an implicit link to a 
resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs.

The key issue is whether browser vendors have interest in it and which 
mechanism(s) would be used. After all, an ISBN could be in a multitude 
of ways, like querying an online bookshop, querying an online 
bibliographic system, or querying an site of books in digital format 
online. Which one should be used? Would it be useful? To be really 
useful, it should be handled so that the browser checks what it can get 
using the ISBN and then make that information available to user (how to 
get bibliographic info, how to read reviews, how to buy the book, how to 
borrow it in a library, download or read the book via the net for free 
or for fee).

> Are any reasons for not doing anything with that information known?
> Probably a more basic issue: Is the cite attribute actually used?

I don?t think it?s much used in the wild, except on pages by 
organizations that define HTML specs. What might be the motivation for 
browsers to do something special with it? Surely you could make things 
so that by clicking on a blockquote, the user accesses the resource 
pointed to by the cite attribute. Browsers could do that, and so could 
authors. But would users actually start clicking on quotations to see 
their sources? Surely they would far more probably click on the title of 
a work in visible credits if present and if it is a link, so what would 
the cite attribute help?

>>> <Cite>  contains a human-readable name of a work. That'll
>>> rarely be machine-readable.
>>
>> HTML documents are always machine-readable. (Well, you _might_ just
>> write HTML on a paper with a pen?)
>
> This is a category error. ?Machine-readable? in this context does not
> mean ?digital information?.

No, it?s not a category thing. It?s about the relativity of being 
?machine-readable.? You are probably thinking of data in a specific 
format designed to be easily parseable and useable by computer software, 
such as a URL, an ISO 8601 date notation, or an XML tag. But browsers 
already do many kinds of heuristics, parsing data that doesn?t really 
match the specs.

A title of a work is easily useable by software: put it inside quotation 
marks and throw it at Google, and the odds are that you get some useful 
links related to it, if there?s info on the work (and perhaps the work 
itself) on the web at all. Well, assuming that the title is relatively 
unique.

Titles of works are often more useful in the long run than URLs. URLs 
change far too often when sites are revamped or for other reasons.

I think a good start would be to add an optional (but usually 
recommended) <credits> or <source> element for use inside <blockquote>.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From svartman95 at gmail.com  Sun Jul 17 12:41:08 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 19:41:08 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
Message-ID: <4E233AD4.4080302@gmail.com>

?ann f?s 15.j?l 2011 18:39, skrifa?i Jonas Sicking:
> 2011/7/14 Ian Fette (????????)<ifette at google.com>:
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com
> 
Would it not be possible to send an unauthenticated request for the
file, if it's of different origin?


From svartman95 at gmail.com  Sun Jul 17 12:59:05 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 19:59:05 +0000
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
Message-ID: <4E233F09.5080304@gmail.com>

?ann f?s 15.j?l 2011 21:34, skrifa?i Darin Fisher:
> 2)  Unlike rel=something, @download provides a way to specify the name
> of the file to save.  This makes the feature useful with data: URLs and
> blob:
> URLs (that are not backed by a single file).  This is valuable to me because
> I can imagine wanting to save the contents of a<canvas>, and that probably
> involves saving the data URL that you get from toDataURL().
> 
> 3)  The target=_download idea is interesting, but I'm not sure we can safely
> introduce new target values, and this also suffers from not providing a way
> to
> specify the downloaded filename.
> 
Is there any other use case for providing the filename than using
canvas' toDataURL instead of blobs (a use case more simply served by
FileSaver)?


From w3c at adambarth.com  Sun Jul 17 13:05:17 2011
From: w3c at adambarth.com (Adam Barth)
Date: Sun, 17 Jul 2011 13:05:17 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
Message-ID: <CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>

2011/7/15 Jonas Sicking <jonas at sicking.cc>:
> We've discussed a different solution to the same problem at mozilla.
> The solution we discussed was allowing FileSaver to in addition to
> taking a blob argument, allow it to take a url argument.
>
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com

It seems like the solution to that problem is to be clear about where
the download is coming from.  Being clear about where downloads come
from is important in many scenarios, beyond just this setting.

> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file

Most browsers treat downloaded HTML files as "dangerous downloads,"
which means they get similar UI treatment to executable downloads.
For example, on Mac OS X, HTML downloads get the same "you're about to
open a dangerous file" warning from the operating system as executable
downloads.  If the attacker can convince the the user to click past
these dialogs, the attacker can convince the user to run arbitrary
code anyway, so there's nothing we can do to provide security in this
setting.

> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com

This sounds like a security vulnerability in the browser.  A better
security posture is to not allow downloaded content from one web site
read downloaded content from another web site, regardless of how the
content was downloaded.  For example, that's the current behavior of
Chrome and Internet Explorer.  Safari takes a different approach and
allows downloaded HTML content to access any file and any web site,
which means the attacker doesn't need to go through the elaborate
process you've outlined.  Merely performing step (3) is sufficient to
steal all the user's banking details today, which tells me that either
Safari is already vulnerable to this attack without this new feature
or that this threat isn't actually much of a risk.

(I know that Firefox has a policy that's somewhere in between the
strong local-file security policy used by Chrome and the weak policy
used by Safari, but Firefox's policy is too complex for me to
understand.  I know that protection of downloaded files was one of the
considerations that fed into the design of Firefox's policy, but I'll
leave it to others to common on whether it provided effective
protection in this scenario.)

> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.

In that model, the attacker can just run arbitrary code.  It's not
possible to provide security in that model, regardless of this
feature.

> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.

In this case, the caveats are important.  As described above, Chrome
is not vulnerable to this attack and Safari is vulnerable to this
attack even without this feature.

> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.

I'm not convinced there's a problem to solve here.  Wiring CORS into
the download system, by contrast, add a significant amount of
complexity to the implementation, which is costly.

> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.

I'm happy to talk it over with your security folks if they disagree
with the contents of this email.

> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.

It's important to think these scenarios through carefully, but in this
case I think we're fine without CORS.

Adam


From jonas at sicking.cc  Sun Jul 17 13:50:23 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Sun, 17 Jul 2011 13:50:23 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E233AD4.4080302@gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<4E233AD4.4080302@gmail.com>
Message-ID: <CA+c2ei8xdOi+FULXRygcsNn41wnuEQUVzQY1PHTNR5MC3Qog8A@mail.gmail.com>

On Sun, Jul 17, 2011 at 12:41 PM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> ?ann f?s 15.j?l 2011 18:39, skrifa?i Jonas Sicking:
>>
>> 2011/7/14 Ian Fette (????????)<ifette at google.com>:
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party site. I.e. this would allow
>> evil.com to trick the user into downloading an email from the users
>> webmail, or download a page from their bank which contains all their
>> banking information. It might be easier to then trick the user into
>> re-uploading the saved file to evil.com since from a user's
>> perspective, it looked like the file came from evil.com
>>
> Would it not be possible to send an unauthenticated request for the
> file, if it's of different origin?

That only solves part of the problem since if the file is located on a
private intranet behind a firewall, even unauthenticated requests can
return sensitive data.

Additionally, I strongly suspect people will want to be able to
download authenticated data cross site.

/ Jonas


From svartman95 at gmail.com  Sun Jul 17 15:18:12 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 22:18:12 +0000
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E232BB4.9020604@cs.tut.fi>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>	<4E22ED32.5080807@cs.tut.fi>	<20110717170709.73ed9b15@desudesudesu>
	<4E232BB4.9020604@cs.tut.fi>
Message-ID: <4E235FA4.4040608@gmail.com>

?ann sun 17.j?l 2011 18:36, skrifa?i Jukka K. Korpela:
> 17.07.2011 18:07, Nils Dagsson Moskopp wrote:
>
> I think it would be rather trivial. The string ?ISBN? followed by
> something that matches the syntax of ISBN numbers, perhaps allowing some
> variation in punctuation, could be treated as an implicit link to a
> resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs.
>
> The key issue is whether browser vendors have interest in it and which
> mechanism(s) would be used. After all, an ISBN could be in a multitude
> of ways, like querying an online bookshop, querying an online
> bibliographic system, or querying an site of books in digital format
> online. Which one should be used? Would it be useful? To be really
> useful, it should be handled so that the browser checks what it can get
> using the ISBN and then make that information available to user (how to
> get bibliographic info, how to read reviews, how to buy the book, how to
> borrow it in a library, download or read the book via the net for free
> or for fee).
>
> I don?t think it?s much used in the wild, except on pages by
> organizations that define HTML specs. What might be the motivation for
> browsers to do something special with it? Surely you could make things
> so that by clicking on a blockquote, the user accesses the resource
> pointed to by the cite attribute. Browsers could do that, and so could
> authors. But would users actually start clicking on quotations to see
> their sources? Surely they would far more probably click on the title of
> a work in visible credits if present and if it is a link, so what would
> the cite attribute help?
>
Good point

> No, it?s not a category thing. It?s about the relativity of being
> ?machine-readable.? You are probably thinking of data in a specific
> format designed to be easily parseable and useable by computer software,
> such as a URL, an ISO 8601 date notation, or an XML tag. But browsers
> already do many kinds of heuristics, parsing data that doesn?t really
> match the specs.
>
You *could* interpret handwritten text on a piece of paper using a 
machine and parse it as HTML. I'm not volunteering for making a machine 
for that task.

> A title of a work is easily useable by software: put it inside quotation
> marks and throw it at Google, and the odds are that you get some useful
> links related to it, if there?s info on the work (and perhaps the work
> itself) on the web at all. Well, assuming that the title is relatively
> unique.
>

> Titles of works are often more useful in the long run than URLs. URLs
> change far too often when sites are revamped or for other reasons.
>
ISBNs are more useful in the long run than titles. Good titles get 
reused far too often.

> I think a good start would be to add an optional (but usually
> recommended) <credits> or <source> element for use inside <blockquote>.
>
What about the common case of multiple quotations credited to the same 
source (interleaved with comments).


From ben.schwarz at gmail.com  Sun Jul 17 15:46:16 2011
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Mon, 18 Jul 2011 08:46:16 +1000
Subject: [whatwg] Custom protocol handlers
Message-ID: <EC88788A9BC540669510CB476C6B8753@gmail.com>

After recently discovering custom protocol handlers[1], it struck me that it would be difficult to provide a decent user experience for those who used browsers which did not support the feature.

There have been previous calls to add further methods to the custom protocol ecosystem, such as a mozilla bug from 2008[2], and a separate discussion from January 2009[3]. However there?s been no solution, so I'd like to raise the issue of the registerProtocolHandler feature again.

Here are some user stories that I feel represent these issues:

1) 

As a web developer
I want to be able to tell when registration of protocols/schemes has either failed or been successful
So that I can provide a fluid user experience

2)
As a web developer
I want to be able to ascertain whether the user-agent supports the registerProtocolHandler feature
So that I can have an alternate experience for the user

Note: I have submitted a pull request to Modernizr to cover story #2[4], I left my story above for posterity. 

3) 
As a web designer / developer
I want to be able to ascertain if another website has registered a custom protocol handler in the user?s browser
So that I can knowingly design and implement an integration experience

4) 
As a web designer / developer
I want to be able to ascertain whether the user has "installed" a custom protocol handler within their operating system
So that I can knowingly design and implement an integration experience



Footnotes:

[1] http://updates.html5rocks.com/2011/06/Registering-a-custom-protocol-handler
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=440620
[3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/018101.html
[4] https://github.com/Modernizr/Modernizr/pull/324/files

Further feature reference:
? https://developer.mozilla.org/En/DOM/Window.navigator.registerProtocolHandler
? https://developer.mozilla.org/en/Web-based_protocol_handlers
? http://developers.whatwg.org/timers.html#custom-handlers


NB:

Thanks for the review from Mr Doug Schepers & Mr Oli Studholme

Cheers, 

Ben


From svartman95 at gmail.com  Sun Jul 17 16:10:55 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 17 Jul 2011 23:10:55 +0000
Subject: [whatwg] Custom protocol handlers
In-Reply-To: <EC88788A9BC540669510CB476C6B8753@gmail.com>
References: <EC88788A9BC540669510CB476C6B8753@gmail.com>
Message-ID: <4E236BFF.5090401@gmail.com>

?ann sun 17.j?l 2011 22:46, skrifa?i Ben Schwarz:
>
> 3)
> As a web designer / developer
> I want to be able to ascertain if another website has registered a custom protocol handler in the user?s browser
> So that I can knowingly design and implement an integration experience
>
> 4)
> As a web designer / developer
> I want to be able to ascertain whether the user has "installed" a custom protocol handler within their operating system
> So that I can knowingly design and implement an integration experience
>
Your requirements seem reasonable at first glance, but it's hard to tell 
if and how to give this information without a concrete example of how it 
is going to be used. How is designing and implementing an "integration 
experience" possible with the information that a competitor has 
registered a protocol handler?


From karger at mit.edu  Sun Jul 17 16:13:36 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 02:13:36 +0300
Subject: [whatwg] namespaces in html5
Message-ID: <4E236CA0.1080501@mit.edu>

Dear whatwg,

   I wish to submit a comment regarding the (non) use of namespaces in 
html5.  But I hope you might help me track down the relevant issue off 
which to hang that comment.  Some time ago I found a lengthy discussion 
of whether html5 should use namespaces, with an over-simplified summary 
being "we haven't seen any important use cases for them, so let's not 
bother".  I would like to respond to that discussion by proposing a use 
case, but I cannot find it.  Searching the bugzilla database has failed. 
  Would you happen to recall participating in this discussion and know 
where it is?

thanks
David Karger


From glenn at zewt.org  Sun Jul 17 20:05:14 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Sun, 17 Jul 2011 23:05:14 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
Message-ID: <CABirCh_5FtmESk6FBQEB=yBuwDEVBN1X_k7ELk6oz-icvqA5ig@mail.gmail.com>

2011/7/15 Ian Fette (????????) <ifette at google.com>

> I really don't see the importance of the "name the thing that isn't going
> to be downloaded" usecase; there are countless edge cases that we could
> concern ourselves with in HTML but that few users will ever hit, this is
> one.
>

A common case is generated PDFs, which are regularly both saved to disk and
viewed in-browser (eg. tax forms which are viewed to print and then saved
for records).

 (I also suspect a user sophisticated enough to actually save something,
> e.g. right click save as, is sophisticated enough to be able to type their
> own filename.)
>

As a user sophisticated enough to enter a filename, I still want the browser
to do it for me.  "The user can do it by hand" isn't an argument for
requiring them to.

You don't always need to "right click save as", either.  For example, a user
with no browser PDF support will generally receive a window like Firefox's
"open with/save as" prompt, which should also be able to use this as a hint,
without forcing users *with* browser PDF support to save to disk.
Similarly, dragging to the desktop, dragging into other applications, batch
downloading (eg. via DownThemAll), and so on.

I think it's better overall to keep the semantics as clean and simple as
> possible.
>

I don't think combining orthogonal concepts is clean or simple.  It seems
like a step back from Content-Disposition, where these concepts are already
cleanly separated.

(Sorry for pressing this point, since I don't feel extremely strongly about
it, but I just felt these arguments against it were a bit weak.)


2011/7/15 Darin Fisher <darin at chromium.org>:
> URLs (that are not backed by a single file).  This is valuable to me
because
> I can imagine wanting to save the contents of a <canvas>, and that
probably
> involves saving the data URL that you get from toDataURL().

You'd probably want Canvas.toBlob and FileSaver for this, once both are
implemented.

-- 
Glenn Maynard


From jonas at sicking.cc  Sun Jul 17 20:40:56 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Sun, 17 Jul 2011 20:40:56 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
Message-ID: <CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>

On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth <w3c at adambarth.com> wrote:
> 2011/7/15 Jonas Sicking <jonas at sicking.cc>:
>> We've discussed a different solution to the same problem at mozilla.
>> The solution we discussed was allowing FileSaver to in addition to
>> taking a blob argument, allow it to take a url argument.
>>
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party site. I.e. this would allow
>> evil.com to trick the user into downloading an email from the users
>> webmail, or download a page from their bank which contains all their
>> banking information. It might be easier to then trick the user into
>> re-uploading the saved file to evil.com since from a user's
>> perspective, it looked like the file came from evil.com
>
> It seems like the solution to that problem is to be clear about where
> the download is coming from. ?Being clear about where downloads come
> from is important in many scenarios, beyond just this setting.

Sure, I'm just not sure that we'll ever be able to get very high
percentage of people actually understanding and making sure they make
a informed decision based on this.

>> Another possible attack goes something like:
>> 1. evil.com tricks the user into downloading sensitive data from bank.com
>> 2. evil.com then asks the user to download a html from evil.com and
>> open the newly downloaded file
>
> Most browsers treat downloaded HTML files as "dangerous downloads,"
> which means they get similar UI treatment to executable downloads.
> For example, on Mac OS X, HTML downloads get the same "you're about to
> open a dangerous file" warning from the operating system as executable
> downloads. ?If the attacker can convince the the user to click past
> these dialogs, the attacker can convince the user to run arbitrary
> code anyway, so there's nothing we can do to provide security in this
> setting.
>
>> 3. the html file contains script which reads the contents from the
>> file downloaded from bank.com and sends it back to evil.com
>
> This sounds like a security vulnerability in the browser. ?A better
> security posture is to not allow downloaded content from one web site
> read downloaded content from another web site, regardless of how the
> content was downloaded. ?For example, that's the current behavior of
> Chrome and Internet Explorer. ?Safari takes a different approach and
> allows downloaded HTML content to access any file and any web site,
> which means the attacker doesn't need to go through the elaborate
> process you've outlined. ?Merely performing step (3) is sufficient to
> steal all the user's banking details today, which tells me that either
> Safari is already vulnerable to this attack without this new feature
> or that this threat isn't actually much of a risk.

That wasn't the security model IE used last I checked. At least at
that time it would refuse to run any scripts while displaying a
warning to the user telling them that they needed to opt-in to scripts
on the page. Opting in was a simple matter of pressing a "yes button"
though and so is something that a decent number of people likely will
do. However it's possible that IE has changed since then.

I just tried and this doesn't appear to be what chrome does. I'd love
to hear the details about chrome's strategy.

> (I know that Firefox has a policy that's somewhere in between the
> strong local-file security policy used by Chrome and the weak policy
> used by Safari, but Firefox's policy is too complex for me to
> understand. ?I know that protection of downloaded files was one of the
> considerations that fed into the design of Firefox's policy, but I'll
> leave it to others to common on whether it provided effective
> protection in this scenario.)

Firefox *basically* lets the page read the contents of the folder that
the html file is in, as well as any sub folders. There are some tricky
situations where more than that is allowed, but that's generally not
relevant to this discussion.

However since Firefox allows the page to read the contents of the same
folder, this means that the script would be allowed to read files
downloaded from other sites.

>> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> the browser. However it's well known that users very often hit
>> whichever button they suspect will make the dialog go away, rather
>> than actually read the contents of the dialog.
>
> In that model, the attacker can just run arbitrary code. ?It's not
> possible to provide security in that model, regardless of this
> feature.

I'm not quite sure what you mean here?

>> One very simple remedy to this would be to require CORS opt-in for
>> cross-site downloads. For same-site downloads no special opt-in would
>> be required of course.
>
> I'm not convinced there's a problem to solve here. ?Wiring CORS into
> the download system, by contrast, add a significant amount of
> complexity to the implementation, which is costly.

The fact that it's a bit more work for the browser implementation
seems like a good tradeoff if it means less data stolen from users. So
this isn't an argument that carries much weight for me.

>> It's also possible that it would be ok to do this without any opt-ins
>> since there are a good number of actions that the user has to take in
>> all these scenarios. Definitely something that I'd be ok with
>> discussing with our security team.
>
> I'm happy to talk it over with your security folks if they disagree
> with the contents of this email.

Sure, we can schedule a security review of this feature if this is a
route that we really want to go. I'll contact you off this list.

/ Jonas


From w3c at adambarth.com  Sun Jul 17 21:05:02 2011
From: w3c at adambarth.com (Adam Barth)
Date: Sun, 17 Jul 2011 21:05:02 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
Message-ID: <CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>

On Sun, Jul 17, 2011 at 8:40 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth <w3c at adambarth.com> wrote:
>> 2011/7/15 Jonas Sicking <jonas at sicking.cc>:
>>> We've discussed a different solution to the same problem at mozilla.
>>> The solution we discussed was allowing FileSaver to in addition to
>>> taking a blob argument, allow it to take a url argument.
>>>
>>> One concern which was brought up was the ability to cause the user to
>>> download a file from a third party site. I.e. this would allow
>>> evil.com to trick the user into downloading an email from the users
>>> webmail, or download a page from their bank which contains all their
>>> banking information. It might be easier to then trick the user into
>>> re-uploading the saved file to evil.com since from a user's
>>> perspective, it looked like the file came from evil.com
>>
>> It seems like the solution to that problem is to be clear about where
>> the download is coming from. ?Being clear about where downloads come
>> from is important in many scenarios, beyond just this setting.
>
> Sure, I'm just not sure that we'll ever be able to get very high
> percentage of people actually understanding and making sure they make
> a informed decision based on this.
>
>>> Another possible attack goes something like:
>>> 1. evil.com tricks the user into downloading sensitive data from bank.com
>>> 2. evil.com then asks the user to download a html from evil.com and
>>> open the newly downloaded file
>>
>> Most browsers treat downloaded HTML files as "dangerous downloads,"
>> which means they get similar UI treatment to executable downloads.
>> For example, on Mac OS X, HTML downloads get the same "you're about to
>> open a dangerous file" warning from the operating system as executable
>> downloads. ?If the attacker can convince the the user to click past
>> these dialogs, the attacker can convince the user to run arbitrary
>> code anyway, so there's nothing we can do to provide security in this
>> setting.
>>
>>> 3. the html file contains script which reads the contents from the
>>> file downloaded from bank.com and sends it back to evil.com
>>
>> This sounds like a security vulnerability in the browser. ?A better
>> security posture is to not allow downloaded content from one web site
>> read downloaded content from another web site, regardless of how the
>> content was downloaded. ?For example, that's the current behavior of
>> Chrome and Internet Explorer. ?Safari takes a different approach and
>> allows downloaded HTML content to access any file and any web site,
>> which means the attacker doesn't need to go through the elaborate
>> process you've outlined. ?Merely performing step (3) is sufficient to
>> steal all the user's banking details today, which tells me that either
>> Safari is already vulnerable to this attack without this new feature
>> or that this threat isn't actually much of a risk.
>
> That wasn't the security model IE used last I checked. At least at
> that time it would refuse to run any scripts while displaying a
> warning to the user telling them that they needed to opt-in to scripts
> on the page. Opting in was a simple matter of pressing a "yes button"
> though and so is something that a decent number of people likely will
> do. However it's possible that IE has changed since then.
>
> I just tried and this doesn't appear to be what chrome does. I'd love
> to hear the details about chrome's strategy.

Chrome treats every local HTML document as having a unique origin
(i.e., as defined by HTML5 for the sandbox attribute).  That means
local HTML files can't read other files in the user's file system,
including other downloads.  This policy makes some users sad, but we
feel the security benefits outweigh that amount of sadness.

>> (I know that Firefox has a policy that's somewhere in between the
>> strong local-file security policy used by Chrome and the weak policy
>> used by Safari, but Firefox's policy is too complex for me to
>> understand. ?I know that protection of downloaded files was one of the
>> considerations that fed into the design of Firefox's policy, but I'll
>> leave it to others to common on whether it provided effective
>> protection in this scenario.)
>
> Firefox *basically* lets the page read the contents of the folder that
> the html file is in, as well as any sub folders. There are some tricky
> situations where more than that is allowed, but that's generally not
> relevant to this discussion.
>
> However since Firefox allows the page to read the contents of the same
> folder, this means that the script would be allowed to read files
> downloaded from other sites.

There's no exception for the Downloads folder?  In that case, Firefox
is vulnerable to downloaded HTML documents (e.g., email attachments)
spying on all the user's other downloads (e.g., tax returns).  That
sounds like a vulnerability that should be fixed regardless of whether
we add this feature.

>>> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>>> the browser. However it's well known that users very often hit
>>> whichever button they suspect will make the dialog go away, rather
>>> than actually read the contents of the dialog.
>>
>> In that model, the attacker can just run arbitrary code. ?It's not
>> possible to provide security in that model, regardless of this
>> feature.
>
> I'm not quite sure what you mean here?

If the user is willing to "very often hit whatever button they suspect
will make the dialog go away," then the attacker can run arbitrary
code on their computer by triggering a download of an EXE and getting
the user to click through however many warnings stand between them an
running the EXE.  It's not an interesting model from a security point
of view.

Many browsers have similar warnings for running local HTML files
downloaded from the web as they do for running loaded EXEs.  For
example, compare the dialogs used for these purposes in Mac OS X.
They're identical for all intents and purposes.

My point is, either the attack you've outlined is already a problem
today or it's not a problem today, depending on which browser we
talking about on which operating system.  In either case, adding this
feature isn't really changing the security equation in any appreciable
way.

>>> One very simple remedy to this would be to require CORS opt-in for
>>> cross-site downloads. For same-site downloads no special opt-in would
>>> be required of course.
>>
>> I'm not convinced there's a problem to solve here. ?Wiring CORS into
>> the download system, by contrast, add a significant amount of
>> complexity to the implementation, which is costly.
>
> The fact that it's a bit more work for the browser implementation
> seems like a good tradeoff if it means less data stolen from users. So
> this isn't an argument that carries much weight for me.

There's also complexity for authors, who need to set the appropriate
headers and to worry about authenticated versus unauthenticated
requests.  Worse, in some deployment scenarios, requiring CORS to use
this feature actually exposes the sites to greater risk because they
might set ACLs on these resources that are broader than needed.
Here's an example:

1) A webmail service wants to offer attachments for download.
2) The webmail service is security conscious, so it renders email
messages in a sandboxed iframe in case it's email rendering contains
an XSS hole (which is quite possible, especially with rich-text, HTML
email).
3) The webmail service wants to include links to download email
attachments using this feature.

In order for the links to work (assuming the links appear in context
in the email, as they do in Outlook, for example), the webmail
provider needs to set CORS headers that grants the sandboxed iframe
access to the attachments.  Because the sandboxed iframe runs in a
unique origin (for maximum security), the only CORS ACL that works is
"Access-Control-Allow-Origin: *".  However, that ACL allows any other
web site to read the contents of the user's attachments!  Now, maybe
you could work around that issue using unguessable URLs for the
attachments, but you'd still be exposing the contents of the
attachments if there's an XSS in the mail rendering code, a
vulnerability that would not be present if the downloads feature
wasn't coupled to CORS.

In summary, using CORS for this purpose is costly (both to
implementors and to authors), and I don't think it solves a real
security problem.

Adam


From jkorpela at cs.tut.fi  Sun Jul 17 21:08:41 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Mon, 18 Jul 2011 07:08:41 +0300
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <4E235FA4.4040608@gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>	<CAE46406-D675-4428-B6B8-8511352AB696@opera.com>	<4E1ECE52.7090506@cs.tut.fi>	<4E1EEAAE.3050701@gmail.com>	<4E205398.9000905@cs.tut.fi>	<CAOKKrgMFS84iYCuPk3R0WoO5aSSkwdpzmnrus9-RuOeg6DJhxg@mail.gmail.com>	<4E22ED32.5080807@cs.tut.fi>	<20110717170709.73ed9b15@desudesudesu>
	<4E232BB4.9020604@cs.tut.fi> <4E235FA4.4040608@gmail.com>
Message-ID: <4E23B1C9.8030402@cs.tut.fi>

18.07.2011 01:18, Bjartur Thorlacius wrote:

>> Titles of works are often more useful in the long run than URLs. URLs
>> change far too often when sites are revamped or for other reasons.
>>
> ISBNs are more useful in the long run than titles. Good titles get
> reused far too often.

ISBNs have their uses (otherwise they wouldn?t be used), but they are 
codes, not names?suitable for use as unique identifiers, not in 
marketing and discussions. A quality quotation has credits that mention 
author, book title, book ISBN, and location within book. All this can be 
done in printed publications without any links or markup. So the 
adequate question is: which markup (if any) should we use for and within 
the credits?

I haven?t seen many attempts to address this question. Maybe it?s not 
that crucial, as proper credits work without markup too?markup could 
just be very useful enhancement. But <blockquote> as a semantic element 
is wishful thinking then.

HTML5 is currently making this a bit worse by explicitly forbidding 
<blockquite> from containing anything that doesn?t come from the 
external source, such as credits?without even telling how to deal with 
credits then.

>> I think a good start would be to add an optional (but usually
>> recommended) <credits> or <source> element for use inside <blockquote>.
>>
> What about the common case of multiple quotations credited to the same
> source (interleaved with comments).

People solve such issues every day when writing books and articles, 
using references to previous mentions of sources. At the shortest, ?op. 
cit.? In hypertext, the reference can be made to a link.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From ian at hixie.ch  Sun Jul 17 22:46:14 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 05:46:14 +0000 (UTC)
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E236CA0.1080501@mit.edu>
References: <4E236CA0.1080501@mit.edu>
Message-ID: <Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>

On Mon, 18 Jul 2011, David Karger wrote:
> 
>   I wish to submit a comment regarding the (non) use of namespaces in 
> html5. But I hope you might help me track down the relevant issue off 
> which to hang that comment.  Some time ago I found a lengthy discussion 
> of whether html5 should use namespaces, with an over-simplified summary 
> being "we haven't seen any important use cases for them, so let's not 
> bother".  I would like to respond to that discussion by proposing a use 
> case, but I cannot find it. Searching the bugzilla database has failed.  
> Would you happen to recall participating in this discussion and know 
> where it is?

You can just post a new thread here.

I recommend describing the problem you wish to address separately from 
your preferred solution. Also I recommend using a word other than 
"namespaces" to describe your preferred solution, as that word is usually 
used in the Web context to refer to some specific designs with known 
problems, and it is likely that you actually want something different.

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


From narendra at narendrasisodiya.com  Mon Jul 18 03:41:37 2011
From: narendra at narendrasisodiya.com (Narendra Sisodiya)
Date: Mon, 18 Jul 2011 16:11:37 +0530
Subject: [whatwg] HTML5 based Eduvid Slidecasting Demo
In-Reply-To: <BANLkTi=YdPFQ419anpK2Rx6B_r5gYV4xGQ@mail.gmail.com>
References: <BANLkTimHTmiyDipLLDh9aRK=xQvMvZOPew@mail.gmail.com>
	<BANLkTi=YdPFQ419anpK2Rx6B_r5gYV4xGQ@mail.gmail.com>
Message-ID: <CAB80A68pHSv8k-SXRbojwWEt0653F7Thqyn_=f_zVAeHvfJeRA@mail.gmail.com>

On Sun, May 22, 2011 at 3:20 AM, Narendra Sisodiya <
narendra at narendrasisodiya.com> wrote:

> I hope this demo will help to who who want html5 version of slidecasting
> technique.
> There is big room or improvement in the codebase.
>
> http://code.narendrasisodiya.com/slidecast/demo-slidecasting.html
>


Another Demo - Video + Slides -
http://code.narendrasisodiya.com/video-slidecast/demo.html
I have support for reading time.xml this time. over the time this will grow
and parser for handling a general purpose time.xml will be developed.

Blog Entry ->
http://blog.narendrasisodiya.com/2011/07/html5-based-video-slidecasting-demo.html


From ben.schwarz at gmail.com  Mon Jul 18 03:54:29 2011
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Mon, 18 Jul 2011 20:54:29 +1000
Subject: [whatwg] Custom protocol handlers
In-Reply-To: <4E236BFF.5090401@gmail.com>
References: <EC88788A9BC540669510CB476C6B8753@gmail.com>
	<4E236BFF.5090401@gmail.com>
Message-ID: <54F753D531494D9E90D4F7D67B5D6801@gmail.com>

Good feedback?The important detail of these stories was ambiguous:  

If I were to re-write it, I'd say:

3)
As a web designer / developer
I want to be able to ascertain if a custom protocol handler has been "installed" to the users browser
So that I can knowingly design and implement an integration experience



On Monday, 18 July 2011 at 9:10 AM, Bjartur Thorlacius wrote:

> ?ann sun 17.j?l 2011 22:46, skrifa?i Ben Schwarz:
> >  
> > 3)
> > As a web designer / developer
> > I want to be able to ascertain if another website has registered a custom protocol handler in the user?s browser
> > So that I can knowingly design and implement an integration experience
> >  
> > 4)
> > As a web designer / developer
> > I want to be able to ascertain whether the user has "installed" a custom protocol handler within their operating system
> > So that I can knowingly design and implement an integration experience
> Your requirements seem reasonable at first glance, but it's hard to tell  
> if and how to give this information without a concrete example of how it  
> is going to be used. How is designing and implementing an "integration  
> experience" possible with the information that a competitor has  
> registered a protocol handler?



From philipj at opera.com  Mon Jul 18 04:20:11 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Mon, 18 Jul 2011 13:20:11 +0200
Subject: [whatwg] Microdata - Handling the case where a string is
 upgraded to an object
In-Reply-To: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
References: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
Message-ID: <op.vyta3xunsr6mfa@kirk>

On Thu, 14 Jul 2011 20:49:44 +0200, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> Some IRC discussion this morning concerned the scenario where an API
> starts by exposing a property as a string, but later wants to change
> it to be a complex object.
>
> This appears to be a reasonably common scenario.  For example, a
> vocabulary with a "name" property may start with it being a string,
> and then later change to an object exposing "firstname"/"lastname"/etc
> properties.  A vocabulary for a music library may start by having
> "track" as a string, then later expanding it to expose the track
> title, the individual artist, the running time, etc.
>
> In a very similar vein, the CSSOM is currently defined to always
> return property values as strings.  We want to instead return complex
> objects that expose useful information and interfaces specialized on
> the value's type, however.  For compat reasons, we have to use an
> entirely different accessor in order to expose this type of thing.
>
> It seems that this may be a useful problem to solve in Microdata.  We
> can expose either an attribute or a privileged property name for the
> object's "name"/"title"/"string representation".  Then, when using the
> .items accessor, objects can be returned with a custom .toString that
> returns that value, so they can be used as strings in legacy code.
>
> Thoughts?

There is no items IDL attribute, do you mean getItems() or .itemValue  
perhaps?

I take it the problem is with code like this:

<div itemscope itemtype="person"><span itemprop="name">Foo  
Barsson</span></div>
<script>
var p = document.getItems("person")[0];
alert(p.properties.namedItem("name")[0].itemValue);
</script>

If the HTML changes to

<div itemscope itemtype="person"><span itemprop="name" itemscope><span  
itemprop="givenName">Foo</span> <span  
itemprop="familyName">Barsson</span></span></div>

then the script would be alerting "[object HTMLElement]" instead of "Foo  
Barsson".

I'm not sure why this would be a problem. If someone changes the page,  
then can't they adjust the script to match? Is it extensions and libraries  
that you're worried about?

As for the solution, are you suggesting that .itemValue return a special  
object which is like HTMLElement in all regards except for how it  
toString()s?

-- 
Philip J?genstedt
Core Developer
Opera Software


From tommyw at google.com  Mon Jul 18 05:17:17 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Mon, 18 Jul 2011 14:17:17 +0200
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
Message-ID: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>

I am very confused regarding the below paragraph from the latest spec:

When a track in a
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 parent is disabled, any
MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
 objects corresponding to the tracks in any
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 objects that were created from parent are disassociated from any track, and
must not be reused for tracks again. If a disabled track in a
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 parent is re-enabled, from the perspective of any
MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
 objects that were created from parent it is a new track and thus new
MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
 objects must be created for the tracks that correspond to the re-enabled
track.



After cloning a LocalMediaStream it looks like this:

LocalMediaStream -> MediaStream1
Track1(E)           Track1(E)
Track2(E)           Track2(E)
Track3(E)           Track3(E)

and as I interpret the spec it looks like this if Track1 in the
LocalMediaStream is disabled:

LocalMediaStream -> MediaStream1
Track1(D)           Track2(E)
Track2(E)           Track3(E)
Track3(E)

So Track1 disappears from the MediaStream1 object and doesn't come back even
if Track1 in the LMS object is enabled:

LocalMediaStream -> MediaStream1
Track1(E)           Track2(E)
Track2(E)           Track3(E)
Track3(E)

And to get it back again has to create a new MediaStream object from the
LMS:

LocalMediaStream -> MediaStream2
Track1(E)           Track1(E)
Track2(E)           Track2(E)
Track3(E)           Track3(E)

Is this interpretation correct?


/Tommy

 --
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.


From tommyw at google.com  Mon Jul 18 05:20:39 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Mon, 18 Jul 2011 14:20:39 +0200
Subject: [whatwg] Muting MediaStreamTracks?
Message-ID: <CALLKCfMV=D-ojvdsu1jicDu-TXqLTeO_imqgo8_QLzRN+JDWwg@mail.gmail.com>

The latest version of the spec mentions muting in several places, for
example:

 (Merely muted tracks are not removed, so the tracks do not change when the
parent is finished.)


But there are no mute operators in the idl definitions... How is the mute
function supposed to work?

/Tommy

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.


From harald at alvestrand.no  Mon Jul 18 05:29:26 2011
From: harald at alvestrand.no (Harald Alvestrand)
Date: Mon, 18 Jul 2011 14:29:26 +0200
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>
References: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>
Message-ID: <4E242726.4010701@alvestrand.no>

Additional question:

What is the scenario in which this behavioiur is useful?

On 07/18/11 14:17, Tommy Widenflycht (?????) wrote:
> I am very confused regarding the below paragraph from the latest spec:
>
> When a track in a
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   parent is disabled, any
> MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
>   objects corresponding to the tracks in any
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   objects that were created from parent are disassociated from any track, and
> must not be reused for tracks again. If a disabled track in a
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   parent is re-enabled, from the perspective of any
> MediaStream<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream>
>   objects that were created from parent it is a new track and thus new
> MediaStreamTrack<http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack>
>   objects must be created for the tracks that correspond to the re-enabled
> track.
>
>
>
> After cloning a LocalMediaStream it looks like this:
>
> LocalMediaStream ->  MediaStream1
> Track1(E)           Track1(E)
> Track2(E)           Track2(E)
> Track3(E)           Track3(E)
>
> and as I interpret the spec it looks like this if Track1 in the
> LocalMediaStream is disabled:
>
> LocalMediaStream ->  MediaStream1
> Track1(D)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)
>
> So Track1 disappears from the MediaStream1 object and doesn't come back even
> if Track1 in the LMS object is enabled:
>
> LocalMediaStream ->  MediaStream1
> Track1(E)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)
>
> And to get it back again has to create a new MediaStream object from the
> LMS:
>
> LocalMediaStream ->  MediaStream2
> Track1(E)           Track1(E)
> Track2(E)           Track2(E)
> Track3(E)           Track3(E)
>
> Is this interpretation correct?
>
>
> /Tommy
>
>   --
> Tommy Widenflycht, Senior Software Engineer
> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
> Org. nr. 556656-6880
> And yes, I have to include the above in every outgoing email according to EU
> law.
>




From aykut.sensoy at bild.de  Mon Jul 18 05:54:19 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Mon, 18 Jul 2011 12:54:19 +0000
Subject: [whatwg] date meta-tag invalid
Message-ID: <CA49FA02.10AEB%aykut.sensoy@bild.de>

According to the w3c Validator the  <metaname="date"content="#" /> tag is invalid. In the WHATWG MetaExtensions List there is no registered extension, no specification and no proposal for the date meta-tag.
The only alternative for "date" is a proposal called "created", which however doesn't meet the requirements for registration . For our SEO team the date meta-tag contains some of the most important information about a webpage.
What would be a w3c-valid way to implement a creation date meta-tag in html5?


Kind Regards
Aykut Sensoy


From mat at matcarey.co.uk  Mon Jul 18 06:06:02 2011
From: mat at matcarey.co.uk (Mat Carey)
Date: Mon, 18 Jul 2011 14:06:02 +0100
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA49FA02.10AEB%aykut.sensoy@bild.de>
References: <CA49FA02.10AEB%aykut.sensoy@bild.de>
Message-ID: <D06473CF-34AC-455C-914B-8AB51056CC59@matcarey.co.uk>

I'm not aware of the context, but is your problem the lack of spaces?

You said:

> <metaname="date"content="#" />

Did you mean:

<meta name="date" content="#" />

Mat Carey

On 18 Jul 2011, at 13:54, <aykut.sensoy at bild.de> wrote:

> According to the w3c Validator the  <metaname="date"content="#" /> tag is invalid. In the WHATWG MetaExtensions List there is no registered extension, no specification and no proposal for the date meta-tag.
> The only alternative for "date" is a proposal called "created", which however doesn't meet the requirements for registration . For our SEO team the date meta-tag contains some of the most important information about a webpage.
> What would be a w3c-valid way to implement a creation date meta-tag in html5?
> 
> 
> Kind Regards
> Aykut Sensoy



From julian.reschke at gmx.de  Mon Jul 18 06:27:37 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 18 Jul 2011 15:27:37 +0200
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA49FA02.10AEB%aykut.sensoy@bild.de>
References: <CA49FA02.10AEB%aykut.sensoy@bild.de>
Message-ID: <4E2434C9.6050502@gmx.de>

On 2011-07-18 14:54, aykut.sensoy at bild.de wrote:
> According to the w3c Validator the<metaname="date"content="#" />  tag is invalid. In the WHATWG MetaExtensions List there is no registered extension, no specification and no proposal for the date meta-tag.
> The only alternative for "date" is a proposal called "created", which however doesn't meet the requirements for registration . For our SEO team the date meta-tag contains some of the most important information about a webpage.
> What would be a w3c-valid way to implement a creation date meta-tag in html5?

Out of curiosity: who is processing the tag? And what does this have to 
do with SEO? Do search engines do anything with it?

 From HTML5's point of view the suggest replace is probably "<time 
pubdate>"... Did you look at that already?

Also: there seems to be overlap with Dublin Core's "dc:created"?

Best regards, Julian


From aykut.sensoy at bild.de  Mon Jul 18 06:49:50 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Mon, 18 Jul 2011 13:49:50 +0000
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <D06473CF-34AC-455C-914B-8AB51056CC59@matcarey.co.uk>
Message-ID: <CA4A0651.10AF6%aykut.sensoy@bild.de>

hi, this was only a mistake in the e-mail. you can see the meta-tag in the
source code live at www.stylebook.de

aykut



Am 18.07.11 15:06 schrieb "Mat Carey" unter <mat at matcarey.co.uk>:

>I'm not aware of the context, but is your problem the lack of spaces?
>
>You said:
>
>> <metaname="date"content="#" />
>
>Did you mean:
>
><meta name="date" content="#" />
>
>Mat Carey
>
>On 18 Jul 2011, at 13:54, <aykut.sensoy at bild.de> wrote:
>
>> According to the w3c Validator the  <metaname="date"content="#" /> tag
>>is invalid. In the WHATWG MetaExtensions List there is no registered
>>extension, no specification and no proposal for the date meta-tag.
>> The only alternative for "date" is a proposal called "created", which
>>however doesn't meet the requirements for registration . For our SEO
>>team the date meta-tag contains some of the most important information
>>about a webpage.
>> What would be a w3c-valid way to implement a creation date meta-tag in
>>html5?
>> 
>> 
>> Kind Regards
>> Aykut Sensoy
>



From aykut.sensoy at bild.de  Mon Jul 18 06:59:40 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Mon, 18 Jul 2011 13:59:40 +0000
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <4E2434C9.6050502@gmx.de>
Message-ID: <CA4A0848.10B0F%aykut.sensoy@bild.de>

hi julian,
i have asked one from the seo team and he says for example the "freshness
factor" is important for google.
is it possible to use the time-tag in the head instead (i mean invisible)?
dc:created is also not in the Meta Extensions List, see:
http://wiki.whatwg.org/wiki/MetaExtensions


Kind regards
Aykut



Am 18.07.11 15:27 schrieb "Julian Reschke" unter <julian.reschke at gmx.de>:

>On 2011-07-18 14:54, aykut.sensoy at bild.de wrote:
>> According to the w3c Validator the<metaname="date"content="#" />  tag
>>is invalid. In the WHATWG MetaExtensions List there is no registered
>>extension, no specification and no proposal for the date meta-tag.
>> The only alternative for "date" is a proposal called "created", which
>>however doesn't meet the requirements for registration . For our SEO
>>team the date meta-tag contains some of the most important information
>>about a webpage.
>> What would be a w3c-valid way to implement a creation date meta-tag in
>>html5?
>
>Out of curiosity: who is processing the tag? And what does this have to
>do with SEO? Do search engines do anything with it?
>
> From HTML5's point of view the suggest replace is probably "<time
>pubdate>"... Did you look at that already?
>
>Also: there seems to be overlap with Dublin Core's "dc:created"?
>
>Best regards, Julian



From julian.reschke at gmx.de  Mon Jul 18 07:11:56 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 18 Jul 2011 16:11:56 +0200
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA4A0848.10B0F%aykut.sensoy@bild.de>
References: <CA4A0848.10B0F%aykut.sensoy@bild.de>
Message-ID: <4E243F2C.2040605@gmx.de>

On 2011-07-18 15:59, aykut.sensoy at bild.de wrote:
> hi julian,
> i have asked one from the seo team and he says for example the "freshness
> factor" is important for google.
> is it possible to use the time-tag in the head instead (i mean invisible)?
> dc:created is also not in the Meta Extensions List, see:
> http://wiki.whatwg.org/wiki/MetaExtensions

I *believe* the SEO time is misguided when it thinks that 
meta/@name="date" affects Google. But only Google can tell us.

I mentioned dc:created not because it's valid, but because it's at least 
*specified* and in more wider use.

Best regards, Julian



From karger at mit.edu  Mon Jul 18 07:22:42 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 17:22:42 +0300
Subject: [whatwg] namespaces in html5
In-Reply-To: <Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
Message-ID: <4E2441B2.8040506@mit.edu>

OK, per Ian's suggestion I'm starting a new thread on a problem that I'd 
hoped html5 would solve for us.  As far as I know the problem still 
exists so I'm going to raise it here.  I'm coming late to the discussion 
so will surely retread old territory (for example, 
http://www.pacificspirit.com/blog/2008/03/13/namespaces_in_html_readings); 
my apologies for that.

I am one of the PIs on the SIMILE project (http://simile.mit.edu/) that 
developed the Exhibit data visualization framework 
(http://simile-widgets.org/exhibit).  The goal of Exhibit is to make it 
easy for non-programmers to embed interactive data visualizations in 
their web pages.  Our approach is to leverage the willingness of many 
non-programmers to author html (a key contributor to the early growth of 
the web).  To do so, Exhibit extends the html vocabulary with attributes 
that describe data, visualizations of that data, and interactions with 
that data.  For example, a tag of the form <div ex:role="view" 
ex:viewclass="timeline"> embeds a simile timeline in the html document, 
while <div ex:role="facet"> embeds a facet that can be used to filter 
the data being viewed in the timeline.  Exhibit offers a javascript 
library that interprets these tags and implements the requested widgets 
on the client side.

You will note that our special attributes use an "ex:" prefix.  This 
decision was taken in 2006, when it appeared that prefix-based 
namespaces were in HTML's future.  It addressed our concern that the new 
attributes we defined should not collide with those defined by other 
projects.  Now that namespaces apparently will not be part of html5, we 
are wondering how we can properly offer our extended html vocabulary.  
In particular, seems highly desirable for us to be able to write Exhibit 
pages using html that will validate.  Below I'll outline some of the 
characteristics of our desired solution, while emphasizing that we'd be 
happy to adopt _any_ solution with these characteristics, and are not 
wedded to namespaces.

I first justify our approach of html vocabulary extension.  A programmer 
can argue that a better approach is to offer our javascript library with 
a good api, and allow programmers to invoke our widgets programmatically 
in script tags.  This works fine for programmers, but excludes the large 
population of users who are afraid of programming but are willing to 
fiddle with html.  These users were a potent force in the early days of 
the web and we believe they continue to play an important role.  They 
may not even "know" html; the simplicity and regularity of the syntax 
allows them to copy, paste, and even modify page elements they like 
without fully understanding them.  Specifying data interactions in the 
more restricted html syntax instead of programmatic javascript also 
opens up the possibility for more effective semantics; for example, it 
is easier for a browser to offer an accessible version of a 
data-filtering facet if it is explicitly named as a facet rather than 
being arbitrary embedded javascript code.

If we accept the need for html language extensibility, there are several 
potential approaches.  One is html polyglot.  Permitting a blended 
html/xml representation, polyglot would allow us to extend the 
vocabulary via xml namespaces.  But polyglot fails to meet our need in 
fatal ways.  Polyglot restricts the html that can be used, for example 
excluding the use of <noscript> tags.  Such tags are essential when 
using Exhibit, since we want to offer some information presentation for 
the case when our visualization javascript is unable to execute.  More 
generally, polyglot appears to demand much more rigid fidelity to 
precise html/xml syntax, for example demanding tbody and colgroup tags 
where they are optional in html.  This is something that the novice 
"programmers" we are targeting are particularly bad at.  One of the real 
accomplishments of html has been the great efforts of the browser 
developers to robustly handle invalid html.  We want to continue to 
benefit from that effort instead of having pages fail because xml 
parsing is performed much more rigidly than html parsing.

Another approach would be to use the catchall html5 data- prefix for 
attributes.  We could certainly prefix all of our specialized attributes 
with the data- prefix, which would turn those attributes valid for 
html.  This solution is unsatisfactory for two reasons.  The first is 
that our attributes are not data attributes----we are not using 
microformat-oriented data attributes; rather, we are using attributes 
that describe visualizations.  data- seems a poor choice of prefix.  The 
second problem that concerns me is attribute collisions.  If we use an 
attribute like data-role="view", how long will it be before an exhibit 
author runs into a situation where a different javascript library is 
using the same data-role attribute for a different purpose, which would 
make the two libraries incompatible with one another?

In 2006, the predicted namespace prefixes seemed an obvious solution to 
our problem: we would define a namespace for our Exhibit framework, and 
our javascript would only pay attention to attributes from that 
namespace.  I have no specific loyalty to namespaces, but I am really 
hopeful that html5 will offer us a solution that reflects the issues I 
outlined above, namely:
* allow extension of them html5 vocabulary with attributes Exhibit will 
use to anchor visualizations,
* such that the resulting html will validate,
* without requiring rigid obedience to the challenging html polyglot 
syntax, which is beyond the capabilities of our target novice web authors
* and protecting us from a future in which collisions on choice of 
attribute names make our library/vocabulary incompatible with others'

On 7/18/2011 8:46 AM, Ian Hickson wrote:
> On Mon, 18 Jul 2011, David Karger wrote:
>>    I wish to submit a comment regarding the (non) use of namespaces in
>> html5. But I hope you might help me track down the relevant issue off
>> which to hang that comment.  Some time ago I found a lengthy discussion
>> of whether html5 should use namespaces, with an over-simplified summary
>> being "we haven't seen any important use cases for them, so let's not
>> bother".  I would like to respond to that discussion by proposing a use
>> case, but I cannot find it. Searching the bugzilla database has failed.
>> Would you happen to recall participating in this discussion and know
>> where it is?
> You can just post a new thread here.
>
> I recommend describing the problem you wish to address separately from
> your preferred solution. Also I recommend using a word other than
> "namespaces" to describe your preferred solution, as that word is usually
> used in the Web context to refer to some specific designs with known
> problems, and it is likely that you actually want something different.
>


From annevk at opera.com  Mon Jul 18 07:28:44 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 18 Jul 2011 16:28:44 +0200
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E2441B2.8040506@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu>
Message-ID: <op.vytjt6x264w2qv@annevk-macbookpro.local>

On Mon, 18 Jul 2011 16:22:42 +0200, David Karger <karger at mit.edu> wrote:
> Another approach would be to use the catchall html5 data- prefix for  
> attributes.  We could certainly prefix all of our specialized attributes  
> with the data- prefix, which would turn those attributes valid for  
> html.  This solution is unsatisfactory for two reasons.  The first is  
> that our attributes are not data attributes----we are not using  
> microformat-oriented data attributes; rather, we are using attributes  
> that describe visualizations.  data- seems a poor choice of prefix.  The  
> second problem that concerns me is attribute collisions.  If we use an  
> attribute like data-role="view", how long will it be before an exhibit  
> author runs into a situation where a different javascript library is  
> using the same data-role attribute for a different purpose, which would  
> make the two libraries incompatible with one another?

You could use data-exhibit-* as the specification suggests. Potentially  
including the ability for the web author to override the "exhibit"  
constant.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From hsivonen at iki.fi  Mon Jul 18 07:32:41 2011
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 18 Jul 2011 16:32:41 +0200
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA4A0848.10B0F%aykut.sensoy@bild.de>
References: <CA4A0848.10B0F%aykut.sensoy@bild.de>
Message-ID: <1310999561.2813.4.camel@shuttle>

On Mon, 2011-07-18 at 13:59 +0000, aykut.sensoy at bild.de wrote:
> i have asked one from the seo team and he says for example the "freshness
> factor" is important for google.

Is there evidence of <meta name="date" content="..."> being part of
Google's freshness factor? Is there public documentation explaining what
<meta name="date" content="..."> means, what date format expected in the
content attribute is and what software does something useful with it?

> is it possible to use the time-tag in the head instead (i mean invisible)?

No, it's not.

> dc:created is also not in the Meta Extensions List, see:
> http://wiki.whatwg.org/wiki/MetaExtensions

It simply hasn't been registered yet. Is there any evidence of consuming
software that does something useful with dc:created?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From karger at mit.edu  Mon Jul 18 07:33:47 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 17:33:47 +0300
Subject: [whatwg] namespaces in html5
In-Reply-To: <op.vytjt6x264w2qv@annevk-macbookpro.local>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu>
	<op.vytjt6x264w2qv@annevk-macbookpro.local>
Message-ID: <4E24444B.1040109@mit.edu>

Yes, we could,  but it doesn't address the two objections I raised to 
data- prefix:
1.  it isn't actually a data attribute, so prefixing with data seems 
odd (appearance; minor)
2.  there's no way to guarantee someone else won't use the same 
data-exhibit prefix, causing incompatibilities (functionality; major)

On Monday, July 18, 2011 5:28:44 PM, Anne van Kesteren wrote:
> On Mon, 18 Jul 2011 16:22:42 +0200, David Karger <karger at mit.edu> wrote:
>> Another approach would be to use the catchall html5 data- prefix for 
>> attributes. We could certainly prefix all of our specialized 
>> attributes with the data- prefix, which would turn those attributes 
>> valid for html. This solution is unsatisfactory for two reasons. The 
>> first is that our attributes are not data attributes----we are not 
>> using microformat-oriented data attributes; rather, we are using 
>> attributes that describe visualizations. data- seems a poor choice of 
>> prefix. The second problem that concer
ns me is attribute collisions. 
>> If we use an attribute like data-role="view", how long will it be 
>> before an exhibit author runs into a situation where a different 
>> javascript library is using the same data-role attribute for a 
>> different purpose, which would make the two libraries incompatible 
>> with one another?
> 
> You could use data-exhibit-* as the specification suggests. Potentially 
> including the ability for the web author to override the "exhibit" 
> constant.


From annevk at opera.com  Mon Jul 18 07:47:40 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 18 Jul 2011 16:47:40 +0200
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E24444B.1040109@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
Message-ID: <op.vytkpqc664w2qv@annevk-macbookpro.local>

On Mon, 18 Jul 2011 16:33:47 +0200, David Karger <karger at mit.edu> wrote:
> Yes, we could,  but it doesn't address the two objections I raised to  
> data- prefix:
> 1.  it isn't actually a data attribute, so prefixing with data seems odd  
> (appearance; minor)

It is custom data implemented by a JavaScript library. Seems like a  
perfect fit.


> 2.  there's no way to guarantee someone else won't use the same  
> data-exhibit prefix, causing incompatibilities (functionality; major)

"exhibit" plus the ability for authors to configure that word should be  
enough to prevent problems. But I doubt you will get prefix clashes in  
practice.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From ap at webkit.org  Mon Jul 18 08:58:35 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Mon, 18 Jul 2011 08:58:35 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
Message-ID: <0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>


17.07.2011, ? 21:05, Adam Barth ???????(?):

> In summary, using CORS for this purpose is costly (both to
> implementors and to authors), and I don't think it solves a real
> security problem.


Agreed. This feature basically gives authors two abilities: (1) force downloading of resources that would be displayed inline otherwise, and (2) rename them on the fly. Neither is what a site operator adding CORS headers e.g. for WebGL textures would think they're allowing.

A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.

Perhaps an author who has not been given permission to change server HTTP responses is not trusted enough to change them via HTML either. 

- WBR, Alexey Proskuryakov



From jonas at sicking.cc  Mon Jul 18 09:20:13 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 18 Jul 2011 09:20:13 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
Message-ID: <CA+c2ei-9TnVEQDgeJ2wvU4BfW0pSznad1-iOHSULbBUW0Nmaiw@mail.gmail.com>

On Mon, Jul 18, 2011 at 8:58 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> 17.07.2011, ? 21:05, Adam Barth ???????(?):
>
>> In summary, using CORS for this purpose is costly (both to
>> implementors and to authors), and I don't think it solves a real
>> security problem.
>
>
> Agreed. This feature basically gives authors two abilities: (1) force downloading of resources that would be displayed inline otherwise, and (2) rename them on the fly. Neither is what a site operator adding CORS headers e.g. for WebGL textures would think they're allowing.
>
> A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.
>
> Perhaps an author who has not been given permission to change server HTTP responses is not trusted enough to change them via HTML either.

Any site that want to allow downloads without risking sharing data can
simply add "content-disposition: attached" headers. So no risk of
leaking too much data required.

/ Jonas


From glenn at zewt.org  Mon Jul 18 09:35:51 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 18 Jul 2011 12:35:51 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
Message-ID: <CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>

On Mon, Jul 18, 2011 at 11:58 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> A different scenario which I don't think has been discussed in this thread
is bypassing a hosting service security settings. Consider a highly
reputable hosting that doesn't let you upload executable files (or maybe
just scans those for malware if uploaded). With @download, one could bypass
that, and make users download or even run an .EXE file by following an
innocuous link to a well known domain. This kind of download could be same
origin or cross origin.

The service hosting the file--the target of the link--shouldn't convey
trust.  The page containing the download link is where trust should come
from, not the link target.

For example, if I have a link on my site to download Chrome, I'm not going
to link directly to the installer on google.com; I'll link to Google's
"Download Chrome" site.  The actual download link the user follows is not
only pointing to google.com, but is linked from there as well.  I expect
that most users will trust the download not because of where the download
link goes, but where it comes from.

If I link directly to the file to download, users should trust the file as
much as they trust *my* site, rather than Google itself, since the download
is, from their perspective, coming from me and not them.  Similarly, if a
site uses a mysterious CDN or an Amazon S3 link, that shouldn't affect
trust; if www.google.com/chrome puts the file itself on
mysteriousgooglecdn.com, it should be no less trusted than if it was from a
google.com subdomain.  That difference should be transparent to users.

(This is why it's okay that Firefox's open/save dialog shows the link target
in a minor, easily-ignored bit of text--it's not important information for
most users.  Chrome doesn't even show that.)

So, if a hosting service doesn't want to allow executable files, it won't
show files as executable from their own download pages, which is what should
matter as far as that site's trust is concerned.  People using this
mechanism to serve executable files from external links may be annoying, but
it shouldn't cause trust issues.

-- 
Glenn Maynard


From anant at mozilla.com  Mon Jul 18 09:56:26 2011
From: anant at mozilla.com (Anant Narayanan)
Date: Mon, 18 Jul 2011 09:56:26 -0700
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <4E242726.4010701@alvestrand.no>
References: <CALLKCfPqzysAWubpM5d8iG8AsF-rNNdYPKL3HF=jm2QkiLbg1g@mail.gmail.com>
	<4E242726.4010701@alvestrand.no>
Message-ID: <4E2465BA.4070801@mozilla.com>

On 7/18/11 5:29 AM, Harald Alvestrand wrote:
> Additional question:
>
> What is the scenario in which this behavioiur is useful?

One use case is to selectively disable the video track in an ongoing 
audio/video session without disrupting audio in reaction to a congested 
network.

-Anant


From jackalmage at gmail.com  Mon Jul 18 10:53:32 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 18 Jul 2011 10:53:32 -0700
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E24444B.1040109@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
Message-ID: <CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>

On Mon, Jul 18, 2011 at 7:33 AM, David Karger <karger at mit.edu> wrote:
> Yes, we could, ?but it doesn't address the two objections I raised to data-
> prefix:
> 1. ?it isn't actually a data attribute, so prefixing with data seems odd
> (appearance; minor)

You seem to have mentally associated the data-* attributes with
Microdata.  There is no connection between them.  In fact, it's
impossible for Microdata to use the data-* attributes at all.

data-* attributes are for private script data that is, for whatever
reason, more convenient to attach directly to a DOM node than to hold
in a JS structure.  Wanting the data's link to DOM nodes to survive
serialization is a good reason.


> 2. ?there's no way to guarantee someone else won't use the same data-exhibit
> prefix, causing incompatibilities (functionality; major)

In practice, the risk of prefix collisions has turned out to be
minimal in many real-world collections, such as jQuery plugins.  We
expect the same to apply here.  For maximum robustness, simply write
your library with the ability to accept a different prefix, so that if
a collision does occur the author can work around it.

~TJ


From karger at mit.edu  Mon Jul 18 11:23:52 2011
From: karger at mit.edu (David Karger)
Date: Mon, 18 Jul 2011 21:23:52 +0300
Subject: [whatwg] namespaces in html5
In-Reply-To: <CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu>
	<op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
	<CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>
Message-ID: <4E247A38.4070304@mit.edu>

The html5 spec states that
>
> Custom data attributes 
> <http://dev.w3.org/html5/spec/elements.html#custom-data-attribute> are 
> intended to store custom data private to the page or application, for 
> which there are no more appropriate attributes or elements.
>
> These attributes are not intended for use by software that is 
> independent of the site that uses the attributes.
>
and further
>
> It would be inappropriate, however, for the user to use _generic 
> software not associated with_ that music site to search for tracks of 
> a certain length by looking at this data.
>
> This is because these attributes are intended for use by the site's 
> own scripts, and are not a generic extension mechanism for 
> publicly-usable metadata.
>

As I interpret these words, data- attributes are intended to be 
delivered by a server for use by the javascript code that server 
delivers with the page.

The exhibit attributes are not associated with any server, and are not 
associated with any particular data items being delivered by any 
server.  Rather, they are part of  "generic software not associated 
with" the server (see quote above)  and handle _presentation_ of the 
content on the page.

So, while it might be technically valid to use data- prefixes, it 
doesn't seem to fit the intention.


On 7/18/2011 8:53 PM, Tab Atkins Jr. wrote:
> On Mon, Jul 18, 2011 at 7:33 AM, David Karger<karger at mit.edu>  wrote:
>> Yes, we could,  but it doesn't address the two objections I raised to data-
>> prefix:
>> 1.  it isn't actually a data attribute, so prefixing with data seems odd
>> (appearance; minor)
> You seem to have mentally associated the data-* attributes with
> Microdata.  There is no connection between them.  In fact, it's
> impossible for Microdata to use the data-* attributes at all.
>
> data-* attributes are for private script data that is, for whatever
> reason, more convenient to attach directly to a DOM node than to hold
> in a JS structure.  Wanting the data's link to DOM nodes to survive
> serialization is a good reason.
>
>
>> 2.  there's no way to guarantee someone else won't use the same data-exhibit
>> prefix, causing incompatibilities (functionality; major)
> In practice, the risk of prefix collisions has turned out to be
> minimal in many real-world collections, such as jQuery plugins.  We
> expect the same to apply here.  For maximum robustness, simply write
> your library with the ability to accept a different prefix, so that if
> a collision does occur the author can work around it.
>
> ~TJ


From ian at hixie.ch  Mon Jul 18 11:33:28 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 18:33:28 +0000 (UTC)
Subject: [whatwg] Muting MediaStreamTracks?
In-Reply-To: <CALLKCfMV=D-ojvdsu1jicDu-TXqLTeO_imqgo8_QLzRN+JDWwg@mail.gmail.com>
References: <CALLKCfMV=D-ojvdsu1jicDu-TXqLTeO_imqgo8_QLzRN+JDWwg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107181831590.3775@ps20323.dreamhostps.com>

On Mon, 18 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
>
> The latest version of the spec mentions muting in several places, for 
> example:
> 
>  (Merely muted tracks are not removed, so the tracks do not change when 
> the parent is finished.)
> 
> But there are no mute operators in the idl definitions... How is the 
> mute function supposed to work?

A MediaStream object has an input and an output. The input depends on how 
the object was created: a LocalMediaStream object generated by a 
getUserMedia() call, for instance, might take its input from the user's 
local camera, while a MediaStream created by a PeerConnection object will 
take as input the data received from a remote peer. The output of the 
object controls how the object is used, e.g. what is saved if the object 
is written to a file, what is displayed if the object is used in a video 
element, or indeed what is transmitted to a remote peer if the object is 
used with a PeerConnection object.

Each track in a MediaStream object can be disabled, meaning that it is 
muted in the object's output. All tracks are initially enabled.

A MediaStream can be finished, indicating that its inputs have forever 
stopped providing data. When a MediaStream object is finished, all its 
tracks are muted regardless of whether they are enabled or disabled.

The MediaStreamTrack.enabled attribute, on getting, must return the last 
value to which it was set. On setting, it must be set to the new value, 
and then, if the MediaStreamTrack object is still associated with a track, 
must enable the track if the new value is true, and disable it otherwise.

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

From ian at hixie.ch  Mon Jul 18 11:38:52 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 18:38:52 +0000 (UTC)
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <4E242D26.3030401@alvestrand.no>
References: <4E242D26.3030401@alvestrand.no>
Message-ID: <Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>

On Mon, 18 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
>
> I am very confused regarding the below paragraph from the latest spec:
> 
> When a track in a MediaStream parent is disabled, any MediaStreamTrack 
> objects corresponding to the tracks in any MediaStream objects that were 
> created from parent are disassociated from any track, and must not be 
> reused for tracks again. If a disabled track in a MediaStream parent is 
> re-enabled, from the perspective of any MediaStream objects that were 
> created from parent it is a new track and thus new MediaStreamTrack 
> objects must be created for the tracks that correspond to the re-enabled 
> track.
> 
> After cloning a LocalMediaStream it looks like this:
> 
> LocalMediaStream -> MediaStream1
> Track1(E)           Track1(E)
> Track2(E)           Track2(E)
> Track3(E)           Track3(E)
> 
> and as I interpret the spec it looks like this if Track1 in the 
> LocalMediaStream is disabled:
> 
> LocalMediaStream -> MediaStream1
> Track1(D)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)

Correct so far (though I'd avoid the term "cloning" since it's not quite 
what's going on here -- the spec uses "forking", which may be closer 
though is still not ideal).


> So Track1 disappears from the MediaStream1 object and doesn't come back 
> even if Track1 in the LMS object is enabled:
>
> LocalMediaStream -> MediaStream1
> Track1(E)           Track2(E)
> Track2(E)           Track3(E)
> Track3(E)

No, it'll create a new track object:

 LocalMediaStream -> MediaStream1
 Track1(E)           Track4(E)
 Track2(E)           Track2(E)
 Track3(E)           Track3(E)

This is specified in the sentence that starts "If a disabled track in a 
MediaStream parent is re-enabled...".

If you could explain how you are interpreting the current text I would be 
happy to fix the problematic area to be clearer (it's not clear to me 
what's unclear at the moment).


On Mon, 18 Jul 2011, Harald Alvestrand wrote:
> 
> What is the scenario in which this behavioiur is useful?

The muting feature exists in order to allow authors to mute outgoing video 
while leaving outgoing audio and while still having a local video montior.

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

From Simetrical+w3c at gmail.com  Mon Jul 18 12:20:21 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 18 Jul 2011 15:20:21 -0400
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E24444B.1040109@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
Message-ID: <CAKA+Axk1KiQxGMPB-udnZxr9mTusHpkK1vFc5BmGXE3_EhcH2A@mail.gmail.com>

On Mon, Jul 18, 2011 at 10:33 AM, David Karger <karger at mit.edu> wrote:
> Yes, we could, ?but it doesn't address the two objections I raised to data-
> prefix:
> 1. ?it isn't actually a data attribute, so prefixing with data seems odd
> (appearance; minor)

It's "data" in the sense that it's being used to just store some info
in the DOM without asking the browser to do anything extra with it.

> 2. ?there's no way to guarantee someone else won't use the same data-exhibit
> prefix, causing incompatibilities (functionality; major)

There's also no way to guarantee someone else won't use the same URL
for their namespace.  But in either case, they almost certainly won't.
 If you're really paranoid, feel free to stick a GUID or domain name
or something inside the names of all your data attributes.  But the
probability data-exhibit-* will ever collide with anything is already
negligible.

On Mon, Jul 18, 2011 at 2:23 PM, David Karger <karger at mit.edu> wrote:
> As I interpret these words, data- attributes are intended to be delivered by
> a server for use by the javascript code that server delivers with the page.
>
> The exhibit attributes are not associated with any server, and are not
> associated with any particular data items being delivered by any server.
> ?Rather, they are part of ?"generic software not associated with" the server
> (see quote above) ?and handle _presentation_ of the content on the page.
>
> So, while it might be technically valid to use data- prefixes, it doesn't
> seem to fit the intention.

I don't get how you're using these attributes.  Do you expect
browsers, search engines, or other consumers of HTML to treat them
differently from any unrecognized attribute?  Or do you intend that
the attributes only be used by the scripts/stylesheets/etc. provided
by your own site?  If your use-case is the former, then you should
propose the attributes for standardization.  If the latter, it's
exactly what data-* was designed for.


From jackalmage at gmail.com  Mon Jul 18 12:29:07 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 18 Jul 2011 12:29:07 -0700
Subject: [whatwg] namespaces in html5
In-Reply-To: <4E247A38.4070304@mit.edu>
References: <4E236CA0.1080501@mit.edu>
	<Pine.LNX.4.64.1107180544211.3775@ps20323.dreamhostps.com>
	<4E2441B2.8040506@mit.edu> <op.vytjt6x264w2qv@annevk-macbookpro.local>
	<4E24444B.1040109@mit.edu>
	<CAAWBYDB=14ubLji8xsDY-A=iQCH2RzS0=KJBu0MV6TgzyhwA7Q@mail.gmail.com>
	<4E247A38.4070304@mit.edu>
Message-ID: <CAAWBYDA4xEK_C0rs6On=dZEuo97wOceJfEsf7UwX4UcpG=TkTw@mail.gmail.com>

On Mon, Jul 18, 2011 at 11:23 AM, David Karger <karger at mit.edu> wrote:
> The exhibit attributes are not associated with any server, and are not
> associated with any particular data items being delivered by any server.
> Rather, they are part of? "generic software not associated with" the server
> (see quote above)? and handle _presentation_ of the content on the page.
>
> So, while it might be technically valid to use data- prefixes, it doesn't
> seem to fit the intention.

As far as I can tell, the exhibit attributes are designed solely to be
read by the exhibit JS library which creates special views of the
data.  The site embeds that library, and so it's part of the site.

The restrictions there are meant to restrict things like, for example,
embedding Microformats data with data-* attributes, with the intention
that they'll be read by spiders and other things outside of the page
author's control.

~TJ


From jackalmage at gmail.com  Mon Jul 18 13:01:37 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 18 Jul 2011 13:01:37 -0700
Subject: [whatwg] Microdata - Handling the case where a string is
 upgraded to an object
In-Reply-To: <op.vyta3xunsr6mfa@kirk>
References: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
	<op.vyta3xunsr6mfa@kirk>
Message-ID: <CAAWBYDC1z2HFrjxk5bqwA80+9mj3Awkx9=BZWsoKHvPDudxP2w@mail.gmail.com>

On Mon, Jul 18, 2011 at 4:20 AM, Philip J?genstedt <philipj at opera.com> wrote:
> There is no items IDL attribute, do you mean getItems() or .itemValue
> perhaps?

Yes, sorry.


> I take it the problem is with code like this:
>
> <div itemscope itemtype="person"><span itemprop="name">Foo
> Barsson</span></div>
> <script>
> var p = document.getItems("person")[0];
> alert(p.properties.namedItem("name")[0].itemValue);
> </script>
>
> If the HTML changes to
>
> <div itemscope itemtype="person"><span itemprop="name" itemscope><span
> itemprop="givenName">Foo</span> <span
> itemprop="familyName">Barsson</span></span></div>
>
> then the script would be alerting "[object HTMLElement]" instead of "Foo
> Barsson".
>
> I'm not sure why this would be a problem. If someone changes the page, then
> can't they adjust the script to match?

That only works if the page is using its own Microdata, not if someone
else is consuming the Microdata.

> Is it extensions and libraries that
> you're worried about?

Yeah.  I suspect this kind of API change is relatively common, and
it's the sort of thing that would *always* be painful.

> As for the solution, are you suggesting that .itemValue return a special
> object which is like HTMLElement in all regards except for how it
> toString()s?

Yes.

~TJ


From ian at hixie.ch  Mon Jul 18 14:13:42 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jul 2011 21:13:42 +0000 (UTC)
Subject: [whatwg] onForward and onBackward event and enable/disable
 Forward and Backward buttons.
In-Reply-To: <BANLkTikXzXygnh2PSaSe55fNOdCix_iJTw@mail.gmail.com>
References: <BANLkTi=mxPQnOZDtKDoc6ZeU2SwGXyDT4Q@mail.gmail.com>
	<1302966847.3322.12.camel@localhost.localdomain>
	<BANLkTikXzXygnh2PSaSe55fNOdCix_iJTw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107182112210.2079@ps20323.dreamhostps.com>

On Sat, 16 Apr 2011, Biju wrote:
> 
> So I want to suggest we should add onBackward and onForward events for
> a page which will be triggered when user click the Backward  or
> Forward button.

We essentially already have this ability using onpopstate and 
onhashchange. It lets authors hook into the session history and makes 
things work. Before we add more features along these lines, we should wait 
to see how authors are adopting the feature we already have.

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


From dglazkov at chromium.org  Mon Jul 18 19:55:20 2011
From: dglazkov at chromium.org (Dimitri Glazkov)
Date: Mon, 18 Jul 2011 19:55:20 -0700
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <op.vw8kp9oate2ec8@aimac.local>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
Message-ID: <CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>

I actually really like this proposal.

Let's do this. Roland, Dave, Boris -- what do y'all think?

:DG<

On Fri, Jun 17, 2011 at 1:04 PM, Kornel Lesi?ski <kornel at geekhood.net> wrote:
> On Thu, 16 Jun 2011 19:32:42 +0100, Dimitri Glazkov <dglazkov at chromium.org>
> wrote:
>
>> What if we do this:
>>
>> 1) By default, <style scoped> implies that all selectors in this
>> stylesheet are prefixed with ":scope".
>> 2) Unless the ":scope" is already in the selector.
>
> That feels magical and a bit backwards to me.
>
> Why not scope all selectors except ones starting with :root?
>
> .foo {scoped}
>
> :root .foo {matches outside scope}
>
> --
> regards, Kornel Lesi?ski
>


From bzbarsky at MIT.EDU  Mon Jul 18 20:40:44 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 18 Jul 2011 23:40:44 -0400
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>	<4DF9C8C9.3090805@lachy.id.au>	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
Message-ID: <4E24FCBC.6060402@mit.edu>

On 7/18/11 10:55 PM, Dimitri Glazkov wrote:
> I actually really like this proposal.
>
> Let's do this. Roland, Dave, Boris -- what do y'all think?

The proposal being that all selectors are scoped except the ones where 
:root is present in the first sequence of simple selectors (not quite 
what Kornel said, but I think that's what he meant)?

That seems ok to me, I think.  David, thoughts?

-Boris


From rolandsteiner at google.com  Mon Jul 18 21:10:16 2011
From: rolandsteiner at google.com (Roland Steiner)
Date: Tue, 19 Jul 2011 13:10:16 +0900
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E24FCBC.6060402@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
Message-ID: <CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>

On Tue, Jul 19, 2011 at 12:40 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/18/11 10:55 PM, Dimitri Glazkov wrote:
>
>> I actually really like this proposal.
>>
>> Let's do this. Roland, Dave, Boris -- what do y'all think?
>>
>
> The proposal being that all selectors are scoped except the ones where
> :root is present in the first sequence of simple selectors (not quite what
> Kornel said, but I think that's what he meant)?
>
> That seems ok to me, I think.  David, thoughts?
>

Just to nail this down:

foo .bar
    scoped, foo must be the scope element or a descendant

:root foo .bar
    NOT scoped, foo can be matched outside the scope

html foo .bar
    scoped, will not match, unless <html> element itself somehow becomes the
scoping element (can this happen?)

body foo .bar
    scoped, will potentially match only if <style scoped> is a direct child
of <body> (thus <body> becoming the scoping element)

html:root foo .bar
    NOT scoped due to the presence of :root in the first sequence (even
though not absolutely the first simple selector)

Seems reasonable, except there may be the question why it "works" with
:root, but not with 'html' or 'body', but I guess that can be explained.


Cheers,

- Roland


From bzbarsky at MIT.EDU  Mon Jul 18 21:14:55 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 19 Jul 2011 00:14:55 -0400
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
Message-ID: <4E2504BF.70504@mit.edu>

On 7/19/11 12:10 AM, Roland Steiner wrote:
> Just to nail this down:
>
> foo .bar
>      scoped, foo must be the scope element or a descendant

This is actually an interesting question.  Does this end up 
corresponding to:

   :scope foo .bar, foo:scope .bar

or to just

   :scope foo .bar

?  The latter would not match on 'foo' being the scope element, while 
the former would.

> html foo .bar
>      scoped, will not match, unless <html> element itself somehow
> becomes the scoping element (can this happen?)

I'd think so; you can always insertBefore a <style> element as a child 
of <html>.

> body foo .bar
>      scoped, will potentially match only if <style scoped> is a direct
> child of <body> (thus <body> becoming the scoping element)

Assuming there's no interesting DOM manipulation adding multiple 
HTMLBodyElement elements to the page, etc.

-Boris


From rolandsteiner at google.com  Mon Jul 18 21:30:02 2011
From: rolandsteiner at google.com (Roland Steiner)
Date: Tue, 19 Jul 2011 13:30:02 +0900
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E2504BF.70504@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
Message-ID: <CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>

On Tue, Jul 19, 2011 at 1:14 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/19/11 12:10 AM, Roland Steiner wrote:
>
>> Just to nail this down:
>>
>> foo .bar
>>     scoped, foo must be the scope element or a descendant
>>
>
> This is actually an interesting question.  Does this end up corresponding
> to:
>
>  :scope foo .bar, foo:scope .bar
>
> or to just
>
>  :scope foo .bar
>

I think one could argue for either case. Personally, I think it's
advantageous to include the scoping element (i.e., use ":scope foo .bar,
foo:scope .bar"), in order to be able to do style the scoping element itself
rather than its children individually, e.g.

:scope { background-color: mauve; }

This otherwise would be impossible in the given proposal, without resorting
to either a) add :root for no semantic reason or b) wrap the contents of the
scoping element within another element, just to be able to style it.


- Roland


From per-erik.brodin at ericsson.com  Tue Jul 19 01:17:55 2011
From: per-erik.brodin at ericsson.com (Per-Erik Brodin)
Date: Tue, 19 Jul 2011 10:17:55 +0200
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
References: <AANLkTi=EKP6EqrkZScfV8df=jVTU2Je4285BN2n2dO2i@mail.gmail.com>
	<4D6B7D05.5030807@alvestrand.no>
	<AANLkTikpUxFpO9rZru7qLAUE0pWV+oyFFUf2EbM=Jp7+@mail.gmail.com>
	<AANLkTik9Sw3pSi6s833BevfQCpR3PceKdJhYVwziF=hA@mail.gmail.com>
	<Pine.LNX.4.64.1103141858460.19153@ps20323.dreamhostps.com>
	<4D836609.9020809@lachy.id.au>
	<op.vx6mo0orim6vpa@shwetank-dixits-macbook.local>
	<1309931809.4058.148699.camel@robslapu>
	<Pine.LNX.4.64.1107112210010.2079@ps20323.dreamhostps.com>
Message-ID: <4E253DB3.6000602@ericsson.com>

On 2011-07-14 00:39, Ian Hickson wrote:
> In response to off-list feedback, I've renamed StreamTrack to
> MediaStreamTrack to be clearer about its relationship to the other
> interfaces.

Perhaps now that there is no longer any relation to tracks on the media 
elements we could also change Track to something else, maybe Component. 
I have had people complaining to me that Track is not really a good name 
here.

> On Wed, 8 Jun 2011, Per-Erik Brodin wrote:
>>
>> The TrackList feature seems to be a good way to control the different
>> components of a Stream. Although it is said that tracks provide a way to
>> temporarily disable a local camera, due to the nature of the
>> ExclusiveTrackList it is still not possible to disable video altogether,
>> i.e. to 'pull down the curtain' in a video conference. I noticed that
>> there is a bug filed on this issue but I do not think the proposed
>> solution there is quite right. There is a state in which no tracks are
>> selected in an ExclusiveTrackList, when the selected index returned is
>> -1. A quick fix would be to allow also setting the active track to -1 in
>> order to deselect all the other tracks.
>
> This is fixed now, hopefully. Let me know if the fix is not sufficient.
>
> (I replaces the videoTracks and audioTracks lists with a single tracks
> list in which you can enable and disable individual tracks.)

Good. Could we still keep audio and video in separate lists though? It 
makes it easier to check the number of audio or video components and you 
can avoid loops that have to check the kind for each iteration if you 
only want to operate on one media type. I also think that it would be 
easier to construct new MediaStream objects from individual components 
rather than temporarily disabling the ones you do not want to copy to 
the new MediaStream object and then re-enabling them again afterwards. 
It is also unclear to me what happens to a LocalMediaStream object that 
is currently being consumed in that case.

Why should the label the same as the parent on the newly constructed 
MediaStream object? If you send two MediaStream objects constructed from 
the same LocalMediaStream over a PeerConnection there needs to be a way 
to separate them on the receiving side. I also think it is a bit 
unfortunate that we now have a 'label' property on the track objects 
that means something else than the 'label' property on MediaStream, 
perhaps 'description' would be a more suitable name for the former.

>> We prefer having a StreamRecorder that you have to stop in order get the
>> recorded data (like the previous one, but with asynchronous Blob retrieval)
>> and we do not understand the use cases for the current proposal where
>> recording continues until the recorder is garbage collected (or the Stream
>> ends) and you always get the data from the beginning of the recording. This
>> also has to be tied to application quota in some way.
>
> The current design is just the result of needing to define what happens
> when you call getRecordedData() twice in a row. Could you elaborate on
> what API you think we should have?

What I am thinking of is something similar to what was proposed in
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030921.html
although that does not take quota into account. Preferably quota should 
be expressed in media time and that is heavily dependent on the format 
being used and, regardless of any codecs, I still think that the format 
has to be specified somehow. Perhaps it would be best to push recording 
to v2 since this does not seem to be the primary use case for people 
currently showing the most interest in this part of the spec.

>> Instead of blob: we would like to use stream: for the Stream URLs so
>> that we very early on in the media engine selection can use the protocol
>> scheme to determine how the URL will be handled. Blobs are typically
>> handled in the same way as other media playback. The definition of
>> stream: could be the same as for blob:.
>
> Why can't the UA know which blob: URLs point to streams and which point to
> blobs?

I was not saying that it would not be possible to keep track of which 
blob: URLs that point to blobs and which point to streams just that we 
want to avoid doing that in the early stage of the media engine 
selection. In my opinion a stream is quite the opposite of a blob 
(unknown, perhaps infinite length vs. fixed length) so when printing the 
URLs for debugging purposes it would also be much nicer to have two 
different protocol schemes. If I remember correctly the discussions 
leading up to the renaming of createBlobURL to createObjectURL assumed 
that there would be stream: URLs.

> Actually, the spec doesn't currently say anything happens when a stream
> that is being transmitted just ends, either. I guess I should spec that...
>
> ...ok, now the spec is clear that an ended stream transmits blackness and
> silence. Same with if some tracks are disabled. (Blackness only if there's
> a video track; silence only if there's an audio track.)

OK, I guess that could work. In that case you have to manually remove 
the stream from being sent over a PeerConnection if it unexpectedly 
ends. Should playing back an ended stream locally in a video element 
also produce silence and blackness then? We have been assuming network 
error which has the nice consequence that you can discard ended streams 
that are only reachable by their stream: URLs even if the URLs are not 
revoked since trying to play back such a stream: URL is 
indistinguishable from trying to play back an invalid stream: URL, in 
that case.

>> PeerConnection is an EventTarget but it still uses a callback for the
>> signaling messages and this mixture of events and callbacks is a bit
>> awkward in my opinion. If you would like to change the function that
>> handles signaling messages after calling the constructor you would have
>> to wrap a function call inside the callback to the actual signal
>> handling function, instead of just (re-)setting an onsignal (or
>> whatever) attribute listener (the event could reuse the MessageEvent
>> interface).
>
> When would you change the callback?

If you would like to send the signaling messages peer-to-peer over the 
data channel, once it is established.

>
> My concern with making the callback an event handler is that it leads to a
> set of poor failure modes and complications in the API:
>
>   - It's easy to not register a callback, which makes no sense. There's
>     literally never a use for create a PeerConnection without a signaling
>     channel, as far as I can tell, so making it easier to create one
>     without a callback than with seems like a bad design.

I think this is the case for many APIs. For example, creating an 
EventSource without registering any listener for incoming events equally 
does not make sense. With the same reasoning we should force such a 
handler to be passed to the EventSource constructor. I think the author 
will figure out and learn rather quickly which events that need to be 
handled.

>   - It's easy to register multiple callbacks. This equally makes no sense,
>     and would likely only ever be the source of bugs.

Yes it would be possible but I am not sure that it would be any easier 
to make such a mistake than to make any other mistake that would cause 
the application to malfunction. I was under the impression that most 
people use attribute event listeners anyway.

>   - It makes getting the data more complicated. Instead of passing the
>     callback the string to send, we end up passing an object which has on
>     it one attribute that contains the string.

Yeah, if getting 'event.data' is more complicated than just getting 
'data'. To get the incoming stream from a StreamEvent (should probably 
be renamed to MediaStreamEvent for consistency) the author would have to 
know how to do this anyway.

>> There is a potential problem in the exchange of SDPs in that glare
>> conditions can occur if both peers add streams simultaneously, in which
>> case there will be two different outstanding offers that none of the
>> peers are allowed to respond to according to the SDP offer-answer model.
>> Instead of using one SDP session for all media as the specification
>> suggests, we are handling the offer-answer for each stream separately to
>> avoid such conditions.
>
> Why isn't this handled by the ICE role conflict processing rules? It seems
> like simultaneous ICE restarts would be trivially resolvable by just
> following the rules in the ICE spec. Am I missing something?

This problem is not related to ICE but rather to the SDP offer-answer 
model which is separate from the ICE processing. The problem is that SDP 
offer-answer does not allow you to respond to an offer when you have an 
outstanding offer for the same set of streams. The way we are avoiding 
this is by sending SDP fragments (only the SDP lines related to the 
affected stream) rather than the full SDP each time.

//Per-Erik



From mercator+whatwg at gmail.com  Tue Jul 19 01:54:49 2011
From: mercator+whatwg at gmail.com (Jorrit Vermeiren)
Date: Tue, 19 Jul 2011 10:54:49 +0200
Subject: [whatwg] The blockquote element spec vs common quoting practices
In-Reply-To: <CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
References: <CAJpND8ng9Ua5pXjfDiq8y5d21H46KXH1=CJL7nZ=KNvBLaOs0g@mail.gmail.com>
	<F7EAD78C-0EBF-4825-8EE1-7D3831D672F4@adactio.com>
	<CAD6ztsqG1pTDK66eFnMONnNT2aP=6c3TRR4JVEQA0FRvOCfR6w@mail.gmail.com>
	<9C14D2D4-1760-496E-BF74-EA607D5582BA@opera.com>
	<CAOACb=LmPTEr-k5WBkFBm5=nNrJGZQOYfCQXZhmDj93pA50gdg@mail.gmail.com>
Message-ID: <CAOV4gmpZgq=Ybu9WqRmQM19Y_vtQK2ZWvVJ+dHALkKCRr-pLQQ@mail.gmail.com>

On Thu, Jul 14, 2011 at 22:48, Tantek ?elik <tantek at cs.stanford.edu> wrote:
> On Thu, Jul 14, 2011 at 12:35, Karl Dubost <karld at opera.com> wrote:
>> I like the pattern id/for pattern of forms. We could imagine
>>
>> <p>
>> <span for="quoteA" class="author">Sir John Typo</span>
>> has written plenty of a wonderful thing
>> in <cite for="quoteA">Amazing title</cite> very similar to those in
>> <span for="quoteB" class="author">Susan Spellchecker</span>'s writings
>
> I really like this pattern.
>
> <label for="input-id"> is a known working and in use pattern.

It is a known working pattern because it actually has a direct effect
on the UI, not because for+id is somehow more intuitive than its
inverse, id+cite, which is currently not being used. It makes the
label act as a click target for its associated input element, which is
especially useful for radio buttons and checkboxes. That's the reason
why I've used it, in any case, not because I wanted to be semantic in
any way.

Jorrit


From tkent at chromium.org  Tue Jul 19 03:40:06 2011
From: tkent at chromium.org (TAMURA, Kent)
Date: Tue, 19 Jul 2011 19:40:06 +0900
Subject: [whatwg] Placeholder visibility on focus
Message-ID: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>


http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute
> ?User agents should present this hint to the user, after having?stripped
> line breaks?from it,
> when the element's?value?is the empty string and the control is not
> focused (e.g. by
> displaying it inside a blank unfocused control).

I'd like to propose to change this part so that we allow UAs to show
placeholder text even if the control is focused.

* This behavior might depend on platforms.
    The password field of Windows 7 logon screen shows placeholder text when
the field is focused.

* autofocus + placeholder is useless in the current specification.

--
TAMURA Kent
Software Engineer, Google




From thomas at webtypes.com  Tue Jul 19 03:55:38 2011
From: thomas at webtypes.com (Thomas Maas)
Date: Tue, 19 Jul 2011 12:55:38 +0200
Subject: [whatwg] Placeholder visibility on focus
In-Reply-To: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
References: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
Message-ID: <CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>

Agreed,

instead of checking for an empty string *and* focus the user agent should just check for an empty string.

current spec:
when the element's value is the empty string and the control is not focused (e.g. by displaying it inside a blank unfocused control)

proposed spec:
when the element's value is the empty string (e.g. by displaying it inside a blank control)

Motivations:

1) autofocus + placeholder is useless in current spec
2) a placeholder is supposed to give a hint. It's not logical to hide the hint before you actually add content. As the act of adding content probably means you understood the hint, not the act of focussing.


- Thomas Maas

-- 
Webtypes
Thomas Maas
email: thomas at webtypes.com
twitter: @thomasmaas
skype: thomasmaas

On Jul 19, 2011, at 12:40 , TAMURA, Kent wrote:

> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute
>>  User agents should present this hint to the user, after having stripped
>> line breaks from it,
>> when the element's value is the empty string and the control is not
>> focused (e.g. by
>> displaying it inside a blank unfocused control).
> 
> I'd like to propose to change this part so that we allow UAs to show
> placeholder text even if the control is focused.
> 
> * This behavior might depend on platforms.
>   The password field of Windows 7 logon screen shows placeholder text when
> the field is focused.
> 
> * autofocus + placeholder is useless in the current specification.
> 
> --
> TAMURA Kent
> Software Engineer, Google
> 
> 
> 








From tyoshino at google.com  Tue Jul 19 04:16:27 2011
From: tyoshino at google.com (Takeshi Yoshino)
Date: Tue, 19 Jul 2011 20:16:27 +0900
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
Message-ID: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>

Hi,

Use of deflate-stream is now mandatory in API spec. I think this kind of
requirement is useless. How about leave it up to implementors' decision?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

Adrian first brought this up on bugzilla for discussion. I'd like to ask
opinions from whatwg.

----

First, what effect specifying /extensions/ has is not yet clear for
client-side. Is this process intended to completely specify the set of
extensions wire-protocol uses? It's strange since we're going to introduce
multiplexing which is by nature not fully under control of JavaScript.

/extensions/ like this can be a hint, suggestion or request for
wire-protocol layer. According to Hixie's post (
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917#c5) here it's used as
mandatory extension request i.e. prohibiting WebSocket w/o deflate-stream
for browsers (but some other extensions can be added in wire-protocol
level).

----

I think this requirement doesn't really help us enforce endpoints
initiate/accept WebSocket with the same configuration. Because

- non-browser UAs are free to be implemented without deflate-stream
- server developers would see/care only the wire protocol spec

So, server developers would simply make their implementation accept both
requests with and without deflate-stream, I think. It's not likely that
server implementors are influenced by "the WebSocket API" and have their
server check if a UA is browser or not and reject requests w/o
deflate-stream. The only people who benefit from this requirement is those
who implement a server only for their own use and are not interested in
serving non-browser clients.

Even for such people, I think it's easier to debug and straightforward that
they implement one without deflate-stream and then with deflate-stream, and
then just leave both available. I can't imagine servers that has solid
implementation for deflate-stream but not for w/o deflate-stream. So,

- as most of servers support WebSocket w/o deflate-stream, no one would face
any difficulties to get their client implementation live
without deflate-stream
- usually both API and wire-protocol are implemented together by the same
person/vendor

Because of these two points, as a result, even clients can be easily ignore
this requirement.

Let keep wire-protocol level stuff handled by IETF.

Regards,
Takeshi


From bzbarsky at MIT.EDU  Tue Jul 19 06:11:34 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 19 Jul 2011 09:11:34 -0400
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
	<CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
Message-ID: <4E258286.7020602@mit.edu>

On 7/19/11 12:30 AM, Roland Steiner wrote:
> I think one could argue for either case. Personally, I think it's
> advantageous to include the scoping element (i.e., use ":scope foo .bar,
> foo:scope .bar"), in order to be able to do style the scoping element
> itself rather than its children individually, e.g.
>
> :scope { background-color: mauve; }

Hmm.  I agree this is a useful thing to do, but perhaps it's better 
accomplished by not prepending ":scope " to selectors which have a 
:scope in the first sequence of simple selectors in addition to ones 
that have :root there?

This would still not make "foo .bar" match if the scope is a foo, but 
would we actually want to match?

-Boris


From jackalmage at gmail.com  Tue Jul 19 08:47:47 2011
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 19 Jul 2011 08:47:47 -0700
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E258286.7020602@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
	<CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
	<4E258286.7020602@mit.edu>
Message-ID: <CAAWBYDCO0DtyQ0S3oF=F8pS=0zEUCRpRV3Ou8eNcQu3Y-FVBrw@mail.gmail.com>

On Tue, Jul 19, 2011 at 6:11 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/19/11 12:30 AM, Roland Steiner wrote:
>>
>> I think one could argue for either case. Personally, I think it's
>> advantageous to include the scoping element (i.e., use ":scope foo .bar,
>> foo:scope .bar"), in order to be able to do style the scoping element
>> itself rather than its children individually, e.g.
>>
>> :scope { background-color: mauve; }
>
> Hmm. ?I agree this is a useful thing to do, but perhaps it's better
> accomplished by not prepending ":scope " to selectors which have a :scope in
> the first sequence of simple selectors in addition to ones that have :root
> there?
>
> This would still not make "foo .bar" match if the scope is a foo, but would
> we actually want to match?

I think it's best for that case to *not* match.  Otherwise, you have
to explicitly remember to add a :not(:scope) to every rule that might
match the scoping element.

It's very easy to style the scoping element by using :scope explicitly.

~TJ


From philipj at opera.com  Tue Jul 19 09:00:07 2011
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Tue, 19 Jul 2011 18:00:07 +0200
Subject: [whatwg] Microdata - Handling the case where a string is
 upgraded to an object
In-Reply-To: <CAAWBYDC1z2HFrjxk5bqwA80+9mj3Awkx9=BZWsoKHvPDudxP2w@mail.gmail.com>
References: <CAAWBYDBLrj=c6p8Y93bLBHGv5pYCbc-2Q18oF1iuCpnDY23XPA@mail.gmail.com>
	<op.vyta3xunsr6mfa@kirk>
	<CAAWBYDC1z2HFrjxk5bqwA80+9mj3Awkx9=BZWsoKHvPDudxP2w@mail.gmail.com>
Message-ID: <op.vyviqhu7sr6mfa@kirk>

On Mon, 18 Jul 2011 22:01:37 +0200, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Mon, Jul 18, 2011 at 4:20 AM, Philip J?genstedt <philipj at opera.com>

>> As for the solution, are you suggesting that .itemValue return a special
>> object which is like HTMLElement in all regards except for how it
>> toString()s?
>
> Yes.

Currently, it's spec'd as returning the element itself. This isn't  
terribly useful, at least I've just checked e.itemScope and then accessed  
e.properties directly rather than going through e.itemValue.properties.  
Given this, a simpler fix would be to let .itemValue act like .textContent  
when an itemscope attribute is present.

Still, I'm not sure if it's a good idea. It makes the Microdata model kind  
of odd if a property is both an item and has a fallback text  
representation. It will also mask the fact that a text property has been  
upgraded to an item, somewhat decreasing the chance that the consuming  
code will be updated.

-- 
Philip J?genstedt
Core Developer
Opera Software


From darin at apple.com  Tue Jul 19 10:12:47 2011
From: darin at apple.com (Darin Adler)
Date: Tue, 19 Jul 2011 10:12:47 -0700
Subject: [whatwg] Placeholder visibility on focus
In-Reply-To: <CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>
References: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
	<CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>
Message-ID: <2D70BBA5-0742-4B0E-9521-D1D3D6CDC0CE@apple.com>

On Jul 19, 2011, at 3:55 AM, Thomas Maas wrote:

> instead of checking for an empty string *and* focus the user agent should just check for an empty string.

I think that for some user agents, whether the placeholder text is shown when the field is focused should depend on platform behavior.

For example, Safari has one behavior on Snow Leopard and a different behavior on Lion and I think that is a good thing.

    -- Darin



From ap at webkit.org  Tue Jul 19 10:42:07 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Tue, 19 Jul 2011 10:42:07 -0700
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
Message-ID: <D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>


18.07.2011, ? 9:35, Glenn Maynard ???????(?):

> > A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.
> 
> The service hosting the file--the target of the link--shouldn't convey trust.  The page containing the download link is where trust should come from, not the link target.


There are many views on what conveys trust. If we don't go to the extremes (like users who click on anything and agree to any confirmation dialogs without reading them), there is certainly a group of people who look where a link points to before clicking it.

The fact that hosting implies a certain degree of trust is also built into client software. For example, if you download an executable file on Mac OS X, then the system warns you about it on first launch, and tells you where it was downloaded from, not where a link to the download was.

Hosting services do have their policies on what can be hosted. As we discuss a way to subvert those policies, we shouldn't start with an assumption that it's inconsequential.

- WBR, Alexey Proskuryakov



From ian at hixie.ch  Tue Jul 19 12:42:45 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Jul 2011 19:42:45 +0000 (UTC)
Subject: [whatwg] Specification of window.find()
In-Reply-To: <BANLkTinMC95+_orq-qrwQ6tdB3NVdj5Pfw@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<4D2715D8.2020102@nokia.com>
	<Pine.LNX.4.64.1105022340110.19153@ps20323.dreamhostps.com>
	<4DBFC066.4030206@nokia.com>
	<BANLkTinMC95+_orq-qrwQ6tdB3NVdj5Pfw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107182154220.2079@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Benjamin Poulain wrote:
> On 05/03/2011 01:42 AM, ext Ian Hickson wrote:
> > > I do not know the original use case but I can think of a few: -on 
> > > mobile devices which have a find dialog but no user interface to 
> > > access it, make the find dialog appear
> > 
> > Are there pages that do this today? Or indeed any UAs that have a find 
> > dialog but no UI to access it? [...]
> 
> I don't really have an interest in defending the feature.
> 
> I was just hoping to get a specification for the API to get a bit more 
> consistency between engines.
> 
> Since you do not seem interested in the feature, I guess we can keep it 
> as a WebKit/Gecko extension.

What would be even better is if WebKit and Gecko could just drop support 
for the feature altogether, if there are no compelling use cases for it, 
no compat need, and nobody is interested in defending the feature.

But if there is a need, that's a different matter:

On Thu, 5 May 2011, Hallvord R M Steen wrote:
> 
> Opera is regularly nagged by rich text editor authors who would like us 
> to support window.find(). Since it seems to be a requested feature, it 
> would be nice to have a proper spec ;-)
>
> I guess that one of the main use cases indeed is to be able to highlight 
> search hits inside a single frame (using the browser's built-in search 
> might highlight hits both in a rich text editor's UI and the document 
> you're editing, which would be confusing)..
>
> Yes, it is a counter-argument that authors could write their own 
> implementation. However, it's non-trivial to write a good text find 
> implementation in JS - it needs to handle text wrapping, text that is 
> split across different text nodes or tags, HTML entities, soft hyphens, 
> BiDi and probably a lot of issues I'm not aware of. It's a lot simpler 
> to let the JS author hook into the UA's presumably superior and better 
> tested algorithm.

In investigating this further, I've found that window.find() is not 
especially interoperably implemented. I've filed bugs on the two browsers 
that implement it to investigate what we can do about it:

   https://bugzilla.mozilla.org/show_bug.cgi?id=672395
   https://bugs.webkit.org/show_bug.cgi?id=64761

I've also added a placeholder to the spec for this feature.

Depending on how these bugs go, I'll either fill in the spec to one extent 
or another, or remove the section altogether.

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


From thomas at webtypes.com  Tue Jul 19 12:43:41 2011
From: thomas at webtypes.com (Thomas Maas)
Date: Tue, 19 Jul 2011 21:43:41 +0200
Subject: [whatwg] Placeholder visibility on focus
In-Reply-To: <2D70BBA5-0742-4B0E-9521-D1D3D6CDC0CE@apple.com>
References: <CAGH7WqGLmdHakLT=JoVUtqx=KQNk5++KoQyyky91AKveg7VBRw@mail.gmail.com>
	<CF0D811D-FC5C-42B2-994F-62D736B1903F@webtypes.com>
	<2D70BBA5-0742-4B0E-9521-D1D3D6CDC0CE@apple.com>
Message-ID: <5A5BC940-1B49-496D-A377-93116630C72B@webtypes.com>

On Jul 19, 2011, at 19:12 , Darin Adler wrote:

> On Jul 19, 2011, at 3:55 AM, Thomas Maas wrote:
> 
>> instead of checking for an empty string *and* focus the user agent should just check for an empty string.
> 
> I think that for some user agents, whether the placeholder text is shown when the field is focused should depend on platform behavior.
> 
> For example, Safari has one behavior on Snow Leopard and a different behavior on Lion and I think that is a good thing.
> 
>    -- Darin
> 

Well, the spec is pretty clear on the expected behavior of a user agent. If two user agents behave differently it just means of them isn't following the spec. I'm not sure I see how that's a good thing, but that's a different discussion altogether.

What Kent was suggesting is changing the spec to state that placeholder strings should bel visible on focus. I think that makes a lot of sense.

The only reason I can think of to hide the placeholder on focus is to make it clear to the user that there is no content yet. But that could be solved by styling the placeholder differently on focus or even bring back the current behavior by setting. :focus input-placeholder to display: none.

-Thomas.






From ian at hixie.ch  Tue Jul 19 14:35:53 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Jul 2011 21:35:53 +0000 (UTC)
Subject: [whatwg] Document's base URI should use the document's
 *current* address
In-Reply-To: <BANLkTikQ0P7WTZ3O6dRMs9LC4Ffkr-mzow@mail.gmail.com>
References: <BANLkTi=3DDK6pW4FXywKj8C6DRvNjFpYrQ@mail.gmail.com>
	<BANLkTikQ0P7WTZ3O6dRMs9LC4Ffkr-mzow@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107192115280.2079@ps20323.dreamhostps.com>

On Wed, 27 Apr 2011, Justin Lebar wrote:
>
> The document base URL is used when fetching resources.
> 
> Right now, if a page doesn't have a <base> element, the document base 
> URL is set to the document's address. ?(I'm going to call this the 
> "document's original address".) ?The document's original address does 
> not change when you call pushState; only the document's current address 
> does.
> 
> I think the base URI should use the document's current address, not the 
> original address.
> 
> To see why this makes sense, consider the following scenario:
> 
> * User loads page.html
> * Page calls pushState and changes its url to page2.html
> * User clicks on a link with href "#foo".
> 
> As currently specified, we'll resolve #foo relative to the document's 
> original URL; that is, clicking the link will take the user to 
> page.html#foo, not page2.html#foo. ?But the intent of a link with href 
> #foo is clearly to navigate within the current page, not to go somewhere 
> else.
> 
> Firefox 4 already implements pushState as I'm suggesting here.

The spec as written decides whether a link is a same-resource reference or 
not based on comparing the URLs to what you're calling the original 
address, not comparing it to the current address. See the navigation 
algorithm, step 7 /Fragment identifiers/.

Note that there are problems with what you describe: what if the new URL 
has a different path, and there are <img> elements whose URLs are 
relative, and after pushState() you clone one? Or what about relative 
links in the original markup? I don't think we can change the base URL on 
the fly, all kinds of problems could result.

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

From jonas at sicking.cc  Tue Jul 19 16:06:56 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 19 Jul 2011 16:06:56 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
Message-ID: <CA+c2ei_WiLbLLu3-EzKzU5oBztz7C6R9WFV1kJ08+h8PoTwg7A@mail.gmail.com>

> I think this requirement doesn't really help us enforce endpoints
> initiate/accept WebSocket with the same configuration. Because
>
> - non-browser UAs are free to be implemented without deflate-stream
> - server developers would see/care only the wire protocol spec

Given the number of browser installations in the world (a couple of
billion or so), and that a significant portion of these will implement
the WebSockets API spec, it would seem downright irresponsible of
server developers to not look at it.

> So, server developers would simply make their implementation accept both
> requests with and without deflate-stream, I think.

I'd like to see a bit more meat on this assertion.

> It's not likely that
> server implementors are influenced by "the WebSocket API" and have their
> server check if a UA is browser or not and reject requests w/o
> deflate-stream.

Agreed. But it's not really servers job to ensure that browsers follow
the websocket spec here. Test suites and being able to claim that you
follow the spec should enforce that.

> The only people who benefit from this requirement is those
> who implement a server only for their own use and are not interested in
> serving non-browser clients.

First off, I suspect that the by far most common use case for servers
implementing websocket is to talk to browsers. So I would expect the
group you are talking about to be the majority of websocket
implementations. How many http servers do you think are out there
written primarily to talk to browsers?

Second, we're not really talking about browsers vs. non-browsers,
right. But rather clients that support deflate-stream vs. ones that
don't. So if a server expects to only talk to clients that support
deflate-stream, they might choose not require that. Even if some of
those clients aren't browsers.

Compare to the situation for http servers out there. I would expect
that a large number of them (as measured by codebases, not by
deployments) to have been primarily developed by testing what works
against browsers. I would further expect that non-browser clients,
such as web search spiders, end up having had to replicate some
browser behavior in order to be compatible with a larger set of http
servers.

> Even for such people, I think it's easier to debug and straightforward that
> they implement one without deflate-stream and then with deflate-stream, and
> then just leave both available. I can't imagine servers that has solid
> implementation for deflate-stream but not for w/o deflate-stream.

Untested generally ends up being non-working code. So while you might
end up writing without deflate-stream in the beginning, once you
implement deflate-stream, and have almost exclusively clients that
support deflate-stream, it's likely that your non-deflate-stream code
path ends up with bugs.

/ Jonas


From wwg at millie.uk.to  Tue Jul 19 17:06:03 2011
From: wwg at millie.uk.to (Marc 'Tafouk')
Date: Wed, 20 Jul 2011 02:06:03 +0200
Subject: [whatwg]  WebVTT feedback (was Re: Video feedback)
Message-ID: <jbm.20110720020603.62552adf@AZIMUTH>

On Mon, 27 Jun 2011 at 09:32 AM, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:
> I wanted to mention that Ronny's page at
> http://leanbackplayer.com/other/webvtt.html has had some updates
> recently and has now settled, with demos at
> http://leanbackplayer.com/test/webvtt.html .
>
> Note that where his implementation differs from the spec, he has made
> a note. There are only two such notes. I'd like to see these
> addressed, too.
>
> Cheers,
> Silvia.
>

Hello folks,

I've been following the latest developments on the WebVTT specification and 
am making an attempt to write an out-of-browser parser, using Anna 
Cavender's proposed patches to WebKit.

First, I filed a request on the bugtracker 
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=13292> regarding the "end-
of-file marker" that's mentioned in the current draft 
<http://www.whatwg.org/specs/web-apps/current-work/#webvtt-cue-text-
parsing-rules>


I have another question about self-closing tags in cue text. It seems 
they're not supported at all.
The U+002F SOLIDUS character (/) is only handled in the WebVTT tag state.

Test case 1-a):
   WEBVTT

   00:00.000 --> 00:02.000
   Initial <b/> test

U+0062 (b) triggers "WebVTT start tag state"; U+002F is then handled as 
"Anything else" and is appended to result (tagname = "b/").


Test case 1-b):
   WEBVTT

   00:00.000 --> 00:02.000
   Initial <b /> test


U+0062 (b) triggers "WebVTT start tag state"; U+0020 (space) triggers  
"WebVTT start tag annotation state"; U+002F is handled as "Anything else" 
and is appended to buffer (annotation = "/").


I am aware those may be moot atm because there is no void element AFAIK, 
and the current tags make no sense when immediately closed.


I also found a slight issue when following the parser specs : there is no 
validation of the class attribute.

Test case 2):
   WEBVTT

   00:00.000 --> 00:02.000
   Second <c.......... [my annotation]> test

classes is a list of 10 empty strings.

Regards, Marc.




From ian at hixie.ch  Tue Jul 19 17:34:42 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 20 Jul 2011 00:34:42 +0000 (UTC)
Subject: [whatwg] <comment> element in HTML5 Spec?
In-Reply-To: <BANLkTim_4yVi3ms+NqW+t9VBJCRJQUkgMA@mail.gmail.com>
References: <C92C1B1D.28D9%Richard.Summers@bbc.co.uk>
	<AANLkTikiNFD+-5tUvVD6eqsyojwbXqKpAB9MO7b3HuNk@mail.gmail.com>
	<2d71c095a3c6bd8bab706420b97d1581.squirrel@htmlfiver.com>
	<Pine.LNX.4.64.1104282130170.19153@ps20323.dreamhostps.com>
	<BANLkTikgHa8PdBVqo2cS7xKSMSHhQiYNfg@mail.gmail.com>
	<BANLkTim_4yVi3ms+NqW+t9VBJCRJQUkgMA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107192343470.2079@ps20323.dreamhostps.com>

On Thu, 28 Apr 2011, Jonas Sicking wrote:
> On Thu, Apr 28, 2011 at 2:41 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 13 Dec 2010, Richard Summers wrote:
> >>
> >> I was wondering, is there any plan to implement a <comment> element 
> >> within the HTML5 spec? I?m suggesting this as a complimentary element 
> >> to the <article> element.
> >
> > There already is one: <article>! We defined it such that if you nest 
> > them, the nested ones are defined to be comments. There are some 
> > examples of this in the spec.
> >
> >
> > On Mon, 13 Dec 2010, Tab Atkins Jr. wrote:
> >>
> >> 1. Differentiating between the main article and user-generated 
> >> content in response (you bring this up). ?Would this be useful for 
> >> search engines? ?I'm not sure. ?Would it be useful to weight comment 
> >> content differently from article content? ?Perhaps weight links in 
> >> comments less than links in the rest of the page?
> >
> > This is already possible: a nested <article> has this semantic.
> 
> This seems like a very unintuitive solution. If this really is a use 
> case that is worth addressing, I think it would be worth coming up with 
> a dedicated element. In general, elements that have different meaning 
> depending on in which context they appear usually doesn't feel very 
> intuitive and thus likely something that people will miss or get wrong.

<article> has just one meaning: content that it would make sense to 
syndicate; or to put it another way, content for which a CMS could 
reasonably have a dedicated permalink page. When it's nested in another, 
it just means that the inner article is a response to the outer one, in 
the same way that a <section> in another <section> is a subsection of the 
first, or that an <h1> in a particular <section> is a heading for that 
section. I don't think this is a different meaning.


On Thu, 28 Apr 2011, Tab Atkins Jr. wrote:
> 
> I agree.  In particular, I want to sometimes nest articles without one 
> article being a comment on the outer one.

Could you describe such a case? I'm finding it hard to imagine a situation 
where an article literally nests another, without <aside> being more 
appropriate.


> The <body> element is supposed to be the "default article" for the page, 
> too - it would be odd if <article>-in-<body> acted differently from 
> <article>-in-<article>.

I don't think it's accurate to consider <body> to be equivalent to 
<article>. You wouldn't syndicate much of what is in a <body>, only the 
article itself (e.g. you wouldn't syndicate the footer, site nav, etc).

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

From ian at hixie.ch  Tue Jul 19 18:12:19 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 20 Jul 2011 01:12:19 +0000 (UTC)
Subject: [whatwg] <base> in <body>
Message-ID: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>


IE7 and up, in both quirks and non-quirks modes, ignores <base href> in 
the <body> of a page. This is intended to protect against a situation 
where a whitelist-based content filter disallows all scripts but does not 
disallow <base>, and the page contains a relative URL in a <script> after 
an area of the page under attacker control.

Would other browser vendors be willing to change to only look at <base 
href> in <head>?

The change to the spec would just be changing this step in the "document 
base URL" definition:

4. If there is no base element that has an href attribute, then the 
   document base URL is fallback base url; abort these steps. Otherwise, 
   let url be the value of the href attribute of the first such element.

...to limit the search just to children of the <head> element.

Note that there is a compatibility risk, in that IE7-9 parse certain 
elements into the <head> where the HTML parser spec does not. For example:

   <!DOCTYPE HTML>
   <html>
    <head>
     <title>Demo</title>
    </head>
    <!-- implied <body> -->
     <form>
      <input type=hidden>
      <base href="">

...will end up with the <head> element containing a <form> element that 
itself contains the <base> element.

IE10 parses this like other browsers, so it would be affected by the same 
compatibility concern.

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


From bzbarsky at MIT.EDU  Tue Jul 19 20:07:05 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 19 Jul 2011 23:07:05 -0400
Subject: [whatwg] <base> in <body>
In-Reply-To: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
Message-ID: <4E264659.3040004@mit.edu>

On 7/19/11 9:12 PM, Ian Hickson wrote:
> Would other browser vendors be willing to change to only look at<base
> href>  in<head>?

Gecko used to implement that back when the spec said it.

This caused site compat issues.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=593807 (United checkin 
outside the US being broken) and 
https://bugzilla.mozilla.org/show_bug.cgi?id=592880 (hyperlatex output 
being broken) for example.

The latter explicitly mentions that hyperlatex output is broken in 
recent IE versions.

The former depends on the parsing behavior of IE you describe so is not 
a problem in IE9-.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=593807#c7

On the other hand, this change would fix CA Unicenter 
(https://bugzilla.mozilla.org/show_bug.cgi?id=627361 and its two 
duplicates), I think.

So I guess it comes down to what set of sites we want to break here.... 
  Do other UA vendors have any data on the matter?

That said, I'm not sure I understand the security concern.  What kind of 
whitelist-based filter would let through <script>s whose URIs it does 
not control, exactly?  Can the security concern be mitigated by only 
allowing <base> outside <head> if the base URI it sets is same-origin 
with the document?

-Boris


From silviapfeiffer1 at gmail.com  Tue Jul 19 20:14:23 2011
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 20 Jul 2011 13:14:23 +1000
Subject: [whatwg] WebVTT feedback (was Re: Video feedback)
In-Reply-To: <jbm.20110720020603.62552adf@AZIMUTH>
References: <jbm.20110720020603.62552adf@AZIMUTH>
Message-ID: <CAHp8n2nJCdZTSJUR4keUXN17T12qKwwriR6XuiUk4w=Dxt369Q@mail.gmail.com>

Hi Marc,

On Wed, Jul 20, 2011 at 10:06 AM, Marc 'Tafouk' <wwg at millie.uk.to> wrote:
>
> Hello folks,
>
> I've been following the latest developments on the WebVTT specification and
> am making an attempt to write an out-of-browser parser, using Anna
> Cavender's proposed patches to WebKit.

Cool! Is this a new video player app or going into, say, VLC or
something similar?


> First, I filed a request on the bugtracker
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13292> regarding the "end-
> of-file marker" that's mentioned in the current draft
> <http://www.whatwg.org/specs/web-apps/current-work/#webvtt-cue-text-
> parsing-rules>

I replied. IIUC, it's just the EOF state that is meant, not an actual character.


> I have another question about self-closing tags in cue text. It seems
> they're not supported at all.

None of the tags that we have mean anything if they self-close (and
the <timestamp> is implicitly closing).


> The U+002F SOLIDUS character (/) is only handled in the WebVTT tag state.
>
> Test case 1-a):
> ? WEBVTT
>
> ? 00:00.000 --> 00:02.000
> ? Initial <b/> test
>
> U+0062 (b) triggers "WebVTT start tag state"; U+002F is then handled as
> "Anything else" and is appended to result (tagname = "b/").

Yes. The next character is then a ">" and causes in the next loop to
return an end tag. Then, end tags are parsed and it's not in the list
that we expect, so this happens: Otherwise, ignore the token. Thus,
<b/> is ignored.


> Test case 1-b):
> ? WEBVTT
>
> ? 00:00.000 --> 00:02.000
> ? Initial <b /> test
>
>
> U+0062 (b) triggers "WebVTT start tag state"; U+0020 (space) triggers
> "WebVTT start tag annotation state"; U+002F is handled as "Anything else"
> and is appended to buffer (annotation = "/").

Once ">" is reached, this leads to a start tag <b> with an annotation
of "/". From how I read it, the annotation string gets ignored.


> I am aware those may be moot atm because there is no void element AFAIK,
> and the current tags make no sense when immediately closed.

They still have to parse correctly. But I think from analysing the
spec they actually do.


> I also found a slight issue when following the parser specs : there is no
> validation of the class attribute.

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#attach-a-webvtt-internal-node-object
says to attach the list of classes to the element. Right now, all
characters are allowed for class names bar space, tab, "." and ">". It
might indeed be an idea to restrict these character to those allowed
for class names in HTML.


> Test case 2):
> ? WEBVTT
>
> ? 00:00.000 --> 00:02.000
> ? Second <c.......... [my annotation]> test
>
> classes is a list of 10 empty strings.

While possibly a bit or unneeded overhead, in
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#webvtt-cue-text-dom-construction-rules
when mapping to HTML happens, they just create an additional space in
the class attribute, so are not harmful.


Cheers,
Silvia.


From rolandsteiner at google.com  Tue Jul 19 20:52:55 2011
From: rolandsteiner at google.com (Roland Steiner)
Date: Wed, 20 Jul 2011 12:52:55 +0900
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <CAAWBYDCO0DtyQ0S3oF=F8pS=0zEUCRpRV3Ou8eNcQu3Y-FVBrw@mail.gmail.com>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
	<CACFPSpiFfBKZ=kFhiVz=YTFBEsAYVGFKn6fhcm6F+K3+t98cFQ@mail.gmail.com>
	<4E258286.7020602@mit.edu>
	<CAAWBYDCO0DtyQ0S3oF=F8pS=0zEUCRpRV3Ou8eNcQu3Y-FVBrw@mail.gmail.com>
Message-ID: <CACFPSpiHXZ2KsUWo6KiSXCt0RVdhSAEpP_QPcKpNmodCbKn0fQ@mail.gmail.com>

On Wed, Jul 20, 2011 at 12:47 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Tue, Jul 19, 2011 at 6:11 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > On 7/19/11 12:30 AM, Roland Steiner wrote:
> >>
> >> I think one could argue for either case. Personally, I think it's
> >> advantageous to include the scoping element (i.e., use ":scope foo .bar,
> >> foo:scope .bar"), in order to be able to do style the scoping element
> >> itself rather than its children individually, e.g.
> >>
> >> :scope { background-color: mauve; }
> >
> > Hmm.  I agree this is a useful thing to do, but perhaps it's better
> > accomplished by not prepending ":scope " to selectors which have a :scope
> in
> > the first sequence of simple selectors in addition to ones that have
> :root
> > there?
> >
> > This would still not make "foo .bar" match if the scope is a foo, but
> would
> > we actually want to match?
>
> I think it's best for that case to *not* match.  Otherwise, you have
> to explicitly remember to add a :not(:scope) to every rule that might
> match the scoping element.
>

You could just prefix ":scope " instead, i.e., write ":scope foo" if you're
worried that foo might match the scoping element.


> It's very easy to style the scoping element by using :scope explicitly.


I kinda agree with the assessment, but from a puritanical point of view,
given that :scope is a pseudo-class it feels strange that with <foo> as
scoping element the more specific "foo:scope" would match, but the more
generic "foo" wouldn't (even though it still is the scoping element). Also,
the same "foo" matches again if there is a ":root" further to the left.

But adding :scope into the discussion raises the question whether matching
should continue even in the absence of :root - e.g.,

baz :scope .bar

It would seem natural that with this rule, matching would go past the
scoping element, given that it's explicitly identified. That means, the
matching algorithm would go along the lines of:

.) match up to a child of the scoping element
.) match the scoping element and upwards ONLY IF the current selector
sequence contains :scope or the first selector sequence contains :root

if the scoping element is not per default included, or

.) match up to the scoping element
.) match upwards ONLY IF the scoping element was explicitly matched with
:scope, or if the first selector sequence contains :root

if it is.


- Roland


From annevk at opera.com  Wed Jul 20 01:54:55 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 20 Jul 2011 10:54:55 +0200
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E264659.3040004@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu>
Message-ID: <op.vywtptlc64w2qv@annevk-macbookpro.local>

On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> That said, I'm not sure I understand the security concern.  What kind of  
> whitelist-based filter would let through <script>s whose URIs it does  
> not control, exactly?  Can the security concern be mitigated by only  
> allowing <base> outside <head> if the base URI it sets is same-origin  
> with the document?

The <script> is from the page itself and uses a relative URL. The <base>  
is inserted by the attacker and causes the script to be requested from a  
server under the attacker's control.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From tyoshino at google.com  Wed Jul 20 01:57:04 2011
From: tyoshino at google.com (Takeshi Yoshino)
Date: Wed, 20 Jul 2011 17:57:04 +0900
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CA+c2ei_WiLbLLu3-EzKzU5oBztz7C6R9WFV1kJ08+h8PoTwg7A@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<CA+c2ei_WiLbLLu3-EzKzU5oBztz7C6R9WFV1kJ08+h8PoTwg7A@mail.gmail.com>
Message-ID: <CAH9hSJZCe-GFabqBO_3XjYVdGgyWBZhPyW5O2DF2kwqEY=-bQQ@mail.gmail.com>

Hi,

On Wed, Jul 20, 2011 at 08:06, Jonas Sicking <jonas at sicking.cc> wrote:

> > I think this requirement doesn't really help us enforce endpoints
> > initiate/accept WebSocket with the same configuration. Because
> >
> > - non-browser UAs are free to be implemented without deflate-stream
> > - server developers would see/care only the wire protocol spec
>
> Given the number of browser installations in the world (a couple of
> billion or so), and that a significant portion of these will implement
> the WebSockets API spec, it would seem downright irresponsible of
> server developers to not look at it.


Sorry, I said too far about this. My main point is the assertion "they
wouldn't try to reject clients w/o deflate-stream".


> > It's not likely that
> > server implementors are influenced by "the WebSocket API" and have their
> > server check if a UA is browser or not and reject requests w/o
> > deflate-stream.
>
> Agreed. But it's not really servers job to ensure that browsers follow
> the websocket spec here. Test suites and being able to claim that you
> follow the spec should enforce that.
>

It really tries to enforce browsers to use deflate-stream. I agree that
point. But even with this requirement I don't think we can avoid the bad
situation for servers that Hixie described in the bug entry. It just pull up
the ratio of clients in the world which never initiates WebSocket w/o
deflate-stream. Even without this requirement, server developers would
implement compression to make their server widely-used. Even with this
requirement, they would still leave their server accept un-compressed
connection for debugging and interoperability with non-browser clients. Just
IMHO.

But for service providers, yes, as you say the requirement may support them
in recommending clients with compression-by-default, or moreover in stopping
support of un-compressed connections, to reduce bandwidth and complexity in
load balancing, etc. So, I'll stop arguing this point.


> > The only people who benefit from this requirement is those
> > who implement a server only for their own use and are not interested in
> > serving non-browser clients.
>
> First off, I suspect that the by far most common use case for servers
> implementing websocket is to talk to browsers. So I would expect the
> group you are talking about to be the majority of websocket
> implementations. How many http servers do you think are out there
> written primarily to talk to browsers?
>

Yes. For most case, their "primary" clients will be browsers, I agree. But
it's also true that IETF keeps it available for possible non-browser
clients.

According to your and Hixie's opinion, the API spec is indirectly attempting
to override the decision made by IETF and eliminate WebSocket w/o
deflate-stream support from both client and server from the world while "the
WebSocket protocol" still allows plain connection. Here we are introducing
inconsistency between the goal of "the WebSocket protocol" and one of "the
WebSocket API".  We are separating the world of "the WebSocket protocol for
the WebSocket API" and "the WebSocket protocol". It's rather really
interoperability problem. Please don't take indirect and majority power
based way silently but feedback to HyBi. We should respect/coordinate each
other's decision/philosophy. It's last resort that we instantiate a
dedicated "the WebSocket protocol for the WebSocket API".

In particular about enforcing or recommending regular use of compression,
once we've specified compression method good enough to recommend, I think
that's fine. But that still should be first discussed in the HyBi WG (with
coordination with the whatwg). deflate-stream is left optional because it's
just an example interim solution and getting objection in the HyBi WG. It's
waiting for better compression extension. We shouldn't extend this
un-stability to the API spec.


> Second, we're not really talking about browsers vs. non-browsers,
> right. But rather clients that support deflate-stream vs. ones that
> don't. So if a server expects to only talk to clients that support
> deflate-stream, they might choose not require that. Even if some of
> those clients aren't browsers.
>

s/not require/require/?

Yes. Accepting deflate-stream or not can be decided by each server developer
and service provider on their responsibility.


> > Even for such people, I think it's easier to debug and straightforward
> that
> > they implement one without deflate-stream and then with deflate-stream,
> and
> > then just leave both available. I can't imagine servers that has solid
> > implementation for deflate-stream but not for w/o deflate-stream.
>
> Untested generally ends up being non-working code. So while you might
> end up writing without deflate-stream in the beginning, once you
> implement deflate-stream, and have almost exclusively clients that
> support deflate-stream, it's likely that your non-deflate-stream code
> path ends up with bugs.


Generally I agree. But IMO connections w/ deflate-stream would be usually
implemented by composing deflater/inflater code with the code that handles
plain (w/o deflate-stream) connections. The situation is different from
supporting some feature A and B where A and B are really independent. There
would be little code that may get rotten. Rather, as I noted above the
complicated matter I'd worry about is
- to handle two kinds of connection with different characteristics mixed
- to handle inefficient clients for all time
from production perspective (load balancing, etc.).

Takeshi


From timdown at gmail.com  Wed Jul 20 03:14:18 2011
From: timdown at gmail.com (Tim Down)
Date: Wed, 20 Jul 2011 11:14:18 +0100
Subject: [whatwg] Specification of window.find()
In-Reply-To: <Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
Message-ID: <CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>

On 6 January 2011 21:53, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 27 Oct 2010, benjamin.poulain at nokia.com wrote:
>>
>> I would like to suggest a change for the main HTML 5 specification:
>> http://www.whatwg.org/specs/web-apps/current-work/
>>
>> The problem I have is with the Window object specification
>> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
>> It does not mention the method find() which can be found on most engines
>> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).
>
> It looks like IE doesn't implement this, so it's probably not strictly
> required for compat with the Web.
>
> What are the use cases for this feature?

It's useful for custom search features. I've recommended it a few
times on Stack Overflow for people wanting to highlight or somehow
style all occurrences of a piece of text that may span nodes (it's
this part that is the compelling feature). You can achieve the same
using TextRange in IE. For example:

http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags

I think this is a valid use case. On a related note, I would like to
see equivalents of some of the text-based methods in IE's TextRange
make their way into Range, but that's a separate issue.

Tim


From chris at bentzel.net  Wed Jul 20 04:33:51 2011
From: chris at bentzel.net (Chris Bentzel)
Date: Wed, 20 Jul 2011 07:33:51 -0400
Subject: [whatwg] a rel=attachment
In-Reply-To: <D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
Message-ID: <CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>

Who should be trusted for filename if the one specified by <a> on the
referring page differs from the one specified by Content-Disposition
on the to-be-downloaded resource?

On Tue, Jul 19, 2011 at 1:42 PM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> 18.07.2011, ? 9:35, Glenn Maynard ???????(?):
>
>> > A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.
>>
>> The service hosting the file--the target of the link--shouldn't convey trust. ?The page containing the download link is where trust should come from, not the link target.
>
>
> There are many views on what conveys trust. If we don't go to the extremes (like users who click on anything and agree to any confirmation dialogs without reading them), there is certainly a group of people who look where a link points to before clicking it.
>
> The fact that hosting implies a certain degree of trust is also built into client software. For example, if you download an executable file on Mac OS X, then the system warns you about it on first launch, and tells you where it was downloaded from, not where a link to the download was.
>
> Hosting services do have their policies on what can be hosted. As we discuss a way to subvert those policies, we shouldn't start with an assumption that it's inconsequential.
>
> - WBR, Alexey Proskuryakov
>
>


From tommyw at google.com  Wed Jul 20 05:28:46 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Wed, 20 Jul 2011 14:28:46 +0200
Subject: [whatwg] Enabling/disabling tracks in MediaStreams
In-Reply-To: <Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
References: <4E242D26.3030401@alvestrand.no>
	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
Message-ID: <CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>

Thanks for the explanation. To me this sounds overly complicated, why not
just make it so that an disable of a track will override the track settings
for forked MediaStreams? This will definitely simplify implementation, and
confuse web developers less imho. MSTracks coming and going doesn't feel
right. Especially since there are no callbacks/events that a MS changes.

Also some follow-up questions regarding the new TrackLists:

What should happen when a track fails? Should the entire stream fail, the
MSTrack silently be removed or the MSTrack disassociated with the track (and
thus becoming a do-nothing object)?

What should happen when a stream with two or more video tracks is associated
to a <video> tag? Just render the first enabled one?

/Tommy

On Mon, Jul 18, 2011 at 20:38, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 18 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> >
> > I am very confused regarding the below paragraph from the latest spec:
> >
> > When a track in a MediaStream parent is disabled, any MediaStreamTrack
> > objects corresponding to the tracks in any MediaStream objects that were
> > created from parent are disassociated from any track, and must not be
> > reused for tracks again. If a disabled track in a MediaStream parent is
> > re-enabled, from the perspective of any MediaStream objects that were
> > created from parent it is a new track and thus new MediaStreamTrack
> > objects must be created for the tracks that correspond to the re-enabled
> > track.
> >
> > After cloning a LocalMediaStream it looks like this:
> >
> > LocalMediaStream -> MediaStream1
> > Track1(E)           Track1(E)
> > Track2(E)           Track2(E)
> > Track3(E)           Track3(E)
> >
> > and as I interpret the spec it looks like this if Track1 in the
> > LocalMediaStream is disabled:
> >
> > LocalMediaStream -> MediaStream1
> > Track1(D)           Track2(E)
> > Track2(E)           Track3(E)
> > Track3(E)
>
> Correct so far (though I'd avoid the term "cloning" since it's not quite
> what's going on here -- the spec uses "forking", which may be closer
> though is still not ideal).
>
>
> > So Track1 disappears from the MediaStream1 object and doesn't come back
> > even if Track1 in the LMS object is enabled:
> >
> > LocalMediaStream -> MediaStream1
> > Track1(E)           Track2(E)
> > Track2(E)           Track3(E)
> > Track3(E)
>
> No, it'll create a new track object:
>
>  LocalMediaStream -> MediaStream1
>  Track1(E)           Track4(E)
>  Track2(E)           Track2(E)
>  Track3(E)           Track3(E)
>
> This is specified in the sentence that starts "If a disabled track in a
> MediaStream parent is re-enabled...".
>
> If you could explain how you are interpreting the current text I would be
> happy to fix the problematic area to be clearer (it's not clear to me
> what's unclear at the moment).
>
>
> On Mon, 18 Jul 2011, Harald Alvestrand wrote:
> >
> > What is the scenario in which this behavioiur is useful?
>
> The muting feature exists in order to allow authors to mute outgoing video
> while leaving outgoing audio and while still having a local video montior.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'




-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.


From bzbarsky at MIT.EDU  Wed Jul 20 07:54:25 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 20 Jul 2011 10:54:25 -0400
Subject: [whatwg] <base> in <body>
In-Reply-To: <op.vywtptlc64w2qv@annevk-macbookpro.local>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu>
	<op.vywtptlc64w2qv@annevk-macbookpro.local>
Message-ID: <4E26EC21.3050005@mit.edu>

On 7/20/11 4:54 AM, Anne van Kesteren wrote:
> On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> That said, I'm not sure I understand the security concern. What kind
>> of whitelist-based filter would let through <script>s whose URIs it
>> does not control, exactly? Can the security concern be mitigated by
>> only allowing <base> outside <head> if the base URI it sets is
>> same-origin with the document?
>
> The <script> is from the page itself and uses a relative URL. The <base>
> is inserted by the attacker and causes the script to be requested from a
> server under the attacker's control.

OK, thanks.  That was about the only threat model I could think of here...

It sounds like my proposal above would mitigate this threat, yes?

-Boris



From annevk at opera.com  Wed Jul 20 07:59:31 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 20 Jul 2011 16:59:31 +0200
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E26EC21.3050005@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu> <op.vywtptlc64w2qv@annevk-macbookpro.local>
	<4E26EC21.3050005@mit.edu>
Message-ID: <op.vyxalhbw64w2qv@annevk-macbookpro.local>

On Wed, 20 Jul 2011 16:54:25 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/20/11 4:54 AM, Anne van Kesteren wrote:
>> On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu>  
>> wrote:
>>> That said, I'm not sure I understand the security concern. What kind
>>> of whitelist-based filter would let through <script>s whose URIs it
>>> does not control, exactly? Can the security concern be mitigated by
>>> only allowing <base> outside <head> if the base URI it sets is
>>> same-origin with the document?
>>
>> The <script> is from the page itself and uses a relative URL. The <base>
>> is inserted by the attacker and causes the script to be requested from a
>> server under the attacker's control.
>
> OK, thanks.  That was about the only threat model I could think of  
> here...
>
> It sounds like my proposal above would mitigate this threat, yes?

Yes.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From julian.reschke at gmx.de  Wed Jul 20 08:28:19 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 20 Jul 2011 17:28:19 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
Message-ID: <4E26F413.5090302@gmx.de>

On 2011-07-20 13:33, Chris Bentzel wrote:
> Who should be trusted for filename if the one specified by<a>  on the
> referring page differs from the one specified by Content-Disposition
> on the to-be-downloaded resource?
> ...

I think the header field needs to be authoritative.

That being said, if you want to go down the road, make it clear how the 
file name actually is extracted from the header field in an 
interoperable way.

Best regards, Julian


From justin.lebar at gmail.com  Wed Jul 20 08:54:22 2011
From: justin.lebar at gmail.com (Justin Lebar)
Date: Wed, 20 Jul 2011 11:54:22 -0400
Subject: [whatwg] Document's base URI should use the document's
	*current* address
In-Reply-To: <Pine.LNX.4.64.1107192115280.2079@ps20323.dreamhostps.com>
References: <BANLkTi=3DDK6pW4FXywKj8C6DRvNjFpYrQ@mail.gmail.com>
	<BANLkTikQ0P7WTZ3O6dRMs9LC4Ffkr-mzow@mail.gmail.com>
	<Pine.LNX.4.64.1107192115280.2079@ps20323.dreamhostps.com>
Message-ID: <CAFWcpZ49CvLObKVHAFm5s3qBnxSAVYR1Ft1JfV1Sra43zGcaHA@mail.gmail.com>

> The spec as written decides whether a link is a same-resource reference or
> not based on comparing the URLs to what you're calling the original
> address, not comparing it to the current address. See the navigation
> algorithm, step 7 /Fragment identifiers/.

Maybe I'm misunderstanding, but this might not be the case in the
history traversal algorithm.

> Step 6: If the specified entry has a URL whose fragment identifier differs from that of the current entry's when compared in
> a case-sensitive manner, and the two share the same Document object, then let hash changed be true.

It's not clear to me what the current/specified entry's URL is, or
where this is properly defined, but earlier, we say:

> The current entry is usually an entry for the location of the Document.

and the document's location changes when we call push/replaceState.

In any case, the navigation algorithm is clear as written.

>> As currently specified, we'll resolve #foo relative to the document's
>> original URL; that is, clicking the link will take the user to
>> page.html#foo, not page2.html#foo.  But the intent of a link with href
>> #foo is clearly to navigate within the current page, not to go somewhere
>> else.

Were you saying that this isn't the right interpretation of the spec?
Because #foo is resolved relative to the document's base URI, which is
the same as the document's original URI, so we decide that #foo is a
same-document link?  That's comforting, if it's true.  :)

> Note that there are problems with what you describe: what if the new URL
> has a different path, and there are <img> elements whose URLs are
> relative, and after pushState() you clone one? Or what about relative
> links in the original markup? I don't think we can change the base URL on
> the fly, all kinds of problems could result.

I agree there are problems with changing the base URI.  But it seems
much less intuitive for common use-cases not to change it.  We can
change my example above to use ?foo instead of #foo, and I think the
same argument applies.  Should a link with href ?foo always resolve
relative to the document's original URI (unless the base is explicitly
changed)?  Similarly, if for some bizarre reason the page pushState's
to a new directory, shouldn't all the links point relative to that new
directory?

I kind of think this ship has sailed wrt implementations.  Chrome and
Firefox both have the same behavior in this respect.  See
http://people.mozilla.org/~jlebar/whatwg/test_pushstate_resolve.html
(source included below, since I have a bad habit of deleting these
test files right before someone else wants to look at them).

Ian, how hard do you think it would be to spec changing the base and
resolve the issues with that?

-Justin

<html>
<body>
<a href='#foo'>#foo</a><br>
<a href='?foo'>?foo</a><br>
<a href='foo'>foo</a><br>
 <button onclick='history.pushState("", "", Math.random())'>pushState
to new file</button><br>
<button onclick='history.pushState("", "", Math.random() +
"/file")'>pushState to new directory</button>
</body>
</html>

On Tue, Jul 19, 2011 at 5:35 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 27 Apr 2011, Justin Lebar wrote:
>>
>> The document base URL is used when fetching resources.
>>
>> Right now, if a page doesn't have a <base> element, the document base
>> URL is set to the document's address. ?(I'm going to call this the
>> "document's original address".) ?The document's original address does
>> not change when you call pushState; only the document's current address
>> does.
>>
>> I think the base URI should use the document's current address, not the
>> original address.
>>
>> To see why this makes sense, consider the following scenario:
>>
>> * User loads page.html
>> * Page calls pushState and changes its url to page2.html
>> * User clicks on a link with href "#foo".
>>
>> As currently specified, we'll resolve #foo relative to the document's
>> original URL; that is, clicking the link will take the user to
>> page.html#foo, not page2.html#foo. ?But the intent of a link with href
>> #foo is clearly to navigate within the current page, not to go somewhere
>> else.
>>
>> Firefox 4 already implements pushState as I'm suggesting here.
>
> The spec as written decides whether a link is a same-resource reference or
> not based on comparing the URLs to what you're calling the original
> address, not comparing it to the current address. See the navigation
> algorithm, step 7 /Fragment identifiers/.
>
> Note that there are problems with what you describe: what if the new URL
> has a different path, and there are <img> elements whose URLs are
> relative, and after pushState() you clone one? Or what about relative
> links in the original markup? I don't think we can change the base URL on
> the fly, all kinds of problems could result.
>
> --
> Ian Hickson ? ? ? ? ? ? ? U+1047E ? ? ? ? ? ? ? ?)\._.,--....,'``. ? ?fL
> http://ln.hixie.ch/ ? ? ? U+263A ? ? ? ? ? ? ? ?/, ? _.. \ ? _\ ?;`._ ,.
> Things that are impossible just take longer. ? `._.-(,_..'--(,_..'`-.;.'


From Simetrical+w3c at gmail.com  Wed Jul 20 09:58:47 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 20 Jul 2011 12:58:47 -0400
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
Message-ID: <CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>

On Wed, Jul 20, 2011 at 6:14 AM, Tim Down <timdown at gmail.com> wrote:
> It's useful for custom search features. I've recommended it a few
> times on Stack Overflow for people wanting to highlight or somehow
> style all occurrences of a piece of text that may span nodes (it's
> this part that is the compelling feature). You can achieve the same
> using TextRange in IE. For example:
>
> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>
> I think this is a valid use case.

However, the implementation here doesn't do what you'd want: it
selects the text, destroying any existing selection.  You can work
around it by preserving and then restoring the selection somehow, but
it's not ideal at all.  It would make much more sense to have a
function that returned a Range or list of Ranges.

Of course, for the use-case you posted, execCommand() would also have
to work on Ranges instead of just the selection, but that should
probably be feature #1 to add to it anyway . . .


From jonas at sicking.cc  Wed Jul 20 10:02:51 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 20 Jul 2011 10:02:51 -0700
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E264659.3040004@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>
	<4E264659.3040004@mit.edu>
Message-ID: <CA+c2ei8J8eCZ-kv7n=Fa3AJ2xu6vYwnrLibCnLQQTmQt5anpoA@mail.gmail.com>

On Tue, Jul 19, 2011 at 8:07 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/19/11 9:12 PM, Ian Hickson wrote:
>>
>> Would other browser vendors be willing to change to only look at<base
>> href> ?in<head>?
>
> Gecko used to implement that back when the spec said it.
>
> This caused site compat issues. ?See
> https://bugzilla.mozilla.org/show_bug.cgi?id=593807 (United checkin outside
> the US being broken) and https://bugzilla.mozilla.org/show_bug.cgi?id=592880
> (hyperlatex output being broken) for example.
>
> The latter explicitly mentions that hyperlatex output is broken in recent IE
> versions.
>
> The former depends on the parsing behavior of IE you describe so is not a
> problem in IE9-. ?See https://bugzilla.mozilla.org/show_bug.cgi?id=593807#c7
>
> On the other hand, this change would fix CA Unicenter
> (https://bugzilla.mozilla.org/show_bug.cgi?id=627361 and its two
> duplicates), I think.
>
> So I guess it comes down to what set of sites we want to break here.... ?Do
> other UA vendors have any data on the matter?
>
> That said, I'm not sure I understand the security concern. ?What kind of
> whitelist-based filter would let through <script>s whose URIs it does not
> control, exactly? ?Can the security concern be mitigated by only allowing
> <base> outside <head> if the base URI it sets is same-origin with the
> document?

Ugh, I'd really hate to introduce such inconsistencies though.

/ Jonas


From derhoermi at gmx.net  Wed Jul 20 11:49:52 2011
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed, 20 Jul 2011 20:49:52 +0200
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
In-Reply-To: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
Message-ID: <o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>

* Takeshi Yoshino wrote:
>Use of deflate-stream is now mandatory in API spec. I think this kind of
>requirement is useless. How about leave it up to implementors' decision?
>http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

The deflate-stream extension, when used for browser to server messages
allows an attacker to put whatever bytes he likes on the wire, after a
bit of unpredictable junk. Browser vendors were pretty opposed to that
for the normal protocol without extensions, and they were opposed to
having some way to make browsers send messages "unmasked"; so it would
be very odd for browser vendors to implement the extension. And by the
looks of it, the hybi Working Group may well drop deflate-stream now.
See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From kornel at geekhood.net  Wed Jul 20 12:36:59 2011
From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=)
Date: Wed, 20 Jul 2011 20:36:59 +0100
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <4E2504BF.70504@mit.edu>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>
Message-ID: <op.vyxnfxdgte2ec8@aimac.local>

On Tue, 19 Jul 2011 05:14:55 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> This is actually an interesting question.  Does this end up  
> corresponding to:
>
>    :scope foo .bar, foo:scope .bar
>
> or to just
>
>    :scope foo .bar
>
> ?  The latter would not match on 'foo' being the scope element, while  
> the former would.

I think it should match the scoping element, as I expect this pattern to  
be common until <style scoped> is widely supported:

<div id=widget>
   <style scoped>
     #widget foo {}
   </style>
</div>

-- 
regards, Kornel Lesi?ski


From ash at ashleysheridan.co.uk  Wed Jul 20 12:55:51 2011
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Wed, 20 Jul 2011 20:55:51 +0100
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <op.vyxnfxdgte2ec8@aimac.local>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu>  <op.vyxnfxdgte2ec8@aimac.local>
Message-ID: <1311191751.577.5.camel@localhost.localdomain>

On Wed, 2011-07-20 at 20:36 +0100, Kornel Lesi?ski wrote:

> On Tue, 19 Jul 2011 05:14:55 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 
> > This is actually an interesting question.  Does this end up  
> > corresponding to:
> >
> >    :scope foo .bar, foo:scope .bar
> >
> > or to just
> >
> >    :scope foo .bar
> >
> > ?  The latter would not match on 'foo' being the scope element, while  
> > the former would.
> 
> I think it should match the scoping element, as I expect this pattern to  
> be common until <style scoped> is widely supported:
> 
> <div id=widget>
>    <style scoped>
>      #widget foo {}
>    </style>
> </div>
> 


While I agree that that might be a common pattern, I disagree that it's
actually a good one. Consider an ad service which wraps everything in a
custom <div> tag. If the scope allowed the immediate parent to be
included as part of the scope, then it could allow the advert to be
altered in a way that could negatively affect the users of the site the
ad appeared on.

The purpose of scope in the style seems to be to protect elements
outside of the included content and to 'contain' the included content
that has the <style scoped> element in it, presumably because it's
coming from an external source. If you allowed the immediate parent as
your example, then it could allow the 3rd parties who created the advert
to take over the element beyond what the advert service would prefer to
be allowed.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk




From kornel at geekhood.net  Wed Jul 20 13:37:33 2011
From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=)
Date: Wed, 20 Jul 2011 21:37:33 +0100
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <1311191751.577.5.camel@localhost.localdomain>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu> <op.vyxnfxdgte2ec8@aimac.local>
	<1311191751.577.5.camel@localhost.localdomain>
Message-ID: <op.vyxp8vhute2ec8@aimac.local>

On Wed, 20 Jul 2011 20:55:51 +0100, Ashley Sheridan  
<ash at ashleysheridan.co.uk> wrote:

>> <div id=widget>
>>    <style scoped>
>>      #widget foo {}
>>    </style>
>> </div>
>
> While I agree that that might be a common pattern, I disagree that it's
> actually a good one. Consider an ad service which wraps everything in a
> custom <div> tag. If the scope allowed the immediate parent to be
> included as part of the scope, then it could allow the advert to be
> altered in a way that could negatively affect the users of the site the
> ad appeared on.

The site could wrap the ad in another div to prevent that (and this is  
typical when the site wants to create fixed-size ad slot).

> The purpose of scope in the style seems to be to protect elements
> outside of the included content and to 'contain' the included content
> that has the <style scoped> element in it, presumably because it's
> coming from an external source. If you allowed the immediate parent as
> your example, then it could allow the 3rd parties who created the advert
> to take over the element beyond what the advert service would prefer to
> be allowed.

For rogue 3rd parties there's <iframe> in seamless and sandboxed flavors.

If author is allowing untrusted and misbehaving code in the DOM, then it's  
already game over ? the ad can do anything, including creating <style>  
without scope and modifying other stylesheets.

Even scoped style could use position:absolute or fixed to modify looks of  
something outside the element.

-- 
regards, Kornel Lesi?ski


From timdown at gmail.com  Wed Jul 20 15:23:24 2011
From: timdown at gmail.com (Tim Down)
Date: Wed, 20 Jul 2011 23:23:24 +0100
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
Message-ID: <CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>

On 20 July 2011 17:58, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Wed, Jul 20, 2011 at 6:14 AM, Tim Down <timdown at gmail.com> wrote:
>> It's useful for custom search features. I've recommended it a few
>> times on Stack Overflow for people wanting to highlight or somehow
>> style all occurrences of a piece of text that may span nodes (it's
>> this part that is the compelling feature). You can achieve the same
>> using TextRange in IE. For example:
>>
>> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>>
>> I think this is a valid use case.
>
> However, the implementation here doesn't do what you'd want: it
> selects the text, destroying any existing selection. ?You can work
> around it by preserving and then restoring the selection somehow, but
> it's not ideal at all.

Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.

> It would make much more sense to have a
> function that returned a Range or list of Ranges.

Absolutely.

> Of course, for the use-case you posted, execCommand() would also have
> to work on Ranges instead of just the selection, but that should
> probably be feature #1 to add to it anyway . . .

Agreed. My number two feature (well, it would make the top 5, at
least) would be removing the restriction on execCommand() only working
on editable content. This very use case shows that its usefulness
extends beyond editable content. The temporarily-switch-designMode-on
workaround is ugly, and destroys the selection in some browsers.

Tim


From w3c at adambarth.com  Wed Jul 20 15:54:30 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 20 Jul 2011 15:54:30 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
Message-ID: <CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>

On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Takeshi Yoshino wrote:
>>Use of deflate-stream is now mandatory in API spec. I think this kind of
>>requirement is useless. How about leave it up to implementors' decision?
>>http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
>
> The deflate-stream extension, when used for browser to server messages
> allows an attacker to put whatever bytes he likes on the wire, after a
> bit of unpredictable junk. Browser vendors were pretty opposed to that
> for the normal protocol without extensions, and they were opposed to
> having some way to make browsers send messages "unmasked"; so it would
> be very odd for browser vendors to implement the extension. And by the
> looks of it, the hybi Working Group may well drop deflate-stream now.
> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.

Isn't the obvious solution to both problems to apply compression before masking?

Adam


From derhoermi at gmx.net  Wed Jul 20 16:56:25 2011
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu, 21 Jul 2011 01:56:25 +0200
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
In-Reply-To: <CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
Message-ID: <lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>

* Adam Barth wrote:
>On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>> The deflate-stream extension, when used for browser to server messages
>> allows an attacker to put whatever bytes he likes on the wire, after a
>> bit of unpredictable junk. Browser vendors were pretty opposed to that
>> for the normal protocol without extensions, and they were opposed to
>> having some way to make browsers send messages "unmasked"; so it would
>> be very odd for browser vendors to implement the extension. And by the
>> looks of it, the hybi Working Group may well drop deflate-stream now.
>> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
>> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.
>
>Isn't the obvious solution to both problems to apply compression before masking?

There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
not a solution to the problem Takeshi Yoshino raised though, which is
about whether Websocket API conformance should impose restrictions on
which Websocket extensions must and must not be supported, as far as I
understand it anyway.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From w3c at adambarth.com  Wed Jul 20 17:13:56 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 20 Jul 2011 17:13:56 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
Message-ID: <CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>

On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>>> The deflate-stream extension, when used for browser to server messages
>>> allows an attacker to put whatever bytes he likes on the wire, after a
>>> bit of unpredictable junk. Browser vendors were pretty opposed to that
>>> for the normal protocol without extensions, and they were opposed to
>>> having some way to make browsers send messages "unmasked"; so it would
>>> be very odd for browser vendors to implement the extension. And by the
>>> looks of it, the hybi Working Group may well drop deflate-stream now.
>>> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
>>> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.
>>
>>Isn't the obvious solution to both problems to apply compression before masking?
>
> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
> not a solution to the problem Takeshi Yoshino raised though, which is
> about whether Websocket API conformance should impose restrictions on
> which Websocket extensions must and must not be supported, as far as I
> understand it anyway.

It seems pretty clear that the API specify whatever profile of the
protocol we choose.  We do the same thing with HTTP (e.g., with the
XMLHttpRequest API).

Adam


From derhoermi at gmx.net  Wed Jul 20 17:38:57 2011
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu, 21 Jul 2011 02:38:57 +0200
Subject: [whatwg] Why deflate-stream is required to be enabled by the
	WebSocket API?
In-Reply-To: <CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
	<CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>
Message-ID: <nqse27djdsv8hi3qjv9nj4egh27eurc3eh@hive.bjoern.hoehrmann.de>

* Adam Barth wrote:
>On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
>> not a solution to the problem Takeshi Yoshino raised though, which is
>> about whether Websocket API conformance should impose restrictions on
>> which Websocket extensions must and must not be supported, as far as I
>> understand it anyway.
>
>It seems pretty clear that the API specify whatever profile of the
>protocol we choose.  We do the same thing with HTTP (e.g., with the
>XMLHttpRequest API).

HTTP allows you to send messages with `Transfer-Encoding: gzip,chunked`.
Opera supports that in responses, most other browsers do not. The XML-
HttpRequest specification takes no position on that, you can conform to
it whether the XMLHttpRequest implementation supports that or not. The
browsers do agree on supporting `Content-Encoding: gzip`, but again the
XMLHttpRequest specification does not require or prohibit supporting it.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From w3c at adambarth.com  Wed Jul 20 17:43:22 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 20 Jul 2011 17:43:22 -0700
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <nqse27djdsv8hi3qjv9nj4egh27eurc3eh@hive.bjoern.hoehrmann.de>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<lppe279p161r8bf7897uonqlrdle1fe7o6@hive.bjoern.hoehrmann.de>
	<CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>
	<nqse27djdsv8hi3qjv9nj4egh27eurc3eh@hive.bjoern.hoehrmann.de>
Message-ID: <CAJE5ia915E7TobEo0CUTjE9=G7QWwJ1_tZNzwzTvSmsu4i6hdw@mail.gmail.com>

On Wed, Jul 20, 2011 at 5:38 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>>> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
>>> not a solution to the problem Takeshi Yoshino raised though, which is
>>> about whether Websocket API conformance should impose restrictions on
>>> which Websocket extensions must and must not be supported, as far as I
>>> understand it anyway.
>>
>>It seems pretty clear that the API specify whatever profile of the
>>protocol we choose. ?We do the same thing with HTTP (e.g., with the
>>XMLHttpRequest API).
>
> HTTP allows you to send messages with `Transfer-Encoding: gzip,chunked`.
> Opera supports that in responses, most other browsers do not. The XML-
> HttpRequest specification takes no position on that, you can conform to
> it whether the XMLHttpRequest implementation supports that or not. The
> browsers do agree on supporting `Content-Encoding: gzip`, but again the
> XMLHttpRequest specification does not require or prohibit supporting it.

XMLHttpRequest imposes restrictions on the HTTP transport that are not
imposed by HTTP itself.  I don't see any reason why an API can't
restrict the protocol elements generated through the use of the API.
You can argue whether we should impose those restrictions, but we
certainly can.

Adam


From jat at google.com  Wed Jul 20 18:12:56 2011
From: jat at google.com (John Tamplin)
Date: Wed, 20 Jul 2011 21:12:56 -0400
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
Message-ID: <CABLsOLA0z-+Z4McW8LH2ziZm-o-x8CcPe=_95msWFGyVyiuvGA@mail.gmail.com>

On Wed, Jul 20, 2011 at 6:54 PM, Adam Barth <w3c at adambarth.com> wrote:

> Isn't the obvious solution to both problems to apply compression before
> masking?
>

Yes.  However, that is not what deflate-stream does.  There has been a
proposal for deflate-frame which would do exactly that, but it has not been
accepted as of yet and there seems to be some resistance to including it in
the base spec at the expense of further delaying it.

deflate-stream was created as a "better than nothing" compression nobody
objected to that served as an example in the spec of an extension.  Since
then, largely due to your work, masking client->server traffic was added
which reduced the value of deflate-stream in that direction and also
requiring the extension be handled outside the normal framing.

The fact that the WS API would mandate deflate-stream and not allowing
browser to support other extensions would in fact prevent the deployment of
deflate-frame later, or for that matter any other improvements.  I could
hope that browsers would ignore that requirement and support other
extensions, but then the spec isn't reflecting reality.

As a further example, if multiplexing is added later, it may well need to
have compression at a different level (otherwise mux/demux operations have
to decompress and recompress) -- mandating deflate-stream would again
complicate that scenario.

-- 
John A. Tamplin
Software Engineer (GWT), Google


From shawn at mozilla.com  Thu Jul 21 12:31:22 2011
From: shawn at mozilla.com (Shawn Gong)
Date: Thu, 21 Jul 2011 12:31:22 -0700 (PDT)
Subject: [whatwg] About the HTML spec inconsistency in URL APIs' Collect URL
 Parameters definition
In-Reply-To: <2061317895.598589.1311274186203.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <1834458172.599023.1311276682070.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

Hello,

When collecting URL Parameters, if we have "a&&b", since the parameter between "&&" is empty, we ignore it, and get the parameterNames ["a", "b"]; however, if we have "a&=&b" then we'll get a parameter with empty name and empty value, and have the parameterNames ["a", "", "b"]. The two behaviors are inconsistent. Should we modify the spec to keep the consistency?

Best,
Shawn Gong

(Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en)


From Simetrical+w3c at gmail.com  Thu Jul 21 12:59:53 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 21 Jul 2011 15:59:53 -0400
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
	<CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
Message-ID: <CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>

On Wed, Jul 20, 2011 at 6:23 PM, Tim Down <timdown at gmail.com> wrote:
> Yes, but it's significantly better than the alternative, which is to
> write your own code to search for text that spans nodes.

It shouldn't be *too* hard to write that code.  First do the search in
textContent and get a list of the offsets of all the results.  Then
get a list of Text nodes, and iterate through them.  Record the sum of
their lengths as you go, and when you get to the right place, store
the result.  I'd guess it would be 20 lines or so.  Something like
this (untested):

function findStrings(root, search) {
    var offsets = [];
    for (var i = root.textContent.indexOf(search); i != -1; i =
root.textContent.indexOf(search, i + 1)) {
        offsets.push(i);
    }
    var results = [];
    var treeWalker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT);
    var currentOffset = 0;
    while (treeWalker.nextNode()) {
        while (offsets.length
        && currentOffset <= offsets[offsets.length - 1]
        && offsets[offsets.length - 1] < currentOffset +
treeWalker.currentNode.length) {
            results.push([treeWalker.currentNode,
offsets[offsets.length - 1] - currentOffset]);
            offsets.pop();
        }
        currentOffset += treeWalker.currentNode.length;
    }
    return results;
}

Probably buggy, but something like that should work.  (And hey, it's
19 lines, good guesswork.)  Granted, if you wanted to do any kind of
normalization it would be more complicated to author, but also more
complicated to spec.  So I don't see really a use-case here that's
strong enough to justify this, if we can get rid of it.

> Agreed. My number two feature (well, it would make the top 5, at
> least) would be removing the restriction on execCommand() only working
> on editable content. This very use case shows that its usefulness
> extends beyond editable content. The temporarily-switch-designMode-on
> workaround is ugly, and destroys the selection in some browsers.

As I said elsewhere, I disagree.  Wanting to only modify editable
content is an important use-case.  It's easy to emulate the behavior
you want if that restriction is in place (temporarily turn on
designMode), but nearly impossible to emulate the opposite behavior if
it's not built in to start with.  If execCommand() worked on any
content at all, then text editors would be permanently forced to use
iframes with designMode instead of being able to use contenteditable,
just to avoid the user randomly bolding or deleting interface text.
Also, it would mean that (for instance) execCommand("delete") works
differently from the backspace key.

If turning designMode on destroys the selection in some browsers,
that's a bug that can easily be fixed, and doesn't justify a change to
the spec.  Changing specs to work around easily-fixed browser bugs
makes much less sense than just fixing the bugs.  The only
disadvantage I see to requiring this is that it's error-prone: the
obvious way to do it is to turn designMode on and then turn it off,
which will have an unexpected side effect if it had already been on.
But that's a minor issue, and I don't see a good way to avoid it.

Why exactly do you not want to turn designMode on and off, other than
easily-fixed browser bugs?  What do you think is "ugly" about it?


From hbono at google.com  Thu Jul 21 20:03:06 2011
From: hbono at google.com (=?ISO-2022-JP?B?SGlyb25vcmkgQm9ubyAoGyRCSzdMbhsoQiAbJEJHbkU1GyhCKQ==?=)
Date: Fri, 22 Jul 2011 12:03:06 +0900
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
Message-ID: <CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>

Greetings all,

This is just out of curiosity.
Would it be possible to give me the encoding used for this "download"
attribute? I think we have several options when we use non-ASCII
characters (this example uses Cyrillic characters) as the value of
this attribute as listed below.

1. Use the same encoding as the one used for the HTML content.
  <a href="..."  download="????.png">????????? ????</a>
(If we allow using '&#x...' format of HTML, it becomes:
  <a href="..."  download="&#x444;&#x430;&#x439;&#x43B;.png">????????? ????</a>

2. Use the URL encoding (same as the "href" attribute).
  <a href="..."  download="%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>

3. Use RFC 2231 (same as the "content-disposition" header)
  <a href="..."
download="UTF-8''%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>

Thank you for your help in advance.

Regards,

Hironori Bono
E-mail: hbono at google.com

On Sat, Jul 16, 2011 at 10:59 AM, Ian Fette (????????)
<ifette at google.com> wrote:
> On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> 2011/7/15 Jonas Sicking <jonas at sicking.cc>
>>
>>> It definitely is an interesting usecase that Glenn brought up about
>>> being able to specify a save-as name without otherwise modifying the
>>> behavior of a reference. However that seems like a much more rare
>>> usecase and so not the one we should optimize for.
>>>
>>
>> Bear in mind that "optimize for" doesn't mean "support at all"; if
>> download=filename is used, it seems unlikely that there will ever be *any*
>> client-side way to supply the filename without implying attachment, which is
>> a very different thing than "not optimizing for it".
>>
>> I don't feel strongly enough about this to press it further, but <a
>> href=ugly download filename=pretty> also seems fairly clean, and avoids
>> combining parameters that really are orthogonal to one another.
>>
>
> I really don't see the importance of the "name the thing that isn't going to
> be downloaded" usecase; there are countless edge cases that we could concern
> ourselves with in HTML but that few users will ever hit, this is one. (I
> also suspect a user sophisticated enough to actually save something, e.g.
> right click save as, is sophisticated enough to be able to type their own
> filename.)I think it's better overall to keep the semantics as clean and
> simple as possible. I suggest we move forward with <a href=blah
> download=filename> with the origin considerations mentioned in the previous
> email and move on.
>
>
>
>
>>
>> --
>> Glenn Maynard
>>
>>
>


From callow_mark at hicorp.co.jp  Thu Jul 21 20:51:46 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Fri, 22 Jul 2011 12:51:46 +0900
Subject: [whatwg] <base> in <body>
In-Reply-To: <op.vywtptlc64w2qv@annevk-macbookpro.local>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>	<4E264659.3040004@mit.edu>
	<op.vywtptlc64w2qv@annevk-macbookpro.local>
Message-ID: <4E28F3D2.2090207@hicorp.co.jp>

> On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky <bzbarsky at mit.edu>
> wrote:
>> That said, I'm not sure I understand the security concern.  What kind
>> of whitelist-based filter would let through <script>s whose URIs it
>> does not control, exactly?  Can the security concern be mitigated by
>> only allowing <base> outside <head> if the base URI it sets is
>> same-origin with the document?
>
> The <script> is from the page itself and uses a relative URL. The
> <base> is inserted by the attacker and causes the script to be
> requested from a server under the attacker's control.
>
>
Seems like a bug in the whitelist filter to me. Shouldn't the filter be
checking requests using the full URL just before they are dispatched?

Regards

    -Mark


From bzbarsky at MIT.EDU  Thu Jul 21 20:58:11 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 21 Jul 2011 23:58:11 -0400
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E28F3D2.2090207@hicorp.co.jp>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>	<4E264659.3040004@mit.edu>	<op.vywtptlc64w2qv@annevk-macbookpro.local>
	<4E28F3D2.2090207@hicorp.co.jp>
Message-ID: <4E28F553.6050708@mit.edu>

On 7/21/11 11:51 PM, Mark Callow wrote:
> Seems like a bug in the whitelist filter to me. Shouldn't the filter be
> checking requests using the full URL just before they are dispatched?

We're talking a filter on the HTML generation, not in the browser.

-Boris


From callow_mark at hicorp.co.jp  Thu Jul 21 23:49:49 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Fri, 22 Jul 2011 15:49:49 +0900
Subject: [whatwg] <base> in <body>
In-Reply-To: <4E28F553.6050708@mit.edu>
References: <Pine.LNX.4.64.1107200101510.3775@ps20323.dreamhostps.com>	<4E264659.3040004@mit.edu>	<op.vywtptlc64w2qv@annevk-macbookpro.local>	<4E28F3D2.2090207@hicorp.co.jp>
	<4E28F553.6050708@mit.edu>
Message-ID: <4E291D8D.5020607@hicorp.co.jp>

> On 7/21/11 11:51 PM, Mark Callow wrote:
>> Seems like a bug in the whitelist filter to me. Shouldn't the filter be
>> checking requests using the full URL just before they are dispatched?
>
> We're talking a filter on the HTML generation, not in the browser.
>
> -Boris
Ahh! Got it. Thanks.

    -Mark


From ian at hixie.ch  Thu Jul 21 23:58:44 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 06:58:44 +0000 (UTC)
Subject: [whatwg] Forcing a download
In-Reply-To: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>

On Sat, 9 Apr 2011, Glenn Maynard wrote:
> >
> > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
> 
> A big +1 to the proposal in this thread, to allow specifying 
> Content-Disposition behavior in anchors.

I believe I last responded to feedback on this topic in August last year:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028148.html

...with a minor addition in December:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029350.html

However, feedback since has introduced a new wrinkle that I do not believe 
was thoroughly examined in previous threads on the topic: the issue of how 
to specify an explicit filename, which is especially relevant for a number 
of use cases mentioned below.


> <a download=filename.txt> would have the effect of adding (or 
> overriding) the header "Content-Disposition: attachment; 
> filename=filename.txt".
> 
> It would mean I'd no longer need to use server-side hacks to cause 
> Content-Disposition to be sent for download links, eg. where 
> "?download=1" adds the C-D header.
> 
> I also just now had to implement a server-side script that receives 
> base64 file data and a filename in parameters, and responds by echoing 
> it back. That's an ugly hack to allow client-side data to be saved to 
> disk, and doesn't work with serverless web apps.  This would be fixed, 
> allowing both data: URLs and File API object URLs as download links.

This download="" attribute seems like a reasonable idea.


On Sun, 10 Apr 2011, Bjartur Thorlacius wrote:
>
> Right. As an end-user I ask: Does a web developer publishing links to 
> resources have a say as to whether I render aforementioned resource 
> immediately, write it to disk or both?

It should always be up to the user to have the final say, but the use 
cases presented here suggest that it makes sense to at least give authors 
the opportunity to provide a hint as to what the default behaviour should 
be for links.


> Better yet, File API could have an API for writing blobs to files.

That would help for some of these cases, but not most. It would also mean 
that what could be expressible purely declaratively requires script, which 
is something we generally try to avoid. Declarative semantics are easier 
to process using static analysis tools, for instance.


On Sun, 10 Apr 2011, Glenn Maynard wrote:
>
> (Browsers generally don't have a "show this file in the browser, even 
> though it's C-D: attachment" option on that dialog--they should, but 
> that's a separate issue.)

Indeed, that should probably be addressed as well.


On Thu, 26 May 2011, Dennis Joachimsthaler wrote:
> 
> The filename is only necessary when you feed the file from a dynamic 
> page, like directly from the PHP processor. And in this case you can 
> directly use the contend-disposition HTTP header.

That prevents a single resource from being offered either for view or 
download, unfortunately (users should be able to use context menus, but in 
practice few users do).


> You have files in a folder that are numbered in one continous numbering 
> scheme. The files are heavily downloaded so server side scripting falls 
> out of the question because sending files through this is, to say the 
> least, slow, unless you use some special tricks.
> 
> Instead of giving the user a link to the file called "A342378437.pdf" 
> you can use the disposition attribute to
> 
> a) Let him directly download it. He doesn't have to go the long way 
> around by right clicking this way.
> 
> b) Give it a meaningful name that the user will appreciate

Indeed.


On Fri, 3 Jun 2011, Bjartur Thorlacius wrote:
>
> Use the last non-empty path component for a short name prone to 
> accidental clashes, or the title for a verbose, unportable and 
> descriptive name. It's purely a hint for user convenience (so they don't 
> have to invent their own names or retype the title). What a file is 
> named on a client's machine is purely the client's matter.

Using the title="" doesn't really work because what is appropriate for a 
tooltip and what is appropriate for a filename might not match.


On Thu, 14 Jul 2011, Ian Fette wrote:
>
> Many websites wish to offer a file for download, even though it could 
> potentially be viewed inline (take images, PDFs, or word documents as an 
> example). Traditionally the only way to achieve this is to set a 
> content-disposition header. *However, sometimes it is not possible for 
> the page author to have control over the response headers sent by the 
> server.* (A related example is offline apps, which may wish to provide 
> the user with a way to "download" a file stored locally using the 
> filesystem API but again can't set any headers.) It would be nice to 
> provide the page author with a client side mechanism to trigger a 
> download.
> 
> After mulling this over with some application developers who are trying 
> to use this functionality, it seems like adding a "rel" attribute to the 
> <a> tag would be a straightforward, minimally invasive way to address 
> this use case. <a rel=attachment href=blah.pdf> would indicate that the 
> browser should treat this link as if the response came with a 
> content-disposition: attachment header, and offer to download/save the 
> file for the user.

On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
> 
> rel="enclosure" is sufficient for today's use cases because authors 
> simply name the file accordingly on their server and then 
> implementations simply use the last segment of the URL as the filename - 
> presto 80/20 case solved (and solved 6 years ago with no modification 
> needed to HTML for it to be valid).
>
> Having to specify a "download" attribute that reflects a filename 
> different from the last segment of the URL is the minority case, but 
> still sufficient to justify addition of the attribute.

We can just say that if the attribute has no value it is indicating that 
the author recommends downloading the file. No need for redundancy.


On Fri, 15 Jul 2011, Alexey Proskuryakov wrote:
> 
> What meaning will this attribute have on a platform that simply doesn't 
> expose the notion of a file?

None, presumably the same as "Content-Disposition: attachment" in the same 
case.


> I think that this attribute could be quite confusing, and it will likely 
> become more confusing with time, as more platforms arise that have 
> creative ways of presenting data to users.

Could you elaborate on what confusion you are expecting here?


> It also doesn't naturally help understanding that it's just poor man's 
> Content-Disposition:attachment. From this point of view, I like Ian's 
> original proposal (rel=attachment) more.

Unfortunately, not being able to provide a file name makes it inadequate 
for a number of use cases people have raised.


On Thu, 14 Jul 2011, Glenn Maynard wrote:
> 
> That reminds me of something download=filename can't do: assign a 
> filename while leaving it inline, so "save as" and other operations can 
> have a specified filename.  That would require two separate properties.  
> One case I've come across is <img>, where I want to display an image, 
> but provide a different filename for save-as.  Separating the filename 
> would allow this to be applied generically both links and inline 
> resources: <img src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg 
> filename=picture.jpg>.

I haven't addressed this use case here, but it's definitely something we 
can investigate in the future if download="" proves successful.

(Note that for same-origin cases, you can use Content-Disposition for this 
already. This would only really help with embedding images from other 
sites that don't support giving a filename, e.g. Flickr.)


On Fri, 15 Jul 2011, Glenn Maynard wrote:
> 
> Bear in mind that "optimize for" doesn't mean "support at all"; if 
> download=filename is used, it seems unlikely that there will ever be 
> *any* client-side way to supply the filename without implying 
> attachment, which is a very different thing than "not optimizing for 
> it".
> 
> I don't feel strongly enough about this to press it further, but <a 
> href=ugly download filename=pretty> also seems fairly clean, and avoids 
> combining parameters that really are orthogonal to one another.

On Sat, 16 Jul 2011, Tantek ?~Gelik wrote:
>
> Agreed with Glenn, narrowing the semantic solves this problem neatly:
> 
> * filename="" attribute - what to name the file if saved by the user (by whatever means)
> * existing rel="enclosure" spec - download the link when clicked/activated.
> 
> So the author can choose to do one, or the other, or both. Clean, 
> simple, orthogonal.

On Fri, 15 Jul 2011, Ian Fette wrote:
> 
> I really don't see the importance of the "name the thing that isn't 
> going to be downloaded" usecase; there are countless edge cases that we 
> could concern ourselves with in HTML but that few users will ever hit, 
> this is one. (I also suspect a user sophisticated enough to actually 
> save something, e.g. right click save as, is sophisticated enough to be 
> able to type their own filename.)I think it's better overall to keep the 
> semantics as clean and simple as possible. I suggest we move forward 
> with <a href=blah download=filename> with the origin considerations 
> mentioned in the previous email and move on.

On Sun, 17 Jul 2011, Glenn Maynard wrote:
> 
> A common case is generated PDFs, which are regularly both saved to disk 
> and viewed in-browser (eg. tax forms which are viewed to print and then 
> saved for records).

This is easily solved by providing two links, or an iframe and a link. 
This is probably more usable than one link and expecting the user to 
right-click, too. As Ian says above, if the user is savvy enough to 
right-click, the user is likely not going to find it difficult to give the 
file a name either.


On Thu, 14 Jul 2011, Karl Dubost wrote:
> 
> A random thought just occured to me (maybe dumb)
> But is it a relation qualifier or in fact a target?
>
> [...] what about adding 
> 
> <a href="foo.pdf" target="_download">Save a Tree, Eat a beaver</a>

On Thu, 14 Jul 2011, Bjartur Thorlacius wrote:
>
> This seems like the best solution to me. A filename hint has two use 
> cases: a suggestion for a local identifier, and providing a filename 
> extension for systems that use them to identify file types with 
> incomplete or nonexistent /etc/mime.type media type mappings. I'll only 
> name so many pictures "pic.jpg", so I suggest using the descriptive (and 
> thus verbose) value of the title attribute. The worst problem will be 
> encoding the name on filesystems such as FAT.
> 
> <a href="//samplecdn.example/pix/2011/7/14/party/cake" 
> title="S??kkula??ikaka me?? ??s" target="_download">Afm??liskaka 
> m??n</a>

On Fri, 15 Jul 2011, Jonas Sicking wrote:
> 3)  The target=_download idea is interesting, but I'm not sure we can 
> safely introduce new target values, and this also suffers from not 
> providing a way to specify the downloaded filename.

Indeed.


On Sat, 30 Apr 2011, Michal Zalewski wrote:
>
> Downloading files in general is a very problematic area, because there's 
> a very fragile transition between HTTP MIME type and filesystem 
> extension or other OS-level content determination mechanism. Many 
> browsers either don't try to do anything useful to prevent weird 
> "promotions" from safe to unsafe document types; or enforce decidedly 
> imperfect logic. Allowing attackers to further control this process has 
> some risks.
> 
> [ This is further compounded by the fact that in many cases, it is safer 
> for users to open certain document types, HTML included, from http: URLs 
> than from file:. ]

On Sat, 30 Apr 2011, Michal Zalewski wrote:
> 
> My concern is a bit more straightforward. To use a practical example: 
> just because a social networking site allows nearly arbitrary JPEG files 
> to be uploaded and served as profile pictures (Content-Type: image/jpeg) 
> does not mean that the applications wants users to be offered that 
> content as a download named Security_Update.exe, supposedly coming from 
> that trusted site.

Well again, making sure you don't put an extension on a file that does
not correspond to the type of the resource as reported by the third-party 
site seems like an elementary precaution.


On Thu, 26 May 2011, Boris Zbarsky wrote:
> > 
> > So what does Firefox do in this case?
> 
> I believe it forces the extension to match the MIME type; if the type 
> text/plain the saved filename will be "Important_Security_Update.exe.txt".

That seems like a rather desireable property.


On Thu, 26 May 2011, Boris Zbarsky wrote:
> On 5/26/11 3:12 PM, Dennis Joachimsthaler wrote:
> > Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python 
> > #!/bin/bash could very well result in the text file being executed in 
> > one of those interpreters, right?
> 
> Yes, but even worse on some systems a .pl file will just handed over to 
> the registered handler for those (often a Perl interpreter) if you try 
> to "open" it (which is a different operation from "execute" and can be 
> done even on files that are not executable; think double-clicking the 
> file in a file manager).

The disparity of behaviours amongst file managers on Unix systems is 
indeed problematic. I'm not sure what to suggest there.


On Fri, 3 Jun 2011, Eduard Pascual wrote:
> 
> My post was entirely about the precedence between the two sources of the 
> header, when they conflict. I think is obvious enough that the provider 
> of a resource should be given more weight than a third party referencing 
> to it. Either of the sides can still leave things to whatever default 
> could apply to each case if they don't care; but if both care, and they 
> conflict, the provider of the resource should have the final say over 
> whatever the third party may be requesting.

I don't think it's obvious. In particular, there is a big difference 
between how a link with a download="" attribute could be processed 
compared to how a regular hyperlink could be processed: in the latter 
case, the UA only knows it's going to be a download some way into 
processing the navigation request (and after some irreversible steps like 
aborting other downloads); in the former case, we can bypass all that and 
just do a direct download without navigating to the resource.


A number of people raised issues relating to download="" confusing the 
issue of which origin to trust:

On Sat, 30 Apr 2011, Michal Zalewski wrote:
>
> Note that somewhat counterintuitively, there would be some security 
> concerns with markup-level content disposition controls (or any JS 
> equivalent). For example, consider evil.com doing this:
> 
> <a href='http://example.com/user_content/harmless_text_file.txt' 
> disposition='attachment; filename="Important_Security_Update.exe"'>

On Sat, 30 Apr 2011, Glenn Maynard wrote:
> 
> To do some contriving, in trying to follow the example: if example.com 
> is a site trusted by the user or administrator, it may be flagged in the 
> browser as "always allow saving sensitive file types from this site".  
> If you can override the C-D header remotely, and if there exists (for 
> example) a text file whose contents happen to alias to a dangerous 
> executable, then you could cause a dangerous executable to be saved to 
> disk.  Browsers might need a mechanism to remember whether the effective 
> Content-Disposition header is "trusted" (received from the response, or 
> overridden from the same origin) or not, which is sort of annoying.

On Thu, 2 Jun 2011, Glenn Maynard wrote:
>
> I don't think the issue raised was about getting people to save files, 
> though.  If you can get someone to click a link, you can already point 
> them at something that sets the HTTP C-D header.
> 
> As I recall, the concern was about getting people to do this on files 
> that appear to be from a trusted domain.  That is, evil.com linking to a 
> perl script on trusted.com (or, say, a dual-mode image/ELF file), 
> setting C-D in the link to get it to save-as, perhaps hoping that people 
> will see "from: http://trusted.com" in the save-as dialog.  (I doubt 
> that most users look at that at all; Chrome doesn't even seem to bother 
> displaying it.)
> 
> At worst, it just seems like a minor UI design issue.

On Thu, 2 Jun 2011, Michal Zalewski wrote:
>
> The origin of a download is one of the best / most important indicators 
> people have right now (which, by itself, is a bit of a shame). I just 
> think it would be a substantial regression to make it possible for 
> microsoft.com or google.com to unwittingly serve .exe / .jar / .zip / 
> .rar files based on third-party markup.
> 
> Firefox and MSIE display the origin fairly prominently, IIRC; Chrome 
> displays it in some views. But deficiencies of current UIs are probably 
> a separate problem.

On Thu, 2 Jun 2011, Glenn Maynard wrote:
> 
> Firefox displays it in a small, unimportant-looking piece of text inside 
> a busy dialog; I never even consciously noticed it until I looked for 
> it.  For me, Chrome doesn't say anything; when I click an .EXE it saves 
> it to disk without asking (maybe I changed a preference somewhere--that 
> seems like an unlikely default).
> 
> When I download a file, I decide whether to trust "dangerous" file types 
> based on who's telling me to download it--that is, based on the site 
> linking the file, not the site hosting it.  I'd strongly suspect that 
> more people look at who's linking the file (eg. where they were when 
> they clicked the link), and that very few people examine the "from:" 
> text in the save-as dialog.
> 
> Either way, again this is something that can be dealt with in UI, for 
> example by displaying the source URL as the source of the download 
> rather than or in addition to the domain hosting the file when this 
> attribute is used.  It's a weak argument against this feature.

On Fri, 15 Jul 2011, Jonas Sicking wrote:
>
> One concern which was brought up was the ability to cause the user to 
> download a file from a third party site. I.e. this would allow evil.com 
> to trick the user into downloading an email from the users webmail, or 
> download a page from their bank which contains all their banking 
> information. It might be easier to then trick the user into re-uploading 
> the saved file to evil.com since from a user's perspective, it looked 
> like the file came from evil.com
> 
> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file
> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com
> 
> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.
> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.
> 
> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.
> 
> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.
> 
> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.

On Sun, 17 Jul 2011, Adam Barth wrote:
> 2011/7/15 Jonas Sicking <jonas at sicking.cc>:
> >
> > One concern which was brought up was the ability to cause the user to 
> > download a file from a third party site. I.e. this would allow 
> > evil.com to trick the user into downloading an email from the users 
> > webmail, or download a page from their bank which contains all their 
> > banking information. It might be easier to then trick the user into 
> > re-uploading the saved file to evil.com since from a user's 
> > perspective, it looked like the file came from evil.com
> 
> It seems like the solution to that problem is to be clear about where 
> the download is coming from.  Being clear about where downloads come 
> from is important in many scenarios, beyond just this setting.
> 
> > Another possible attack goes something like:
> > 1. evil.com tricks the user into downloading sensitive data from bank.com
> > 2. evil.com then asks the user to download a html from evil.com and
> > open the newly downloaded file
> 
> Most browsers treat downloaded HTML files as "dangerous downloads," 
> which means they get similar UI treatment to executable downloads. For 
> example, on Mac OS X, HTML downloads get the same "you're about to open 
> a dangerous file" warning from the operating system as executable 
> downloads.  If the attacker can convince the the user to click past 
> these dialogs, the attacker can convince the user to run arbitrary code 
> anyway, so there's nothing we can do to provide security in this 
> setting.
> 
> > 3. the html file contains script which reads the contents from the 
> > file downloaded from bank.com and sends it back to evil.com
> 
> This sounds like a security vulnerability in the browser.  A better 
> security posture is to not allow downloaded content from one web site 
> read downloaded content from another web site, regardless of how the 
> content was downloaded.  For example, that's the current behavior of 
> Chrome and Internet Explorer.  Safari takes a different approach and 
> allows downloaded HTML content to access any file and any web site, 
> which means the attacker doesn't need to go through the elaborate 
> process you've outlined.  Merely performing step (3) is sufficient to 
> steal all the user's banking details today, which tells me that either 
> Safari is already vulnerable to this attack without this new feature or 
> that this threat isn't actually much of a risk.
> 
> (I know that Firefox has a policy that's somewhere in between the strong 
> local-file security policy used by Chrome and the weak policy used by 
> Safari, but Firefox's policy is too complex for me to understand.  I 
> know that protection of downloaded files was one of the considerations 
> that fed into the design of Firefox's policy, but I'll leave it to 
> others to common on whether it provided effective protection in this 
> scenario.)
> 
> > Step 1 and 2 require the user to answer "yes" to a dialog displayed by 
> > the browser. However it's well known that users very often hit 
> > whichever button they suspect will make the dialog go away, rather 
> > than actually read the contents of the dialog.
> 
> In that model, the attacker can just run arbitrary code.  It's not 
> possible to provide security in that model, regardless of this feature.
> 
> > Step 3 again requires the user to answer "yes" to a dialog displayed 
> > by the browser in at least some browsers. Same caveat applies though.
> 
> In this case, the caveats are important.  As described above, Chrome is 
> not vulnerable to this attack and Safari is vulnerable to this attack 
> even without this feature.
> 
> > One very simple remedy to this would be to require CORS opt-in for 
> > cross-site downloads. For same-site downloads no special opt-in would 
> > be required of course.
> 
> I'm not convinced there's a problem to solve here.  Wiring CORS into the 
> download system, by contrast, add a significant amount of complexity to 
> the implementation, which is costly.
> 
> > It's also possible that it would be ok to do this without any opt-ins 
> > since there are a good number of actions that the user has to take in 
> > all these scenarios. Definitely something that I'd be ok with 
> > discussing with our security team.
> 
> I'm happy to talk it over with your security folks if they disagree with 
> the contents of this email.

(Jonas questioned some of the premises above, but not Adam's basic points 
which IMHO make the presented risk somewhat irrelevant as the same 
assumptions would lead to far bigger problems already.)


> > Tentatively I would feel safer with the CORS option though. And again, 
> > for same-site downloads this isn't a problem at all, but I suspect 
> > that in many cases the file to be downloaded is hosted on a separate 
> > server.
> 
> It's important to think these scenarios through carefully, but in this 
> case I think we're fine without CORS.

In fact, using CORS here seems like it would _add_ a vulnerability: it 
would mean that any site that wants to allow another site to let the user 
download a file from that site can in addition simply read the file! Given 
the huge amount of concern we have shown over the possibility that authors 
will accidentally set CORS headers on too many pages, this sounds like a 
very dangerous thing to be encouraging.


Adam Barth also wrote:
> 
> There's also complexity for authors, who need to set the appropriate 
> headers and to worry about authenticated versus unauthenticated 
> requests.  Worse, in some deployment scenarios, requiring CORS to use 
> this feature actually exposes the sites to greater risk because they 
> might set ACLs on these resources that are broader than needed. Here's 
> an example:
> 
> 1) A webmail service wants to offer attachments for download.
> 2) The webmail service is security conscious, so it renders email
> messages in a sandboxed iframe in case it's email rendering contains
> an XSS hole (which is quite possible, especially with rich-text, HTML
> email).
> 3) The webmail service wants to include links to download email
> attachments using this feature.
> 
> In order for the links to work (assuming the links appear in context in 
> the email, as they do in Outlook, for example), the webmail provider 
> needs to set CORS headers that grants the sandboxed iframe access to the 
> attachments.  Because the sandboxed iframe runs in a unique origin (for 
> maximum security), the only CORS ACL that works is 
> "Access-Control-Allow-Origin: *".  However, that ACL allows any other 
> web site to read the contents of the user's attachments!  Now, maybe you 
> could work around that issue using unguessable URLs for the attachments, 
> but you'd still be exposing the contents of the attachments if there's 
> an XSS in the mail rendering code, a vulnerability that would not be 
> present if the downloads feature wasn't coupled to CORS.
> 
> In summary, using CORS for this purpose is costly (both to implementors 
> and to authors), and I don't think it solves a real security problem.

Indeed.


On Fri, 15 Jul 2011, Ian Fette wrote:
> 
> So, in the interest of making progress, what if we tried...
> 
> download=filename
> 
> for same origin it's always downloaded (includes filesystem api from 
> that origin) for cross-origin it's downloaded if we get a positive CORS 
> response and/or we get a content-disposition attachment for cross-origin 
> if we don't get positive CORS response OR content-disposition:attachment 
> we don't download
> 
> We can always start conservative and broaden out.

On Fri, 15 Jul 2011, Jonas Sicking wrote:
> 
> I know that I would personally feel a lot more comfortable if the site 
> opted in to allowing downloads of the resource in question. But it's 
> quite possible that I'm overly paranoid.
> 
> Though one thing to keep in mind is sites that explicitly state that a 
> resource should *not* reach the users disk. This is today often done 
> using "Cache-Control: no-store". Seems scary to allow such content to be 
> saved based on a cross-site request.

On Mon, 18 Jul 2011, Jonas Sicking wrote:
> 
> Any site that want to allow downloads without risking sharing data can 
> simply add "content-disposition: attached" headers. So no risk of 
> leaking too much data required.

Is there any reason to use CORS here at all? It seems like the simpler 
solution would be the following:

 - If download="" is set, then by default trigger a download rather than a 
   navigation action. (User can override via context menu.)
 - Pick a filename for the download as follows:
   - if the received resource has a Content-Disposition: attachment header 
     that specifies a filename, use that.
   - otherwise, if the received resource has a Content-Disposition header 
     that specifies a filename, and the resource is same-origin, use that
     filename.
   - otherwise, if the received resource is same-origin and the 
     download="" attribute specifies a filename, use that.
   - otherwise, if the received resource has a Content-Disposition: 
     attachment header and the download="" attribute specifies a filename, 
     use the filename from the attribute.
   - otherwise, if the received resource is same-origin then derive a 
     filename from the resource.
   - otherwise, either abort or alert the user that a file is being 
     downloaded from a different origin and prompt for a filename.
 - If a mapping from the MIME type to an extension is known, but the 
   filename doesn't have that extension, add it.

This is what I've used for now (modulo some allowances for user 
interfaces), but I welcome suggests for changing this.

One thing this doesn't handle is the case of a resource on the server not 
having a known type, and the download="" filename (or indeed the URL 
itself) having a potentially dangerous extension (like .exe). I figure 
this is no more dangerous than the server having the right type in this 
case, if the right type is a dangerous type.


On Mon, 18 Jul 2011, Glenn Maynard wrote:
> 
> If I link directly to the file to download, users should trust the file 
> as much as they trust *my* site, rather than Google itself, since the 
> download is, from their perspective, coming from me and not them.

It's not quite that simple. If your site is an HTTPS site, and you link to 
an HTTP site, then the downloaded resource musn't be trusted as much as 
your site, since it could have been tampered with in-flight.


> So, if a hosting service doesn't want to allow executable files, it 
> won't show files as executable from their own download pages, which is 
> what should matter as far as that site's trust is concerned.  People 
> using this mechanism to serve executable files from external links may 
> be annoying, but it shouldn't cause trust issues.

This implies the hosting service has to prevent pages from including 
download="" attributes pointing to itself, of course.


On Tue, 19 Jul 2011, Alexey Proskuryakov wrote:
>
> The fact that hosting implies a certain degree of trust is also built 
> into client software. For example, if you download an executable file on 
> Mac OS X, then the system warns you about it on first launch, and tells 
> you where it was downloaded from, not where a link to the download was.

Which URL is given there of course depends on what URL the browser decides 
to put there. It could be the page's URL.

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

From ian at hixie.ch  Fri Jul 22 00:00:33 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 07:00:33 +0000 (UTC)
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E26F413.5090302@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
Message-ID: <Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>


(These e-mails were sent after I started working on the previous one.)

On Wed, 20 Jul 2011, Chris Bentzel wrote:
>
> Who should be trusted for filename if the one specified by <a> on the 
> referring page differs from the one specified by Content-Disposition on 
> the to-be-downloaded resource?

I've specified that the header wins.


On Wed, 20 Jul 2011, Julian Reschke wrote:
> 
> That being said, if you want to go down the road, make it clear how the 
> file name actually is extracted from the header field in an 
> interoperable way.

That isn't really in scope for the HTML spec, it's something either for 
the HTTP spec or the Content-Disposition spec (if HTTP doesn't define th 
header itself) to define.

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


From ian at hixie.ch  Fri Jul 22 00:06:49 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 07:06:49 +0000 (UTC)
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
	<CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107220706160.2079@ps20323.dreamhostps.com>

On Fri, 22 Jul 2011, Hironori Bono (???? ????) wrote:
> 
> This is just out of curiosity. Would it be possible to give me the 
> encoding used for this "download" attribute? I think we have several 
> options when we use non-ASCII characters (this example uses Cyrillic 
> characters) as the value of this attribute as listed below.

It's whatever encoding is used for the page. Attributes are just Unicode, 
parsed by the same parser as the rest of the page.

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

From julian.reschke at gmx.de  Fri Jul 22 00:10:21 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 22 Jul 2011 09:10:21 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
Message-ID: <4E29225D.2020908@gmx.de>

On 2011-07-22 09:00, Ian Hickson wrote:
>
> (These e-mails were sent after I started working on the previous one.)
>
> On Wed, 20 Jul 2011, Chris Bentzel wrote:
>>
>> Who should be trusted for filename if the one specified by<a>  on the
>> referring page differs from the one specified by Content-Disposition on
>> the to-be-downloaded resource?
>
> I've specified that the header wins.
>
>
> On Wed, 20 Jul 2011, Julian Reschke wrote:
>>
>> That being said, if you want to go down the road, make it clear how the
>> file name actually is extracted from the header field in an
>> interoperable way.
>
> That isn't really in scope for the HTML spec, it's something either for
> the HTTP spec or the Content-Disposition spec (if HTTP doesn't define th
> header itself) to define.

Is there a specific reason why the new text doesn't mention 
Content-Disposition anymore?

Best regards, Julian



From julian.reschke at gmx.de  Fri Jul 22 00:22:56 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 22 Jul 2011 09:22:56 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAF4kx8fqnJXn=V0=i_J+aoVResBBh=eGXb7EbgsVeq7rbnprAg@mail.gmail.com>
	<CA+c2ei_8m3iNAR9DjHzapaKX5J0bHv-yH0OGhgbGXk2QNvP-6w@mail.gmail.com>
	<CAP0-Qpt=1c_LbCbCm22qryWSfZO5BwfUp2Kr1DUP+q6ws=vqwg@mail.gmail.com>
	<CA+c2ei_fpFLSjzDUPqgoLbwt8egXa_dC54UHF0EfgpUyf7m-XQ@mail.gmail.com>
	<CABirCh91yiSCft2gR+6eRPc85GPjDKWjALh+sMFMuxRTJQvhVQ@mail.gmail.com>
	<CAF4kx8f7psXWhHge=Hb579KLSu4BV3r2iP9ZdKiZ0XM3g47o_w@mail.gmail.com>
	<CAN3JrbbUFEyGgFoFBdbXyU+472mE=_EmsJthDWkvdSUSAzVxkA@mail.gmail.com>
Message-ID: <4E292550.4050309@gmx.de>

On 2011-07-22 05:03, Hironori Bono (?? ??) wrote:
> Greetings all,
> 
> This is just out of curiosity.
> Would it be possible to give me the encoding used for this "download"
> attribute? I think we have several options when we use non-ASCII
> characters (this example uses Cyrillic characters) as the value of
> this attribute as listed below.
> 
> 1. Use the same encoding as the one used for the HTML content.
>    <a href="..."  download="????.png">????????? ????</a>
> (If we allow using '&#x...' format of HTML, it becomes:
>    <a href="..."  download="&#x444;&#x430;&#x439;&#x43B;.png">????????? ????</a>
> 
> 2. Use the URL encoding (same as the "href" attribute).
>    <a href="..."  download="%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>
> 
> 3. Use RFC 2231 (same as the "content-disposition" header)
>    <a href="..."
> download="UTF-8''%D1%84%D0%B0%D0%B9%D0%BB.png">????????? ????</a>
> 
> Thank you for your help in advance.

It's the same as with any other HTML attribute.

The thing you mention in 3) is a special mechanism only needed in HTTP
header fields (btw updated by RFC 5987), and doesn't apply here.

Best regards, Julian


From ian at hixie.ch  Fri Jul 22 00:24:45 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 07:24:45 +0000 (UTC)
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E29225D.2020908@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
	<4E29225D.2020908@gmx.de>
Message-ID: <Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>

On Fri, 22 Jul 2011, Julian Reschke wrote:
> > 
> > That isn't really in scope for the HTML spec, it's something either 
> > for the HTTP spec or the Content-Disposition spec (if HTTP doesn't 
> > define th header itself) to define.
> 
> Is there a specific reason why the new text doesn't mention 
> Content-Disposition anymore?

Not only does the new text mention Content-Disposition, it actually refers 
to its specification multiple times. Are you looking at the right diff?

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


From simon.madine at nokia.com  Fri Jul 22 00:30:39 2011
From: simon.madine at nokia.com (simon.madine at nokia.com)
Date: Fri, 22 Jul 2011 07:30:39 +0000
Subject: [whatwg] Selectors within <style scoped>
In-Reply-To: <op.vyxp8vhute2ec8@aimac.local>
References: <BANLkTik-0n005+sb1TDLaXTbtmgbL4Xbq3o69wqatw1AuN_3uA@mail.gmail.com>
	<4DF9C8C9.3090805@lachy.id.au>
	<BANLkTi=_oPqdh33nT=qXb=xHY9PmaLnBVQ@mail.gmail.com>
	<BANLkTin4+Q8_+FtKux0g9PGCmRgwfG1EpA_UM1emt7mb9vxT0g@mail.gmail.com>
	<BANLkTikZeOxPVxDZuHz5os3wMzEUWLyYWWdsFVkRGoCMTh2WLg@mail.gmail.com>
	<op.vw8kp9oate2ec8@aimac.local>
	<CADh5Ky2i1u-yao=Mi9Tnvh-mOCEtb6hAU2r6vDg0mXPHM5Hfaw@mail.gmail.com>
	<4E24FCBC.6060402@mit.edu>
	<CACFPSpjE2N9-Cgc3o_i3heKy8JnCXerfkdh3E4=gD0v1MR5u2w@mail.gmail.com>
	<4E2504BF.70504@mit.edu> <op.vyxnfxdgte2ec8@aimac.local>
	<1311191751.577.5.camel@localhost.localdomain>,
	<op.vyxp8vhute2ec8@aimac.local>
Message-ID: <82630CFC810DB14BB43301B96536D485010F4FDF@008-AM1MPN1-004.mgdnok.nokia.com>

I've been working with a JS polyfill to enable scoped styles optionally including or excluding the direct parent element and, from a CSS writing point-of-view, it feels more natural to be able to affect the parent. The scoped block essentially has influence over the elements it can directly 'see' - parent and siblings.

Either way, there's going to be a neutral container element so it comes down to whether that would be better provided by the author of the page or the author of the included block. 

Simon



________________________________________
From: whatwg-bounces at lists.whatwg.org [whatwg-bounces at lists.whatwg.org] on behalf of ext Kornel Lesi?ski [kornel at geekhood.net]
Sent: 20 July 2011 22:37
To: ash at ashleysheridan.co.uk
Cc: whatwg
Subject: Re: [whatwg] Selectors within <style scoped>

On Wed, 20 Jul 2011 20:55:51 +0100, Ashley Sheridan
<ash at ashleysheridan.co.uk> wrote:

>> <div id=widget>
>>    <style scoped>
>>      #widget foo {}
>>    </style>
>> </div>
>
> While I agree that that might be a common pattern, I disagree that it's
> actually a good one. Consider an ad service which wraps everything in a
> custom <div> tag. If the scope allowed the immediate parent to be
> included as part of the scope, then it could allow the advert to be
> altered in a way that could negatively affect the users of the site the
> ad appeared on.

The site could wrap the ad in another div to prevent that (and this is
typical when the site wants to create fixed-size ad slot).

> The purpose of scope in the style seems to be to protect elements
> outside of the included content and to 'contain' the included content
> that has the <style scoped> element in it, presumably because it's
> coming from an external source. If you allowed the immediate parent as
> your example, then it could allow the 3rd parties who created the advert
> to take over the element beyond what the advert service would prefer to
> be allowed.

For rogue 3rd parties there's <iframe> in seamless and sandboxed flavors.

If author is allowing untrusted and misbehaving code in the DOM, then it's
already game over ? the ad can do anything, including creating <style>
without scope and modifying other stylesheets.

Even scoped style could use position:absolute or fixed to modify looks of
something outside the element.

--
regards, Kornel Lesi?ski

From julian.reschke at gmx.de  Fri Jul 22 03:37:10 2011
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 22 Jul 2011 12:37:10 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
	<4E29225D.2020908@gmx.de>
	<Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>
Message-ID: <4E2952D6.6050201@gmx.de>

On 2011-07-22 09:24, Ian Hickson wrote:
> On Fri, 22 Jul 2011, Julian Reschke wrote:
>>>
>>> That isn't really in scope for the HTML spec, it's something either
>>> for the HTTP spec or the Content-Disposition spec (if HTTP doesn't
>>> define th header itself) to define.
>>
>> Is there a specific reason why the new text doesn't mention
>> Content-Disposition anymore?
>
> Not only does the new text mention Content-Disposition, it actually refers
> to its specification multiple times. Are you looking at the right diff?

I was looking at the diff r6318. Maybe there were more changes?

Best regards, Julian



From annevk at opera.com  Fri Jul 22 03:41:55 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 22 Jul 2011 12:41:55 +0200
Subject: [whatwg] a rel=attachment
In-Reply-To: <4E2952D6.6050201@gmx.de>
References: <CAF4kx8e8-MvSQgL3TvYgtj_Jb6YUewMiXv4C00jkwB6Tvt1G0Q@mail.gmail.com>
	<CA+c2ei9qTff4Xmy2KawsJmg3VT3pEqsJaMAeCA4Gu8+ZoQBwcg@mail.gmail.com>
	<CAJE5ia8hqM2=dupMiLVsfb=k1FXq00-rP21wdcXjX3R7ku17qg@mail.gmail.com>
	<CA+c2ei917jnPuuov9wNCgqtATHjG+ZoeeEL8_-0FpFjx8J-03w@mail.gmail.com>
	<CAJE5ia_KJiu-ai6yb9oSwTqsevCG3Jwa6tYdb9nGKzK3UPsjPw@mail.gmail.com>
	<0CD98046-972E-4132-91F3-34F9DE71C97A@webkit.org>
	<CABirCh8iKBrrf+6bC21SYwizR-fgnVON4BGbz3QQK+X2=TResw@mail.gmail.com>
	<D2724AF1-54DA-4F4E-87A1-7552529D1FA6@webkit.org>
	<CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
	<4E26F413.5090302@gmx.de>
	<Pine.LNX.4.64.1107220659140.2079@ps20323.dreamhostps.com>
	<4E29225D.2020908@gmx.de>
	<Pine.LNX.4.64.1107220724120.3775@ps20323.dreamhostps.com>
	<4E2952D6.6050201@gmx.de>
Message-ID: <op.vy0nz5st64w2qv@annevk-macbookpro.local>

On Fri, 22 Jul 2011 12:37:10 +0200, Julian Reschke <julian.reschke at gmx.de>  
wrote:
> I was looking at the diff r6318. Maybe there were more changes?

Searching for content-disposition in http://html5.org/r/6318 gives plenty  
of results.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From glenn at zewt.org  Fri Jul 22 09:22:53 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 22 Jul 2011 12:22:53 -0400
Subject: [whatwg] Forcing a download
In-Reply-To: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
	<Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
Message-ID: <CABirCh9pD0ec0BzVyKjMA_O0f1L8HbBdhD5zBpx8nFmOArzgBg@mail.gmail.com>

On Fri, Jul 22, 2011 at 2:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> As Ian says above, if the user is savvy enough to
> right-click, the user is likely not going to find it difficult to give the
> file a name either.

(But again, just because I'm able to do something by hand doesn't mean that
I should be required to.)

> Is there any reason to use CORS here at all? It seems like the simpler
> solution would be the following:
>   - if the received resource has a Content-Disposition: attachment header
>     that specifies a filename, use that.
>   - otherwise, if the received resource has a Content-Disposition header
>     that specifies a filename, and the resource is same-origin, use that
>     filename.
>   - otherwise, if the received resource is same-origin and the
>     download="" attribute specifies a filename, use that.
>   - otherwise, if the received resource has a Content-Disposition:
>     attachment header and the download="" attribute specifies a filename,
>     use the filename from the attribute.
>   - otherwise, if the received resource is same-origin then derive a
>     filename from the resource.
>   - otherwise, either abort or alert the user that a file is being
>     downloaded from a different origin and prompt for a filename.

This doesn't allow cross-origin files to be linked to as both attachment and
inline resources.  Your suggested workaround for the PDF case is to have two
links, but in order to do that cross-origin you'd need to add
"Content-Disposition: attachment" on the file, so that wouldn't work: they'd
both become download links.

Similarly, sites show an image inline and have a separate link to download
it.  For that link to use @download, C-D: attachment would have to be
applied to the images, which is clearly unwanted.

This breaks every case where I've wanted this functionality in the past.  It
doesn't make sense for @download to only work on files which are already
marked as such by Content-Disposition.

If you really want cross-origin @download to be opt-in, then use a separate
header for it ("Allow-Forced-Downloads: *"); don't repurpose C-D like this.

>> So, if a hosting service doesn't want to allow executable files, it
>> won't show files as executable from their own download pages, which is
>> what should matter as far as that site's trust is concerned.  People
>> using this mechanism to serve executable files from external links may
>> be annoying, but it shouldn't cause trust issues.
>
> This implies the hosting service has to prevent pages from including
> download="" attributes pointing to itself, of course.

My point was the opposite; they don't need to do that.  They're not
providing the trojan-as-JPG from their own download pages, and if an
external site links to a file and changes the extension to .EXE, then it's
the external site that users should blame, not the download site.

(That's what I believe will happen, anyhow, since that's the site in the
address bar when the user clicks the link, which I expect is what users
examine, not eg. the small "from:" text in Firefox's save-or-open dialog.  I
think that's sensible, because I don't think it's reasonable to expect users
to make security decisions involving multiple sites; it's hard enough to get
them to look at the address bar before entering a password.)

-- 
Glenn Maynard


From ap at webkit.org  Fri Jul 22 13:27:36 2011
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 22 Jul 2011 13:27:36 -0700
Subject: [whatwg] Forcing a download
In-Reply-To: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
	<Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
Message-ID: <CDE2722E-C7DC-4A7F-8BC5-251BFA27F68A@webkit.org>

> On Tue, 19 Jul 2011, Alexey Proskuryakov wrote:
>> 
>> What meaning will this attribute have on a platform that simply doesn't 
>> expose the notion of a file?
> 
> None, presumably the same as "Content-Disposition: attachment" in the same 
> case.
> 
> 
>> I think that this attribute could be quite confusing, and it will likely 
>> become more confusing with time, as more platforms arise that have 
>> creative ways of presenting data to users.
> 
> Could you elaborate on what confusion you are expecting here?

Having rel=attachment and download be named so differently implies that the functionality is different. For example, I'm sure that many people will waste time trying to see what they can do with @download on an iPhone that they couldn't do before with Content-Disposition.

> On Tue, 19 Jul 2011, Alexey Proskuryakov wrote:
>> 
>> The fact that hosting implies a certain degree of trust is also built 
>> into client software. For example, if you download an executable file on 
>> Mac OS X, then the system warns you about it on first launch, and tells 
>> you where it was downloaded from, not where a link to the download was.
> 
> Which URL is given there of course depends on what URL the browser decides 
> to put there. It could be the page's URL.


For reference, this is how the warning looks: <http://nypop.com/~ap/webkit/quarantine.png>.

A browser can certainly find a way to put an arbitrary original URL here, but the behavior is not limited to browsers. Any application can use the download API, and non-browser applications will not necessarily have the notion of referencing page. Having different data depending on whether you download directly from a browser or using a download manager is of course no good.

That said, as long as we don't need to honor a file extension provided in @download when it doesn't match Content-Type, it may not matter very much if a page gets the chance to modify the base part of the name.

- WBR, Alexey Proskuryakov



From jonas at sicking.cc  Fri Jul 22 14:03:12 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 22 Jul 2011 14:03:12 -0700
Subject: [whatwg] Forcing a download
In-Reply-To: <Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
References: <CAP0-Qpu2uBp6k4=8ft8k7x0BL65QyNOuDmv0bhvOc3EZ3rQ6OA@mail.gmail.com>
	<Pine.LNX.4.64.1107200515330.3775@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei9Q9zWpc1eqx5UMV+W6Qji9-1mFWCjJRB19uvpL18XTdA@mail.gmail.com>

On Thu, Jul 21, 2011 at 11:58 PM, Ian Hickson <ian at hixie.ch> wrote:
> Is there any reason to use CORS here at all? It seems like the simpler
> solution would be the following:
>
> ?- If download="" is set, then by default trigger a download rather than a
> ? navigation action. (User can override via context menu.)
> ?- Pick a filename for the download as follows:
> ? - if the received resource has a Content-Disposition: attachment header
> ? ? that specifies a filename, use that.
> ? - otherwise, if the received resource has a Content-Disposition header
> ? ? that specifies a filename, and the resource is same-origin, use that
> ? ? filename.
> ? - otherwise, if the received resource is same-origin and the
> ? ? download="" attribute specifies a filename, use that.
> ? - otherwise, if the received resource has a Content-Disposition:
> ? ? attachment header and the download="" attribute specifies a filename,
> ? ? use the filename from the attribute.
> ? - otherwise, if the received resource is same-origin then derive a
> ? ? filename from the resource.
> ? - otherwise, either abort or alert the user that a file is being
> ? ? downloaded from a different origin and prompt for a filename.
> ?- If a mapping from the MIME type to an extension is known, but the
> ? filename doesn't have that extension, add it.
>
> This is what I've used for now (modulo some allowances for user
> interfaces), but I welcome suggests for changing this.

The "otherwise, either abort or alert the user that a file is being
downloaded from a different origin and prompt for a filename" step
seems to allow to *very* different browser behaviors, resulting in a
site working in one browser, but not in another.

I'm still trying to find a date when we can do a security review about
this in mozilla though. It still does seem very strange to me that a
bank site which sends "cache-control: no-store" for a resource in
order to prevent it from being temporarily stored on the users hard
drive, can still end up being *permanently* stored on a users hard
drive. All that's needed is for the user to click a 'yes' button on a
download dialog while watching a seemingly harmless site.

/ Jonas


From ian at hixie.ch  Fri Jul 22 15:33:15 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jul 2011 22:33:15 +0000 (UTC)
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>

On Thu, 21 Apr 2011, James Kozianski wrote:
> 
> I'd like to propose the following changes to the registerProtocolHandler 
> spec. [...]

Before I study the proposals in detail, is there a description of the 
kind of experience we're trying to enable here?

What are the UIs we expect to see page use wih registerProtocolHandler()?

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


From kornel at geekhood.net  Fri Jul 22 16:09:54 2011
From: kornel at geekhood.net (=?utf-8?B?S29ybmVsIExlc2nFhHNraQ==?=)
Date: Sat, 23 Jul 2011 00:09:54 +0100
Subject: [whatwg] Page displayed during/after download (<meta refresh>
	downloads)
Message-ID: <op.vy1mmspjte2ec8@aimac.local>


There is a design (anti)pattern related to file downloads: instead of  
linking to a file directly, websites use "Download" links pointing to a  
page with <meta refresh="5; url=actual URL to download"> (or equivalent  
javascript) and "Thank you!" text or further instructions how to use  
downloaded file (e.g. install an application).

Examples:

http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_10.3_for_Mac_OS_X_10.4_-_10.6_(Intel)
http://sourceforge.net/projects/vlc/files/1.1.11/macosx/vlc-1.1.11.dmg/download
http://www.opera.com/download/get.pl?id=33846&thanks=true&sub=true
http://www.google.com/chrome/thankyou.html?hl=en-GB&platform=mac

This is problematic, because:

* it's hard or impossible to see or copy URL of the file (to download with  
another application, share URL, check if file type is correct by looking  
at the filename)

* Right-click and "Save As" on "Download now" links is unreliable and  
sometimes results in HTML downloaded

* "Thank you!" pages saved in browsing sessions cause files to be  
re-downloaded every time browser is restarted

* Extra pages and <meta refresh> cause unnecessary delays. "Your download  
will start in 5 seconds" is very annoying when download itself takes  
couple of seconds.


I wish this could be replaced with something that doesn't break download  
links.


I think in terms of use-cases it can be expressed as:

1. Show users immediate and very clear feedback that the download is  
starting, even if browser's standard download UI is very subtle or appears  
only after the download server responds.

2. Allow website to show additional information about the download, while  
the download is taking place.

e.g. Instructions what to do with the file after it is downloaded. List of  
mirrors to use in case download is slow or fails. List of related products  
to upsell.

<a download> and UI improvements in browsers might partially cover use  
case #1, but I don't see an easy solution to #2, and partial improvement  
might not be enough to replace <meta refresh> download pages.

And I'm afraid that <meta refresh> also fulfils another case:

3. Make it harder for others to link directly to the file, force them to  
link to a branded landing page.


I think cases #1 and #2 could be satisfied with something like:

<a post-download-href="url of page to navigate to when download starts">

And to satisfy all three cases (without breaking links), it needs to be  
done at HTTP level, by adding HTTP header (or multipart response? or  
attribute to Content-Disposition?) that causes both file download to start  
and a page to be displayed at the same time.

-- 
regards, Kornel Lesi?ski


From svartman95 at gmail.com  Sun Jul 24 20:30:02 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 25 Jul 2011 03:30:02 +0000
Subject: [whatwg] window.status and window.defaultStatus
Message-ID: <4E2CE33A.6010402@gmail.com>

Are JavaScript implementors willing to reimplement window.status? There 
are obvious security problems with drawing an author-provided string 
where a certain URI is expected, but could window.defaultStatus not set 
the name (_NET_WM_NAME or equivalent) of the script's window and 
window.status either override window.defaultStatus temporarily, or sent 
to the user, e.g. through Growl or as a Windows toast.
The window name is already accessible to scripts (by modifying the text 
child of <title> through the DOM) so no new security concerns are 
introduced. The Growl binding might well be better by a new function, 
though.


From jgraham at opera.com  Mon Jul 25 01:48:25 2011
From: jgraham at opera.com (James Graham)
Date: Mon, 25 Jul 2011 10:48:25 +0200
Subject: [whatwg] window.status and window.defaultStatus
In-Reply-To: <4E2CE33A.6010402@gmail.com>
References: <4E2CE33A.6010402@gmail.com>
Message-ID: <4E2D2DD9.3090104@opera.com>

On 07/25/2011 05:30 AM, Bjartur Thorlacius wrote:
> Are JavaScript implementors willing to reimplement window.status? There
> are obvious security problems with drawing an author-provided string
> where a certain URI is expected, but could window.defaultStatus not set
> the name (_NET_WM_NAME or equivalent) of the script's window and
> window.status either override window.defaultStatus temporarily, or sent
> to the user, e.g. through Growl or as a Windows toast.
> The window name is already accessible to scripts (by modifying the text
> child of <title> through the DOM) so no new security concerns are
> introduced. The Growl binding might well be better by a new function,
> though.

If you want OS-level notifications you might be interested in [1]

[1] http://dev.w3.org/2006/webapi/WebNotifications/


From ian at hixie.ch  Mon Jul 25 12:02:15 2011
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Jul 2011 19:02:15 +0000 (UTC)
Subject: [whatwg] Physical quantities: <var> or <i>?
In-Reply-To: <172D93ED6EC74255ADA2D5262080E98A@JukanPC>
References: <1DDAC71F28644CD99F84542A4EFAFBEB@JukanPC>
	<BANLkTimQLe75LnjQC2HgyaKrRKu=7fFD=w@mail.gmail.com>
	<172D93ED6EC74255ADA2D5262080E98A@JukanPC>
Message-ID: <Pine.LNX.4.64.1107222252350.2079@ps20323.dreamhostps.com>

On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
>
> Looking at the nice summary (with examples) of text-level markup at 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#usage-summary 
> I started wondering why there is no example of markup for symbols of 
> physical quantities. The descriptions of individual elements or their 
> examples don't seem to say anything about this either.

The main reason is that most of these symbols have Unicode characters and 
don't need special markup.


> So what markup should we use for E = mc?, given that by the applicable
> standards, E, M, and c should appear in italics and the other characters as
> normal (upright)?

It sounds like you want to use these characters:

   U+1D438 MATHEMATICAL ITALIC CAPITAL E
   U+1D45A MATHEMATICAL ITALIC SMALL M
   U+1D450 MATHEMATICAL ITALIC SMALL C

Alternatively, you can use MathML to mark up the equation.


> Physical quantities surely satisfy the requirement that "typical 
> typographic presentation is italicized" in the following, and they are 
> to be offset from the normal prose, but why aren't they mentioned in the 
> fairly long list of examples then:
> 
> "The i element represents a span of text in an alternate voice or mood, 
> or otherwise offset from the normal prose, such as a taxonomic 
> designation, a technical term, an idiomatic phrase from another 
> language, a thought, a ship name in Western texts, or some other prose 
> whose typical typographic presentation is italicized." 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element
> 
> (As an aside, the wording "a taxonomic designation" is too broad, as by 
> biological nomenclature rules, genus and species names are to be 
> italiced but higher taxons, e.g. family names, like Canidae, must not. 
> Besides, e.g. an English name of a species is taxonomic too... So 
> "scientific names of organisms" would be a better formulation.)

Whether you want something in italics or not is more a matter for CSS than 
a matter for HTML.


> Should we consider the var element as covering physical quantities too? 
> After all, they can be regarded as variables in a broad sense, as 
> symbols that denote different values in different situations. However, 
> <var>c</var> would be odd, wouldn't it, since the symbol denotes a 
> universal constant of nature.

You can look at it as being a variable whose value is a constant of 
nature. I've clarified the spec to indicate that this is fine.


On Thu, 14 Apr 2011, Bjartur Thorlacius wrote:
>
> Well, a constant isn't really variable any more, is it? I thought <var> 
> was meant to mark up text that couldn't simply be 'copypasted' without 
> filling in the unknowns (free variables). Defined variables (whether in 
> source code or formulae) do not conform to that definition.
> 
> So, <code>rm -r <var>$path</var></code> would conform (as a reply to the 
> question "how does one remove a (potentially non-empty) directory on 
> *nix?") as $path is undefined, but <code><var>i</var>++</code> would 
> not, as i isn't ment to be substituted.

What do you base this interpretation on?


On Sat, 16 Apr 2011, Jukka K. Korpela wrote:
> 
> Besides, there is no implied uniform rendering for variables in the 
> current broad meaning for <var>. In mathematics, variables are 
> conventionally written in italics. But the HTML(5) notion of variable is 
> wider: "The var element represents a variable. This could be an actual 
> variable in a mathematical expression or programming context, or it 
> could just be a term used as a placeholder in prose." A programming 
> language variable is something that is _not_ conventionally rendered in 
> italics. Rather, they are usually (though for no really good reason) 
> rendered in a monospace font, like any other expressions in computer 
> languages.

Indeed. And vectors are usually bold. This is the kind of thing I would 
expect to see handled using classes, e.g.:

   <var class=vector>a</var> &#x2A2F; <var class=vector>b</var> =
   <var>a</var> <var>b</var> sin <var>&theta;</var> <var class=vector>n</var>


> Too bad there's no example of <var> used in programming context. The 
> current wording suggests that it would be normal, when discussing 
> programming, to write, say, "Then we define the variable 
> <var>myFoo</var> of type <code>fooType</code> with initial value 
> <code>"Foo"</code> - -", which really makes no sense, even if we use 
> both <var> and <code> for myFoo.

Why does it make no sense?

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

From svartman95 at gmail.com  Mon Jul 25 15:45:15 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 25 Jul 2011 22:45:15 +0000
Subject: [whatwg] Page displayed during/after download (<meta refresh>
 downloads)
In-Reply-To: <op.vy1mmspjte2ec8@aimac.local>
References: <op.vy1mmspjte2ec8@aimac.local>
Message-ID: <4E2DF1FB.4090006@gmail.com>

?ann f?s 22.j?l 2011 23:09, skrifa?i Kornel Lesi?ski:
> 2. Allow website to show additional information about the download,
> while the download is taking place.
>
> And to satisfy all three cases (without breaking links), it needs to be
> done at HTTP level, by adding HTTP header (or multipart response? or
> attribute to Content-Disposition?) that causes both file download to
> start and a page to be displayed at the same time.
>
Sending multiple responses in reply to a single request is generally 
useful, but seems hard to implement in a fashion compatible with HTTP 
pipelining clients.
How about a JavaScript opening a new browsing context and navigating it 
to the additional metainformation when the user follows the link?


From shawn at mozilla.com  Mon Jul 25 16:00:12 2011
From: shawn at mozilla.com (Shawn Gong)
Date: Mon, 25 Jul 2011 16:00:12 -0700 (PDT)
Subject: [whatwg] When initializing a JS URL object,
 do we handle the case of 0 argument?
In-Reply-To: <1224548462.638617.1311633980644.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <1911155557.638885.1311634812090.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

(Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en)

The incoming arguments plainURL and baseURL are optional. The question is, when there is no argument provided, do we return an error or treat it normally, then assign the URL later? If so, which interface do we use to assign the URL? href?

Thanks!
Shawn Gong


From w3c at adambarth.com  Mon Jul 25 16:23:53 2011
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 25 Jul 2011 16:23:53 -0700
Subject: [whatwg] When initializing a JS URL object,
 do we handle the case of 0 argument?
In-Reply-To: <1911155557.638885.1311634812090.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
References: <1224548462.638617.1311633980644.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<1911155557.638885.1311634812090.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <CAJE5ia9ShOSJer-jKoEtBq_3hgbH8nZyGzJHYUQEV9UymjnmOQ@mail.gmail.com>

I've made the first URL non-optional.

Thanks,
Adam


On Mon, Jul 25, 2011 at 4:00 PM, Shawn Gong <shawn at mozilla.com> wrote:
> (Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en)
>
> The incoming arguments plainURL and baseURL are optional. The question is, when there is no argument provided, do we return an error or treat it normally, then assign the URL later? If so, which interface do we use to assign the URL? href?
>
> Thanks!
> Shawn Gong
>


From koz at chromium.org  Mon Jul 25 20:31:28 2011
From: koz at chromium.org (James Kozianski)
Date: Tue, 26 Jul 2011 13:31:28 +1000
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>
Message-ID: <CALmvxBf3+3g5eH1CG3yFEeF8sfOjJM05hp+X184iFaq5zyOT=A@mail.gmail.com>

Hi Ian,

Here are the use cases I had in mind:

1. Allow sites to conditionally show UI to promote the advantages of
registering the site as a handler.
   (requires isRegistered)

2. Allow sites to provide settings screens which allow users to register
/ deregister handlers from within the site.
   (requires isRegistered, and deregisterProtocolHandler)

The presence of an ignored list - sites who don't have permission to use
registerProtocolHandler - necessitates Michael Davidson's suggestion that
isRegistered() should return a tri-state value (REGISTERED, DECLINED,
NOTASKED). Otherwise sites that have been 'ignored' by a user won't be able
to tell if they should show their promotional UI or not.

Cheers,
James


On Sat, Jul 23, 2011 at 8:33 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 21 Apr 2011, James Kozianski wrote:
> >
> > I'd like to propose the following changes to the registerProtocolHandler
> > spec. [...]
>
> Before I study the proposals in detail, is there a description of the
> kind of experience we're trying to enable here?
>
> What are the UIs we expect to see page use wih registerProtocolHandler()?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>


From ian at hixie.ch  Mon Jul 25 22:30:37 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Jul 2011 05:30:37 +0000 (UTC)
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
References: <4E242D26.3030401@alvestrand.no>
	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
	<CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>

On Thu, 14 Jul 2011, Shwetank Dixit wrote:
> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
> > > 
> > > Another question is flash. As far as I have seen, there seems to be 
> > > no option to specify whether the camera needs to use flash or not. 
> > > Is this decision left up to the device? (If someone is making an app 
> > > which is just clicking a picture of the person, then it would be 
> > > nice to have the camera use flash in low light conditions).
> >
> > getUserMedia() returns a video stream, so it wouldn't use a flash.
> 
> Wouldn't it make sense to have a provision for flash separately then? I 
> think a lot of apps would like just a picture instead of video, and in 
> those cases, flash would be required. Maybe a seperate provision in the 
> spec which defines whether to use flash, and if so, for how many 
> miliseconds. Is that doable?

In response to getUserMedia()? I don't really understand how that would 
work. Could you elaborate? How do you envisage the API working? Maybe a 
concrete example would help.

I'm particularly concerned about two things: preventing hostile sites from 
abusing a flash feature to troll the user, and preventing well-meaning but 
poorly designed sites from using the flash when the user doesn't want it 
to (e.g. when taking a photograph in an area where a flash isn't desired).


On Thu, 14 Jul 2011, timeless wrote:
>
> I'd expect a web app to have no idea about device camera specifications 
> and thus to not be able to properly specify a flash duration. I don't 
> see how such a thing is valuable.
> 
> If a user is in a movie theater, or a museum, it's quite likely they 
> won't notice a web app is forcing a flash. Let the user control flash 
> through a useragent only or host application only mode. I believe the 
> hazards of exposing flash duration outweigh any benefits. The only 
> application class I know of built using control of camera flash is 
> "flash-light", and that's both a hack and not guaranteed to be workable 
> for all possible flash technologies.

Right.


On Fri, 15 Jul 2011, Shwetank Dixit wrote:
> 
> Just like, just allowing the web app to use the camera as it is will not 
> make sense, and presumably, user agents will implement a authorization 
> by the user before the app gains access to the camera (something like 
> 'This application requests access to the camera. Allow for now/Always 
> Allow/Never Allow/Close' just like you do in geolocation right now) ... 
> just like that, you could do it for flash, where the app only gains 
> access to it if the user allows it. If that is the implementation, i do 
> not think there would be much hazards in allowing flash access.

This is quickly going to get frustrating to the user. In general, we'd 
rather not have any such prompts. For example, for video, well-designed 
browsers are likely not going to have a "yes/no" prompt, instead they'll 
just have a prompt that asks the user what camera they want to use. This 
is far less frustrating to the user.


> Apart from helping capture images/video in low light conditions, there 
> are a few other use cases for flash such as the flash light thing you 
> mentioned, as well as a possible S.O.S type app.
>
> I'm fine if the consensus is that the device/user agent will handle the 
> issue of flash by showing some sort of control where the user can click 
> between 'flash on/off/auto'. That will cover *most* of the use cases, 
> which is recording images/video in low light conditions. If so, then it 
> might be good to specify that somewhere in the spec just to make things 
> a bit clearer?

Ok, done.


On Tue, 19 Jul 2011, Per-Erik Brodin wrote:
> 
> Perhaps now that there is no longer any relation to tracks on the media 
> elements we could also change Track to something else, maybe Component. 
> I have had people complaining to me that Track is not really a good name 
> here.

I'm happy to change the name if there's a better one. I'm not sure 
Component is any better than Track though.


> Good. Could we still keep audio and video in separate lists though? It 
> makes it easier to check the number of audio or video components and you 
> can avoid loops that have to check the kind for each iteration if you 
> only want to operate on one media type.

Well in most (almost all?) cases, there'll be at most one audio track and 
at most one video track, which is why I didn't put them in separate lists. 
What use cases did you have in mind where there would be enough tracks 
that it would be better for them to be separate lists?


> I also think that it would be easier to construct new MediaStream 
> objects from individual components rather than temporarily disabling the 
> ones you do not want to copy to the new MediaStream object and then 
> re-enabling them again afterwards.

Re-enabling them afterwards would re-include them in the copies, too.

The main use case here is temporarily disabling a video or audio track in 
a video conference. I don't understand how your proposal would work for 
that. Can you elaborate?


> It is also unclear to me what happens to a LocalMediaStream object that 
> is currently being consumed in that case.

Not sure what you mean. Can you elaborate?


> Why should the label the same as the parent on the newly constructed
> MediaStream object?

The label identifies the source of the media. It's the same source, so, 
same label.


> If you send two MediaStream objects constructed from the same 
> LocalMediaStream over a PeerConnection there needs to be a way to 
> separate them on the receiving side.

What's the use case for sending the same feed twice?


> I also think it is a bit unfortunate that we now have a 'label' property 
> on the track objects that means something else than the 'label' property 
> on MediaStream, perhaps 'description' would be a more suitable name for 
> the former.

In what sense do they mean different things? I don't understand the 
problem here. Can you elaborate?


> > > We prefer having a StreamRecorder that you have to stop in order get 
> > > the recorded data (like the previous one, but with asynchronous Blob 
> > > retrieval) and we do not understand the use cases for the current 
> > > proposal where recording continues until the recorder is garbage 
> > > collected (or the Stream ends) and you always get the data from the 
> > > beginning of the recording. This also has to be tied to application 
> > > quota in some way.
> > 
> > The current design is just the result of needing to define what 
> > happens when you call getRecordedData() twice in a row. Could you 
> > elaborate on what API you think we should have?
> 
> What I am thinking of is something similar to what was proposed in 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030921.html 

That doesn't answer the question of what happens if you call stop() twice.

(Also, having to call a method and hook an event so that you can read an 
attribute seems like a rather round-about way of getting data. Is calling 
a method with a callback not simpler?)


> Preferably quota should be expressed in media time and that is heavily 
> dependent on the format being used and, regardless of any codecs

Quota doesn't seem particularly important here. It's not like you can 
really do lasting damage. It would just be a DOS attack, like creating a 
Web page with an infinite number of 10000x10000 canvases. We can just let 
the "hardware limitation" clause handle it.


> I still think that the format has to be specified somehow.

I continue to agree and continue to intend to wait for implementation 
experience before specifying this. I can't write the spec for this until I 
know what makes sense to spec.


> Perhaps it would be best to push recording to v2 since this does not 
> seem to be the primary use case for people currently showing the most 
> interest in this part of the spec.

Just because you talk more doesn't mean your use cases are more important. :-)


> > > Instead of blob: we would like to use stream: for the Stream URLs so 
> > > that we very early on in the media engine selection can use the 
> > > protocol scheme to determine how the URL will be handled. Blobs are 
> > > typically handled in the same way as other media playback. The 
> > > definition of stream: could be the same as for blob:.
> > 
> > Why can't the UA know which blob: URLs point to streams and which 
> > point to blobs?
> 
> I was not saying that it would not be possible to keep track of which 
> blob: URLs that point to blobs and which point to streams just that we 
> want to avoid doing that in the early stage of the media engine 
> selection. In my opinion a stream is quite the opposite of a blob 
> (unknown, perhaps infinite length vs. fixed length) so when printing the 
> URLs for debugging purposes it would also be much nicer to have two 
> different protocol schemes. If I remember correctly the discussions 
> leading up to the renaming of createBlobURL to createObjectURL assumed 
> that there would be stream: URLs.

You wouldn't be able to remove that logic, since http: URLs would still 
have the same needs. You can have finite and infinite http: resources, 
just like you can have finite and infinite blob: resources. I don't really 
see the problem here. Indeed, with blob:, it's trivial to find out if the 
resource is finite or not; with http: you might not know until the whole 
finite resource is downloaded.

If there is something I'm missing here please do let me know.


> > Actually, the spec doesn't currently say anything happens when a 
> > stream that is being transmitted just ends, either. I guess I should 
> > spec that...
> > 
> > ...ok, now the spec is clear that an ended stream transmits blackness 
> > and silence. Same with if some tracks are disabled. (Blackness only if 
> > there's a video track; silence only if there's an audio track.)
> 
> OK, I guess that could work. In that case you have to manually remove 
> the stream from being sent over a PeerConnection if it unexpectedly 
> ends.

Right. This is desireable; scripts that have not been written to deal with 
unexpected conditions should fail safely, not suddenly find variables are 
changing values in ways that the authors didn't consider.


> Should playing back an ended stream locally in a video element also 
> produce silence and blackness then?

As currently specified, yes.


> We have been assuming network error which has the nice consequence that 
> you can discard ended streams that are only reachable by their stream: 
> URLs even if the URLs are not revoked since trying to play back such a 
> stream: URL is indistinguishable from trying to play back an invalid 
> stream: URL, in that case.

Well by the point a stream: URL can only provide silence and blackness 
there's really not much to keep around, so it's not like it costs much. 
But having them give a network error would be quite tidy, true.

I could go either way on this. On the one hand, it seems good for the 
behaviour to be consistent on both sides of the PeerConnection. On the 
other hand, there's a conceptual neatness to having ended streams act as a 
network error.

Anyone else have a preference?


> > > PeerConnection is an EventTarget but it still uses a callback for 
> > > the signaling messages and this mixture of events and callbacks is a 
> > > bit awkward in my opinion. If you would like to change the function 
> > > that handles signaling messages after calling the constructor you 
> > > would have to wrap a function call inside the callback to the actual 
> > > signal handling function, instead of just (re-)setting an onsignal 
> > > (or whatever) attribute listener (the event could reuse the 
> > > MessageEvent interface).
> > 
> > When would you change the callback?
> 
> If you would like to send the signaling messages peer-to-peer over the 
> data channel, once it is established.

That seems like a disaster waiting to happen. The UDP data channel is 
unreliable, the signaling channel has to be reliable. Worse, the UDP data 
channel might go down at any second, and then the user agent would try to 
re-establish it using the signaling channel.


> > My concern with making the callback an event handler is that it leads to a
> > set of poor failure modes and complications in the API:
> > 
> >   - It's easy to not register a callback, which makes no sense. There's
> >     literally never a use for create a PeerConnection without a signaling
> >     channel, as far as I can tell, so making it easier to create one
> >     without a callback than with seems like a bad design.
> 
> I think this is the case for many APIs.

Just because we made bad APIs before doesn't mean we should do it again!


> For example, creating an EventSource without registering any listener 
> for incoming events equally does not make sense.

Actually, it does. One operation mode for EventSource is to have events 
with different names, each triggering a different event listener.


> >   - It's easy to register multiple callbacks. This equally makes no sense,
> >     and would likely only ever be the source of bugs.
> 
> Yes it would be possible but I am not sure that it would be any easier 
> to make such a mistake than to make any other mistake that would cause 
> the application to malfunction.

We're not comparing how easy it is to make this mistake compared to other 
mistakes, we're comparing how easy it is to make this mistake compared to 
not being _able_ to make this mistake.

The net number of mistakes will be some fraction of the net number of 
possible mistakes. Reduce the second number and you reduce the first.


> >   - It makes getting the data more complicated. Instead of passing the
> >     callback the string to send, we end up passing an object which has on
> >     it one attribute that contains the string.
> 
> Yeah, if getting 'event.data' is more complicated than just getting 
> 'data'.

It's not like the difference between a "Hello World" document and a video 
conferencing app, but it's still more, needless, complexity.


> To get the incoming stream from a StreamEvent (should probably be 
> renamed to MediaStreamEvent for consistency) the author would have to 
> know how to do this anyway.

I'm not saying authors won't have to figure out how to use events; events 
are all over the platform. I'm just saying that if we can make things 
simpler without breaking use cases, as here, we should.

(I fixed the event interface name.)


> > > There is a potential problem in the exchange of SDPs in that glare 
> > > conditions can occur if both peers add streams simultaneously, in 
> > > which case there will be two different outstanding offers that none 
> > > of the peers are allowed to respond to according to the SDP 
> > > offer-answer model. Instead of using one SDP session for all media 
> > > as the specification suggests, we are handling the offer-answer for 
> > > each stream separately to avoid such conditions.
> > 
> > Why isn't this handled by the ICE role conflict processing rules? It 
> > seems like simultaneous ICE restarts would be trivially resolvable by 
> > just following the rules in the ICE spec. Am I missing something?
> 
> This problem is not related to ICE but rather to the SDP offer-answer 
> model which is separate from the ICE processing. The problem is that SDP 
> offer-answer does not allow you to respond to an offer when you have an 
> outstanding offer for the same set of streams.

As far as I can tell, your interpretation is incorrect. This is entirely 
related to ICE, and ICE, as far as I can tell, defines this exact case in 
its role conflict resolution.

The only time this can happen is if you have both ends do an ICE restart 
at exactly the same time. The offer from each ICE agent will be received 
by the other as if it was the response, and thus there will be a role 
conflict and the ICE role conflict resolution process will kick in. No?


> The way we are avoiding this is by sending SDP fragments (only the SDP 
> lines related to the affected stream) rather than the full SDP each 
> time.

That seems completely incompatible with ICE requirements.


On Wed, 20 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> On Mon, Jul 18, 2011 at 20:38, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 18 Jul 2011, Tommy Widenflycht (??~[~O??~Z????~[~X??~[~X??~Z??) wrote:
> > >
> > > I am very confused regarding the below paragraph from the latest 
> > > spec:
> > >
> > > When a track in a MediaStream parent is disabled, any 
> > > MediaStreamTrack objects corresponding to the tracks in any 
> > > MediaStream objects that were created from parent are disassociated 
> > > from any track, and must not be reused for tracks again. If a 
> > > disabled track in a MediaStream parent is re-enabled, from the 
> > > perspective of any MediaStream objects that were created from parent 
> > > it is a new track and thus new MediaStreamTrack objects must be 
> > > created for the tracks that correspond to the re-enabled track.
> > >
> > > After cloning a LocalMediaStream it looks like this:
> > >
> > > LocalMediaStream -> MediaStream1
> > > Track1(E)           Track1(E)
> > > Track2(E)           Track2(E)
> > > Track3(E)           Track3(E)
> > >
> > > and as I interpret the spec it looks like this if Track1 in the 
> > > LocalMediaStream is disabled:
> > >
> > > LocalMediaStream -> MediaStream1
> > > Track1(D)           Track2(E)
> > > Track2(E)           Track3(E)
> > > Track3(E)
> >
> > Correct so far (though I'd avoid the term "cloning" since it's not 
> > quite what's going on here -- the spec uses "forking", which may be 
> > closer though is still not ideal).
> >
> > > So Track1 disappears from the MediaStream1 object and doesn't come 
> > > back even if Track1 in the LMS object is enabled:
> > >
> > > LocalMediaStream -> MediaStream1
> > > Track1(E)           Track2(E)
> > > Track2(E)           Track3(E)
> > > Track3(E)
> >
> > No, it'll create a new track object:
> >
> >  LocalMediaStream -> MediaStream1
> >  Track1(E)           Track4(E)
> >  Track2(E)           Track2(E)
> >  Track3(E)           Track3(E)
> >
> > This is specified in the sentence that starts "If a disabled track in 
> > a MediaStream parent is re-enabled...".
>
> Thanks for the explanation. To me this sounds overly complicated, why 
> not just make it so that an disable of a track will override the track 
> settings for forked MediaStreams?

I don't understand what you mean. How would that be different?


> This will definitely simplify implementation, and confuse web developers 
> less imho. MSTracks coming and going doesn't feel right. Especially 
> since there are no callbacks/events that a MS changes.

You don't need a callback, since only the author can do this in the firstp 
place.


> Also some follow-up questions regarding the new TrackLists:
> 
> What should happen when a track fails? Should the entire stream fail, 
> the MSTrack silently be removed or the MSTrack disassociated with the 
> track (and thus becoming a do-nothing object)?

What do you mean by "fails"?


> What should happen when a stream with two or more video tracks is 
> associated to a <video> tag? Just render the first enabled one?

Same as if you had a regular video file with multiple tracks.

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

From callow_mark at hicorp.co.jp  Mon Jul 25 23:22:17 2011
From: callow_mark at hicorp.co.jp (Mark Callow)
Date: Tue, 26 Jul 2011 15:22:17 +0900
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
 and other feedback
In-Reply-To: <Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
References: <4E242D26.3030401@alvestrand.no>	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>	<CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
	<Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
Message-ID: <4E2E5D19.9040704@hicorp.co.jp>

There is a lot more that could be done than simply triggering the flash.
See /The Frankencamera: An Experimental Platform for Computational
Photography/ <http://graphics.stanford.edu/papers/fcam/> and The FCAM
API <http://fcam.garage.maemo.org/>.

Regards

    -Mark

On 26/07/2011 14:30, Ian Hickson wrote:
> On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson <ian at hixie.ch> wrote:
>>> > > > 
>>> > > > Another question is flash. As far as I have seen, there seems to be 
>>> > > > no option to specify whether the camera needs to use flash or not. 
>>> > > > Is this decision left up to the device? (If someone is making an app 
>>> > > > which is just clicking a picture of the person, then it would be 
>>> > > > nice to have the camera use flash in low light conditions).
>> > >
>> > > getUserMedia() returns a video stream, so it wouldn't use a flash.
> > 
> > Wouldn't it make sense to have a provision for flash separately then? I 
> > think a lot of apps would like just a picture instead of video, and in 
> > those cases, flash would be required. Maybe a seperate provision in the 
> > spec which defines whether to use flash, and if so, for how many 
> > miliseconds. Is that doable?


From jkorpela at cs.tut.fi  Mon Jul 25 23:22:17 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Tue, 26 Jul 2011 09:22:17 +0300
Subject: [whatwg] Physical quantities: <var> or <i>?
In-Reply-To: <Pine.LNX.4.64.1107222252350.2079@ps20323.dreamhostps.com>
References: <1DDAC71F28644CD99F84542A4EFAFBEB@JukanPC>
	<BANLkTimQLe75LnjQC2HgyaKrRKu=7fFD=w@mail.gmail.com>
	<172D93ED6EC74255ADA2D5262080E98A@JukanPC>
	<Pine.LNX.4.64.1107222252350.2079@ps20323.dreamhostps.com>
Message-ID: <4E2E5D19.3040701@cs.tut.fi>

25.07.2011 22:02, Ian Hickson wrote:

>> So what markup should we use for E = mc?, given that by the applicable
>> standards, E, M, and c should appear in italics and the other characters as
>> normal (upright)?
>
> It sounds like you want to use these characters:
>
>     U+1D438 MATHEMATICAL ITALIC CAPITAL E
>     U+1D45A MATHEMATICAL ITALIC SMALL M
>     U+1D450 MATHEMATICAL ITALIC SMALL C

No, I don?t want to use them, since only about one person in a million 
would see the expression. There are several reasons to that, including 
the absence of those characters in fonts?the only commonly available 
font that contained a reasonable collection of Plane 1 characters was 
code2001, and it does not seem to be distributed by its author any more.

Characters not supported by any of the fonts installed in the user?s 
system don?t degrade well. The user sees a small box or the ??? 
character (which may appear due to other problems, too).

Comparing this with how well <i>E</i> = <i>m</i><i>c</i>? works, I don?t 
think anyone who understands the implications will give a second though 
to using such Plane 1 characters in HTML documents.

> Alternatively, you can use MathML to mark up the equation.

Or I could use LaTeX and get a presentation of acceptable quality. Or an 
image, as people still widely use. The question was about markup of 
physical quantities in HTML. Using other tools just to present a casual 
equation in running text would be disproportionate.

> Whether you want something in italics or not is more a matter for CSS than
> a matter for HTML.

In many contexts, by long traditions and conventions, the use of italics 
is a matter of content, not casual presentation. When people know they 
cannot use italics, they are forced to simulating it (e.g., writing /a/ 
to denote italic ?a?) or to avoiding the issue with clumsy methods like 
long prose explanations. Wouldn?t it be odd to pretend that in HTML, you 
are forced to something like that? After all, <i> has been with us since 
the dawn of HTML, and all browsers support it when they can use italics 
at all (and may use some special representation when not).

>> Should we consider the var element as covering physical quantities too?
>> After all, they can be regarded as variables in a broad sense, as
>> symbols that denote different values in different situations. However,
>> <var>c</var>  would be odd, wouldn't it, since the symbol denotes a
>> universal constant of nature.
>
> You can look at it as being a variable whose value is a constant of
> nature. I've clarified the spec to indicate that this is fine.

I don?t think you have clarified whether <var> is suitable for physical 
quantities, but I guess you meant to imply it?even though there is not a 
single example about markup for physical quantities.

On the other hand, it seems that it doesn?t really matter. The <var> 
element has now been defined to have such a wide and vague meaning that 
it is pointless to use it. There is little reason to expect that any 
software will ever pay attention to <var> markup on any semantic basis.

So authors will use <i> if they think italics is semantically essential, 
and <var> won?t be used much.

>> A programming
>> language variable is something that is _not_ conventionally rendered in
>> italics. Rather, they are usually (though for no really good reason)
>> rendered in a monospace font, like any other expressions in computer
>> languages.
>
> Indeed. And vectors are usually bold.

So why should authors be told to use markup that by default (and always 
when CSS is off) results in programming language constructs to be 
italicized? Flagging ?placeholders? with italics (as in ?issue the 
command <kbd>rm <i>filename</i></kbd> to delete a file) is a widely used 
and understood style, but programming language variables are a 
completely different issue.

>> Too bad there's no example of<var>  used in programming context. The
>> current wording suggests that it would be normal, when discussing
>> programming, to write, say, "Then we define the variable
>> <var>myFoo</var>  of type<code>fooType</code>  with initial value
>> <code>"Foo"</code>  - -", which really makes no sense, even if we use
>> both<var>  and<code>  for myFoo.
>
> Why does it make no sense?

Because it implies that in default rendering, identifiers of variables 
appear in italics whereas identifiers of types or classes do not. Why 
would anyone use extra <var> markup when it has no other implications 
than requiring extra CSS code to remove (when possible) italics?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From christoph.paeper at crissov.de  Tue Jul 26 04:04:07 2011
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 26 Jul 2011 13:04:07 +0200
Subject: [whatwg] [Selectors4] case-insensitive attribute value matching
	(in XML)
In-Reply-To: <op.vy6zxuiz64w2qv@annevk-macbookpro.local>
References: <op.vy48y1mf64w2qv@annevk-macbookpro.local>
	<4E2DA1D3.4020309@inkedblade.net>
	<20110725181711.GA22625@pickering.dbaron.org>
	<4E2DB9B0.60604@inkedblade.net>
	<6F190DD9-8EE6-450B-9FFE-ECD76945F80C@hp.com>
	<op.vy6zxuiz64w2qv@annevk-macbookpro.local>
Message-ID: <554C7A95-C4D6-4DAF-A62F-E5CB7A515C42@crissov.de>

Anne van Kesteren:
> I'm still trying to get HTML and browsers to change so that attribute values always match case-sensitively, irrespective of markup language. The current magic attribute list in HTML whose values needs to be matched ASCII case-insensitively is just ugly.

Can?t that be changed to something like the following?

  When an attribute takes as a value
  ? a single keyword or
  ? a whitespace-separated list of keywords,
  where all valid keywords are defined in this spexcification,
  these keywords are ASCII case-insensitive.
  All other attribute values are case-sensitive.

or just

  All element names, attribute names and attribute value keywords
  defined in this specification are ASCII case-insensitive.
  All other attribute values are case-sensitive.

From aykut.sensoy at bild.de  Tue Jul 26 04:27:35 2011
From: aykut.sensoy at bild.de (aykut.sensoy at bild.de)
Date: Tue, 26 Jul 2011 11:27:35 +0000
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <4E243F2C.2040605@gmx.de>
Message-ID: <CA547099.10D90%aykut.sensoy@bild.de>

http://www.google.com/support/news_pub/bin/answer.py?answer=93994

See Link above, Google says, that they provide "DC.date.issued", but this
is also not part auf the whatwg metaextensions list.
 


kind regards

Aykut



Am 18.07.11 16:11 schrieb "Julian Reschke" unter <julian.reschke at gmx.de>:

>On 2011-07-18 15:59, aykut.sensoy at bild.de wrote:
>> hi julian,
>> i have asked one from the seo team and he says for example the
>>"freshness
>> factor" is important for google.
>> is it possible to use the time-tag in the head instead (i mean
>>invisible)?
>> dc:created is also not in the Meta Extensions List, see:
>> http://wiki.whatwg.org/wiki/MetaExtensions
>
>I *believe* the SEO time is misguided when it thinks that
>meta/@name="date" affects Google. But only Google can tell us.
>
>I mentioned dc:created not because it's valid, but because it's at least
>*specified* and in more wider use.
>
>Best regards, Julian
>



From tommyw at google.com  Tue Jul 26 06:03:26 2011
From: tommyw at google.com (=?UTF-8?B?VG9tbXkgV2lkZW5mbHljaHQgKOGbj+GaruGbmOGbmOGapCk=?=)
Date: Tue, 26 Jul 2011 15:03:26 +0200
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
In-Reply-To: <Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
References: <4E242D26.3030401@alvestrand.no>
	<Pine.LNX.4.64.1107181834090.3775@ps20323.dreamhostps.com>
	<CALLKCfMjt27nVFqGckS=4FMmAAKSZLLR7Z+EZD+UuhK7ViNmqQ@mail.gmail.com>
	<Pine.LNX.4.64.1107260251170.2079@ps20323.dreamhostps.com>
Message-ID: <CALLKCfOeJLRL1ynw33NSC0bzvfWgQ1HYiZ3oTJJa5OSAN=44iQ@mail.gmail.com>

On Tue, Jul 26, 2011 at 07:30, Ian Hickson <ian at hixie.ch> wrote:
>
>
> > If you send two MediaStream objects constructed from the same
> > LocalMediaStream over a PeerConnection there needs to be a way to
> > separate them on the receiving side.
>
> What's the use case for sending the same feed twice?
>

There's no proper use case as such but the spec allows this.


>
>
> > I also think it is a bit unfortunate that we now have a 'label' property
> > on the track objects that means something else than the 'label' property
> > on MediaStream, perhaps 'description' would be a more suitable name for
> > the former.
>
> In what sense do they mean different things? I don't understand the
> problem here. Can you elaborate?
>

label on a MediaStream is a unique identifier, while the label on a
MediaStreamTrack is just a description like "Logitech Vision Pro", "Line In"
or "Built-in Mic". I too find this a bit odd.


>
>
> On Wed, 20 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote:
> > On Mon, Jul 18, 2011 at 20:38, Ian Hickson <ian at hixie.ch> wrote:
> > > On Mon, 18 Jul 2011, Tommy Widenflycht (??~[~O??~Z????~[~X??~[~X??~Z??)
> wrote:
> > > >
> > > > I am very confused regarding the below paragraph from the latest
> > > > spec:
> > > >
> > > > When a track in a MediaStream parent is disabled, any
> > > > MediaStreamTrack objects corresponding to the tracks in any
> > > > MediaStream objects that were created from parent are disassociated
> > > > from any track, and must not be reused for tracks again. If a
> > > > disabled track in a MediaStream parent is re-enabled, from the
> > > > perspective of any MediaStream objects that were created from parent
> > > > it is a new track and thus new MediaStreamTrack objects must be
> > > > created for the tracks that correspond to the re-enabled track.
> > > >
> > > > After cloning a LocalMediaStream it looks like this:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(E)           Track1(E)
> > > > Track2(E)           Track2(E)
> > > > Track3(E)           Track3(E)
> > > >
> > > > and as I interpret the spec it looks like this if Track1 in the
> > > > LocalMediaStream is disabled:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(D)           Track2(E)
> > > > Track2(E)           Track3(E)
> > > > Track3(E)
> > >
> > > Correct so far (though I'd avoid the term "cloning" since it's not
> > > quite what's going on here -- the spec uses "forking", which may be
> > > closer though is still not ideal).
> > >
> > > > So Track1 disappears from the MediaStream1 object and doesn't come
> > > > back even if Track1 in the LMS object is enabled:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(E)           Track2(E)
> > > > Track2(E)           Track3(E)
> > > > Track3(E)
> > >
> > > No, it'll create a new track object:
> > >
> > >  LocalMediaStream -> MediaStream1
> > >  Track1(E)           Track4(E)
> > >  Track2(E)           Track2(E)
> > >  Track3(E)           Track3(E)
> > >
> > > This is specified in the sentence that starts "If a disabled track in
> > > a MediaStream parent is re-enabled...".
> >
> > Thanks for the explanation. To me this sounds overly complicated, why
> > not just make it so that an disable of a track will override the track
> > settings for forked MediaStreams?
>
> I don't understand what you mean. How would that be different?
>
>
If I may make an analogy to the real world: plumbing.

Each fork of a MediaStream is a new joint in the pipe, my suggestion
introduces a tap at each joint. No matter how you open and close the tap at
the end (or middle); if any previous tap is closed there's nothing coming
through.
The spec currently removes and add the entire pipe after the changed joint.


>
> > Also some follow-up questions regarding the new TrackLists:
> >
> > What should happen when a track fails? Should the entire stream fail,
> > the MSTrack silently be removed or the MSTrack disassociated with the
> > track (and thus becoming a do-nothing object)?
>
> What do you mean by "fails"?
>

Yanking the USB cable to the camera for example. This should imho stop the
MS, not just silently send black video.


> > What should happen when a stream with two or more video tracks is
> > associated to a <video> tag? Just render the first enabled one?
>
> Same as if you had a regular video file with multiple tracks.
>
>
And that is? Sorry, this might be written down somewhere and I have missed
it.


/Tommy

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.


From ddahl at mozilla.com  Tue Jul 26 12:59:20 2011
From: ddahl at mozilla.com (David Dahl)
Date: Tue, 26 Jul 2011 12:59:20 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <1192225079.577736.1311175542151.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <815375749.651048.1311710360055.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

Hello All:

Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.

Summary:

    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
    HASH and HMAC methods may be implemented first
    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
        Keypairs must be generated on a per-origin basis
        The Keypair for a specific origin cannot be used in another origin 
    No private or wrapped key material will be accessible to content scripts
    Each implementation will provide a mechanism to clear keys
    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
    The returned encrypted object format will be a raw ArrayBuffer
    The public key format will be a raw ArrayBuffer
        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
    HASH and HMAC methods should be synchronous to make them simpler
        HASH and HMAC methods should be constructors 
    We may implement the HASH and HMAC APIs first then the PublicKey API

A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14

The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest 

Any comments and discussion will be most welcome.

Regards,

David Dahl


From scott at crisscott.com  Tue Jul 26 14:11:36 2011
From: scott at crisscott.com (=?utf-8?B?c2NvdHRAY3Jpc3Njb3R0LmNvbQ==?=)
Date: Tue, 26 Jul 2011 17:11:36 -0400
Subject: [whatwg]
	=?utf-8?q?PeerConnection=2C_MediaStream=2C_getUserMedia?=
	=?utf-8?q?=28=29=2C=09and_other_feedback?=
Message-ID: <0MTBQE-1Qt09R0kNS-00SFJA@mrelay.perfora.net>



----- Reply message -----
From: "Ian Hickson" <ian at hixie.ch>
Date: Tue, Jul 26, 2011 1:30 am
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),	and other feedback
To: "whatwg at whatwg.org" <whatwg at whatwg.org>


From Simetrical+w3c at gmail.com  Tue Jul 26 14:26:32 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Tue, 26 Jul 2011 17:26:32 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
Message-ID: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>

Since February, I've been working on writing a detailed specification
for browser editing, primarily the document.execCommand() and
document.queryCommand*() methods.  These were created by Microsoft in
the 1990s and were subsequently adopted in some form by all other
browsers, and today browsers have to implement them to be compatible
with web content, but no detailed specification ever existed.
Interoperability is practically nonexistent as a result, which has
driven all major content editing frameworks away from using
execCommand().  Hopefully we can start to fix that and make these APIs
a part of the web platform that just works.

The current version of the specification is at
<http://aryeh.name/spec/editing/editing.html>.  It's about fifty pages
printed, and supersedes the Editing APIs section of HTML
<http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis>
(which is more like two pages).  In the style of modern web specs, it
is phrased in terms of algorithms that attempt to cover all corner
cases unambiguously and leave no behavior undefined, and it tries to
match the behavior of existing browsers to the greatest extent
possible.  At this point, it's stable and complete enough that I
believe it's ready for serious review by implementers, and I would
like as much detailed feedback as possible.

There is a basically complete JavaScript implementation, which is used
to produce expected results for a largely undocumented and entirely ad
hoc test suite:
<http://aryeh.name/spec/editing/autoimplementation.html>.  I used the
tests as an aid to writing the spec, and they probably aren't well
suited to aid implementers in implementing it.  I will probably get
around to porting them to something like testharness.js at some point.
 I haven't tried testing my implementation on real-world sites, only
on artificial input, so I don't know at this point how implementable
it really is, but the JS implementation means that it at least has
large parts that make sense.

Anyone reviewing the spec should be advised that I put extensive
rationale in HTML comments.  If you want to know why the spec says
what it does, check the HTML source.  I plan to change this to use
<details> or such in the near future.  There are lots of minor known
issues still left, but none that I thought was important enough that
it needs to delay review.  Feedback can be sent to the whatwg list,
CCing me, with [editing] in the subject.  (I'm also fine receiving
feedback on public-html or public-webapps, but I don't know if the
chairs would be okay with that, since it's off-topic.)  I should be
available to respond to all feedback promptly at least through the end
of August.  After that, I can't make specific guarantees about my
availability, but I do plan to continue maintaining the spec in the
long term.

I've CCd or BCCd everyone who's commented on or contributed to this
spec at some point.


From ian at hixie.ch  Tue Jul 26 14:44:44 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Jul 2011 21:44:44 +0000 (UTC)
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
Message-ID: <Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>


On Fri, 29 Apr 2011, Simon Heckmann wrote:
> 
> I have read a lot in the last month about the future of html and web 
> applications and I am very impressed by the progress this makes. 
> However, I have come across some thing that annoys me: Permissions. I 
> know they are important and I know they are needed but currently I find 
> this quite inconvenient. And with more and more permissions coming up 
> this might get worse so I spent some time thinking about it.
> 
> I have written a short document covering my proposal: 
> www.simonheckmann.de/download/Proposal.pdf (3 pages, ~200KB)
> 
> It should just take only a few minutes to read and includes examples and 
> screenshots. I am really looking forward to hearing your thoughts on 
> this. Please feel free to share this idea with whomever you want to. If 
> you think I should post this proposal somewhere else please say so.

Robert O'Callahan posted a good response:

http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html

In short, the better solution isn't to ask for permissions up-front, but 
to ask for fewer permissions. The ideal solution is to not ask for any 
permission but to base the permission on a natural user gesture. For 
example, drag-and-drop of files to a site doesn't require permissions, but 
it is an implicit permission grant. Same with <input type=file>. With 
getUserMedia() we are doing something similar: instead of asking for 
permission, the user is asked for a specific input to be selected.

Permission grants are a bug.


On Sat, 30 Apr 2011, Glenn Maynard wrote:
> 
> I'd wonder what their response is to Android; the problems on that 
> platform are obvious.  The result is exactly as you say: people end up 
> giving up and just accepting everything.
> 
> (The permissions request for Skype includes: "read contact data, write 
> contact data, coarse (network-based) location, full Internet access, act 
> as an account authenticator, manage the accounts list, user the 
> authentication credentials of an account, modify/delete USB storage 
> contents, change your audio settings, record audio, read phone state and 
> identity, disable keylock, modify global system settings, prevent phone 
> from sleeping, retrieve running applications, write sync settings, view 
> network state, view Wi-Fi state, control vibrator, read sync settings, 
> read sync statistics, discover known accounts".  It's hopeless; if "take 
> out a mortgage on your house" was in there, nobody would notice.)
> 
> Of course, asking each of these while using the application would also 
> be painfully annoying, and it's not obvious how to make permissions 
> meaningful to the user (eg. when you use its feature) while also scaling 
> to lots of permissions.

Indeed. The system shouldn't ask for any permissions. For example instead 
of reading contact data, it could cause the OS to pop up a contacts list 
from which you can pick a contact to give access to it to the app.


On Sun, 1 May 2011, Robert O'Callahan wrote:
> 
> Notifications are a particularly hard case for the principle of 
> requesting permissions in response to user action, because the whole 
> point of notifications is that they happen when the user isn't giving 
> the application attention :-).

My proposal for notifications was to have them default to being just 
inside the page (nothing that a <div> couldn't do), but that they would 
include explicit UI to promote them to full-system notifications; and 
vice-versa, so a system notification could be demoted back to just in-page 
notification with a similar gesture.


On Tue, 3 May 2011, Cameron Heavon-Jones wrote:
> 
> The quantity of permission requests can be managed in an effective 
> manner by the agent allowing the user to store their preferences for the 
> next command or as a universal setting.

That doesn't work. It might be appropriate for Bing Maps to have access to 
my Geolocation information, but I certainly don't want some random blog to 
have access to it. Defaults don't work here.


> For web applications to specify their required permissions would seem to 
> introduce a duplication of specification. If a web application includes 
> an image file upload which the user chooses to capture from webcam, 
> first how is the application to know that the user would use a web cam?

There's no need for the app to know. It can just allow the user to upload 
a photo, and the browser can offer to use the webcam.



I haven't added anythign to the spec in relation to this proposal.

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


From silviapfeiffer1 at gmail.com  Tue Jul 26 14:58:30 2011
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 27 Jul 2011 07:58:30 +1000
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <815375749.651048.1311710360055.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
References: <1192225079.577736.1311175542151.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<815375749.651048.1311710360055.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>

If I understand this correctly, then this is introducing a mechanism
for Web publishers to provide a secure service to users where the data
exchanged between the server and the UA is encrypted and not decodable
by anyone else listening in on that communication or getting access to
the data stored in the browser for that communication.

If so, could this be a means to provide a one-session-only decoding
key to a UA to decode a specially encoded piece of content (e.g. a
video) from a publisher? I am quite directly thinking that this could
be a first step towards providing DRM methodology in the browser, but
also for example for about having secure private video conversations
without needing to install browser plugins.

Apologies for taking this thread a bit off topic - I am just curious.

Cheers,
Silvia.


On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
> Hello All:
>
> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>
> Summary:
>
> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
> ? ?HASH and HMAC methods may be implemented first
> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
> ? ? ? ?Keypairs must be generated on a per-origin basis
> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
> ? ?No private or wrapped key material will be accessible to content scripts
> ? ?Each implementation will provide a mechanism to clear keys
> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
> ? ?The returned encrypted object format will be a raw ArrayBuffer
> ? ?The public key format will be a raw ArrayBuffer
> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
> ? ?HASH and HMAC methods should be synchronous to make them simpler
> ? ? ? ?HASH and HMAC methods should be constructors
> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>
> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>
> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> Any comments and discussion will be most welcome.
>
> Regards,
>
> David Dahl
>


From ian at hixie.ch  Tue Jul 26 15:22:46 2011
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Jul 2011 22:22:46 +0000 (UTC)
Subject: [whatwg] Styling of datagrid content
In-Reply-To: <45F5DC15.8060306@westnet.com.au>
References: <45F5DC15.8060306@westnet.com.au>
Message-ID: <Pine.LNX.4.64.1107262221310.2079@ps20323.dreamhostps.com>

On Tue, 13 Mar 2007, Sean Hogan wrote:
>
> How do you define style for datagrids?
> e.g.
> - row color
> - alternating row color
> - selected row color
> - initial column widths
> - fixed column widths

For the time being, I have abandoned the idea of specifying a <datagrid> 
element. My plan is to wait to see if recent developments around XBL go 
anywhere, and if they do, see if <datagrid> can just be implemented using 
a widget binding by authors rather than having a native widget.

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


From ddahl at mozilla.com  Tue Jul 26 15:26:10 2011
From: ddahl at mozilla.com (David Dahl)
Date: Tue, 26 Jul 2011 15:26:10 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
Message-ID: <1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

Silvia:

The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.

I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.

Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).

The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases

Cheers,

David

----- Original Message -----
From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
To: "David Dahl" <ddahl at mozilla.com>
Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
Sent: Tuesday, July 26, 2011 4:58:30 PM
Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report

If I understand this correctly, then this is introducing a mechanism
for Web publishers to provide a secure service to users where the data
exchanged between the server and the UA is encrypted and not decodable
by anyone else listening in on that communication or getting access to
the data stored in the browser for that communication.

If so, could this be a means to provide a one-session-only decoding
key to a UA to decode a specially encoded piece of content (e.g. a
video) from a publisher? I am quite directly thinking that this could
be a first step towards providing DRM methodology in the browser, but
also for example for about having secure private video conversations
without needing to install browser plugins.

Apologies for taking this thread a bit off topic - I am just curious.

Cheers,
Silvia.


On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
> Hello All:
>
> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>
> Summary:
>
> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
> ? ?HASH and HMAC methods may be implemented first
> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
> ? ? ? ?Keypairs must be generated on a per-origin basis
> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
> ? ?No private or wrapped key material will be accessible to content scripts
> ? ?Each implementation will provide a mechanism to clear keys
> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
> ? ?The returned encrypted object format will be a raw ArrayBuffer
> ? ?The public key format will be a raw ArrayBuffer
> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
> ? ?HASH and HMAC methods should be synchronous to make them simpler
> ? ? ? ?HASH and HMAC methods should be constructors
> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>
> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>
> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> Any comments and discussion will be most welcome.
>
> Regards,
>
> David Dahl
>


From silviapfeiffer1 at gmail.com  Tue Jul 26 15:41:47 2011
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 27 Jul 2011 08:41:47 +1000
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Message-ID: <CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>

OK, so it would apply to a private video conference, but not to
protect a server-client-delivery. That's good to know, thanks.
Silvia.

On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
> Silvia:
>
> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>
> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>
> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>
> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>
> Cheers,
>
> David
>
> ----- Original Message -----
> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
> To: "David Dahl" <ddahl at mozilla.com>
> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
> Sent: Tuesday, July 26, 2011 4:58:30 PM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>
> If I understand this correctly, then this is introducing a mechanism
> for Web publishers to provide a secure service to users where the data
> exchanged between the server and the UA is encrypted and not decodable
> by anyone else listening in on that communication or getting access to
> the data stored in the browser for that communication.
>
> If so, could this be a means to provide a one-session-only decoding
> key to a UA to decode a specially encoded piece of content (e.g. a
> video) from a publisher? I am quite directly thinking that this could
> be a first step towards providing DRM methodology in the browser, but
> also for example for about having secure private video conversations
> without needing to install browser plugins.
>
> Apologies for taking this thread a bit off topic - I am just curious.
>
> Cheers,
> Silvia.
>
>
> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>> Hello All:
>>
>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>
>> Summary:
>>
>> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>> ? ?HASH and HMAC methods may be implemented first
>> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>> ? ? ? ?Keypairs must be generated on a per-origin basis
>> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
>> ? ?No private or wrapped key material will be accessible to content scripts
>> ? ?Each implementation will provide a mechanism to clear keys
>> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>> ? ?The returned encrypted object format will be a raw ArrayBuffer
>> ? ?The public key format will be a raw ArrayBuffer
>> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>> ? ?HASH and HMAC methods should be synchronous to make them simpler
>> ? ? ? ?HASH and HMAC methods should be constructors
>> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>>
>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>
>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>
>> Any comments and discussion will be most welcome.
>>
>> Regards,
>>
>> David Dahl
>>
>


From simon at simonheckmann.de  Tue Jul 26 15:55:30 2011
From: simon at simonheckmann.de (Simon Heckmann)
Date: Wed, 27 Jul 2011 00:55:30 +0200
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
Message-ID: <69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>

Okay, I am a little confused now: What about the following use case:

On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.

On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.

As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?

Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?

Thank you very much!

Kind regards,
Simon Heckmann


Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:

> OK, so it would apply to a private video conference, but not to
> protect a server-client-delivery. That's good to know, thanks.
> Silvia.
> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>> Silvia:
>> 
>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>> 
>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>> 
>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>> 
>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>> 
>> Cheers,
>> 
>> David
>> 
>> ----- Original Message -----
>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>> To: "David Dahl" <ddahl at mozilla.com>
>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>> 
>> If I understand this correctly, then this is introducing a mechanism
>> for Web publishers to provide a secure service to users where the data
>> exchanged between the server and the UA is encrypted and not decodable
>> by anyone else listening in on that communication or getting access to
>> the data stored in the browser for that communication.
>> 
>> If so, could this be a means to provide a one-session-only decoding
>> key to a UA to decode a specially encoded piece of content (e.g. a
>> video) from a publisher? I am quite directly thinking that this could
>> be a first step towards providing DRM methodology in the browser, but
>> also for example for about having secure private video conversations
>> without needing to install browser plugins.
>> 
>> Apologies for taking this thread a bit off topic - I am just curious.
>> 
>> Cheers,
>> Silvia.
>> 
>> 
>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>> Hello All:
>>> 
>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>> 
>>> Summary:
>>> 
>>>    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>    HASH and HMAC methods may be implemented first
>>>    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>        Keypairs must be generated on a per-origin basis
>>>        The Keypair for a specific origin cannot be used in another origin
>>>    No private or wrapped key material will be accessible to content scripts
>>>    Each implementation will provide a mechanism to clear keys
>>>    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>    The returned encrypted object format will be a raw ArrayBuffer
>>>    The public key format will be a raw ArrayBuffer
>>>        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>    HASH and HMAC methods should be synchronous to make them simpler
>>>        HASH and HMAC methods should be constructors
>>>    We may implement the HASH and HMAC APIs first then the PublicKey API
>>> 
>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>> 
>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>> 
>>> Any comments and discussion will be most welcome.
>>> 
>>> Regards,
>>> 
>>> David Dahl
>>> 
>> 


From roBman at mob-labs.com  Tue Jul 26 17:56:11 2011
From: roBman at mob-labs.com (Rob Manson)
Date: Wed, 27 Jul 2011 10:56:11 +1000
Subject: [whatwg] Access to live/raw audio and video stream data from both
 local and remote sources
Message-ID: <1311728171.2937.90113.camel@robslapu>

Hi,

sorry for posting across multiple groups, but I hope you'll see from my
comments below that this is really needed. 

This is definitely not intended as criticism of any of the work going
on.  It's intended as constructive feedback that hopefully provides
clarification on a key use case and it's supporting requirements.

        "Access to live/raw audio and video stream data from both local
        and remote sources in a consistent way"

I've spent quite a bit of time trying to follow a clear thread of
requirements/solutions that provide API access to raw stream data (e.g.
audio, video, etc.).  But I'm a bit concerned this is falling in the gap
between the DAP and RTC WGs.  If this is not the case then please point
me to the relevant docs and I'll happily get back in my box 8)

Here's how the thread seems to flow at the moment based on public
documents.

On the DAP page [1] the mission states:
        "the Device APIs and Policy Working Group is to create
        client-side APIs that enable the development of Web Applications
        and Web Widgets that interact with devices services such as
        Calendar, Contacts, Camera, etc"

So it seems clear that this is the place to start.  Further down that
page the "HTML Media Capture" and "Media Capture" APIs are listed.

HTML Media Capture (camera/microphone interactions through HTML forms)
initially seems like a good candidate, however the intro in the latest
PWD [2] clearly states:
        "Providing streaming access to these capabilities is outside of
        the scope of this specification."

Followed by a NOTE that states:
        "The Working Group is investigating the opportunity to specify
        streaming access via the proposed <device> element."
        
The link on the "proposed <device> element" [3] links to a "no longer
maintained" document that then redirects to the top level of the whatwg
"current work" page [4].  On that page the most relevant link is the
video conferencing and peer-to-peer communication section [5].  More
about that further below.

So back to the DAP page to follow explore the other Media Capture API
(programmatic access to camera/microphone) [1] and it's latest PWD [6].
The abstract states:
        "This specification defines an Application Programming Interface
        (API) that provides access to the audio, image and video capture
        capabilities of the device."

And the introduction states:
        "The Capture API defines a high-level interface for accessing
        the microphone and camera of a hosting device. It completes the
        HTML Form Based Media Capturing specification [HTMLMEDIACAPTURE]
        with a programmatic access to start a parametrized capture
        process."
        
So it seems clear that this is not related to streams in any way either.

The Notes column for this API on the DAP page [1] also states:
        "Programmatic API that completes the form based approach
        Need to check if still interest in this
        How does it relate with the Web RTC Working Group?"

Is there an updated position on this?

So if you then head over to the WebRTC WG's charter [7] it states:
        "...to define client-side APIs to enable Real-Time
        Communications in Web browsers.
        
        These APIs should enable building applications that can be run
        inside a browser, requiring no extra downloads or plugins, that
        allow communication between parties using audio, video and
        supplementary real-time communication, without having to use
        intervening servers..."
        
So this is clearly focused upon peer-to-peer communication "between"
systems and the stream related access is naturally just treated as an
ancillary requirement.  The scope section then states:
        "Enabling real-time communications between Web browsers require
        the following client-side technologies to be available:
        
        - API functions to explore device capabilities, e.g. camera,
        microphone, speakers (currently in scope for the Device APIs &
        Policy Working Group)
        - API functions to capture media from local devices (camera and
        microphone) (currently in scope for the Device APIs & Policy
        Working Group)
        - API functions for encoding and other processing of those media
        streams,
        - API functions for establishing direct peer-to-peer
        connections, including firewall/NAT traversal
        - API functions for decoding and processing (including echo
        cancelling, stream synchronization and a number of other
        functions) of those streams at the incoming end,
        - Delivery to the user of those media streams via local screens
        and audio output devices (partially covered with HTML5)"
        
So this is where I really start to feel the gap growing.  The DAP is
pointing to RTC saying not sure how if our Camera/Microphone APIs are
being superseded by the work in the RTC...and the RTC then points back
to say it will be relying on work in the DAP.  However the RTCs
Recommended Track Deliverables list does include:
        "Media Stream Functions, Audio Stream Functions and Video Stream
        Functions"

So then it's back to the whatwg MediaStream and LocalMediaStream current
work [8].  Following this through you end up back at the <audio> and
<video> media element with some brief discussion about media data [9].

Currently the only API that I'm aware of that allows live access to the
audio data through the <audio> tag is the relatively proprietary Mozilla
Audio Data API [10].

And while the video stream data can be accessed by rendering each frame
into a canvas 2d graphics context and then using getImageData to extract
and manipulate it from there [11], this seems more like a work around
than an elegantly designed solution.
 
As I said above, this is not intended as a criticism of the work that
the DAP WG, WebRTC WG or WHATWG are doing.  It's intended as
constructive feedback to highlight that the important use case of
"Access to live/raw audio and video stream data from both local and
remote sources" appears to be falling in the gaps between the groups. 

>From my perspective this is a critical use case for many advanced web
apps that will help bring them in line with what's possible in the
native single vendor stack based apps at the moment (e.g. iPhone &
Android).  And it's also critical for the advancement of web standards
based AR applications and other computer vision, hearing and signal
processing applications.

I understand that a lot of these specifications I've covered are in very
formative stages and that requirements and PWDs are just being drafted
as I write.  And that's exactly why I'm raising this as a single and
consolidated perspective that spans all these groups.  I hope this goes
some way towards "Access to live/raw audio and video stream data from
both local and remote sources" being treated as an essential and core
use case that binds together the work of all these groups.  With a clear
vision for this and a little consolidated work I think this will then
also open up a wide range of other app opportunities that we haven't
even thought of yet.  But at the moment it really feels like this is
being treated as an assumed requirement and could end up as a poorly
formed second class bundle of semi-related API hooks.

For this use case I'd really like these clear requirements to be
supported:
- access the raw stream data for both audio and video in similar ways
- access the raw stream data from both remote and local streams in
similar ways
- ability to inject new data or the transformed original data back into
streams and presented audio/video tags in a consistent way
- all of this be optimised for performance to meet the demands of live
signal processing

roBman

PS: I've also cc'd in the mozilla dev list as I think this directly
relates to the current "booting to the web" thread [12]


[1] http://www.w3.org/2009/dap/
[2] http://www.w3.org/TR/2011/WD-html-media-capture-20110414/#introduction
[3] http://dev.w3.org/html5/html-device/ 
[4] http://www.whatwg.org/specs/web-apps/current-work/complete/#devices 
[5] http://www.whatwg.org/specs/web-apps/current-work/complete/#auto-toc-9
[6] http://www.w3.org/TR/2010/WD-media-capture-api-20100928/
[7] http://www.w3.org/2011/04/webrtc-charter.html
[8] http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html#mediastream 
[9] http://www.whatwg.org/specs/web-apps/current-work/complete/the-iframe-element.html#media-data
[10] https://wiki.mozilla.org/Audio_Data_API
[11] https://developer.mozilla.org/En/Manipulating_video_using_canvas
[12] http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/7668a9d46a43e482# 



From w3c at adambarth.com  Tue Jul 26 19:14:40 2011
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 26 Jul 2011 19:14:40 -0700
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
Message-ID: <CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>

Hi Simon,

That would look something like the following:

== Phase 1: Key Generation (Client-Side) ==

crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
  ... send pubKey to the server ...
  ... store keyID somewhere??? ...
});

== Phase 2: Encryption (Server-Side) ==

The server encrypts file F under public key pubKey.
The server sends the encrypted file EF to the client and stores it
locally using the File API.

== Phase 3: Decryption (Client-Side) ==

... retrieve keyID from somewhere??? ...

crypto.pk.decrypt(EF, keyID, function(plainText) {
  ... rejoice ...
});

To fill in the ??? we need to store the keyID somewhere.  (To be
clear, the keyID is just a capability to use the private key, which
never leaves the user agent's secure key store.)  To complete your
example, we'd need to provide a facility to protect the keyID with the
user's password.

Adam


On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
> Okay, I am a little confused now: What about the following use case:
>
> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>
> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>
> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>
> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>
> Thank you very much!
>
> Kind regards,
> Simon Heckmann
>
>
> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>
>> OK, so it would apply to a private video conference, but not to
>> protect a server-client-delivery. That's good to know, thanks.
>> Silvia.
>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>> Silvia:
>>>
>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>
>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>
>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>
>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> ----- Original Message -----
>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>> To: "David Dahl" <ddahl at mozilla.com>
>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>
>>> If I understand this correctly, then this is introducing a mechanism
>>> for Web publishers to provide a secure service to users where the data
>>> exchanged between the server and the UA is encrypted and not decodable
>>> by anyone else listening in on that communication or getting access to
>>> the data stored in the browser for that communication.
>>>
>>> If so, could this be a means to provide a one-session-only decoding
>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>> video) from a publisher? I am quite directly thinking that this could
>>> be a first step towards providing DRM methodology in the browser, but
>>> also for example for about having secure private video conversations
>>> without needing to install browser plugins.
>>>
>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>
>>> Cheers,
>>> Silvia.
>>>
>>>
>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>> Hello All:
>>>>
>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>
>>>> Summary:
>>>>
>>>> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>> ? ?HASH and HMAC methods may be implemented first
>>>> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>> ? ? ? ?Keypairs must be generated on a per-origin basis
>>>> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
>>>> ? ?No private or wrapped key material will be accessible to content scripts
>>>> ? ?Each implementation will provide a mechanism to clear keys
>>>> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>> ? ?The returned encrypted object format will be a raw ArrayBuffer
>>>> ? ?The public key format will be a raw ArrayBuffer
>>>> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>> ? ?HASH and HMAC methods should be synchronous to make them simpler
>>>> ? ? ? ?HASH and HMAC methods should be constructors
>>>> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>
>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>
>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>
>>>> Any comments and discussion will be most welcome.
>>>>
>>>> Regards,
>>>>
>>>> David Dahl
>>>>
>>>
>


From ddahl at mozilla.com  Tue Jul 26 21:42:28 2011
From: ddahl at mozilla.com (David Dahl)
Date: Tue, 26 Jul 2011 21:42:28 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
Message-ID: <1678257437.657460.1311741748246.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>


----- Original Message ----
> From: "Simon Heckmann" <simon at simonheckmann.de>
> To: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
> Cc: "David Dahl" <ddahl at mozilla.com>, "WHATWG Proposals" <whatwg at lists.whatwg.org>
> Sent: Tuesday, July 26, 2011 5:55:30 PM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report

> Additionally, are there plans or a roapmap to bring the DOMCrypt
> specification to a W3C technical report?
> 

Yes. Getting this API on a standards track is one of the project goals.

Cheers,

David


From rniwa at webkit.org  Tue Jul 26 23:34:54 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Tue, 26 Jul 2011 23:34:54 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Message-ID: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>

Hi all,

In the last couple of weeks, I've been working with developers of CKEditor,
TinyMCE, and Google Docs to come up with *new API for undo and redo*.

Why? Because* undo and redo are broken on the Web today*. Whenever Web apps
try to add a custom editing operation without using execCommand or do a "fix
up" after browser executes a user editing action, user agents get confused
by DOM mutations made by the apps and won't be able to undo or redo user
editing actions and execCommand. This forces Web apps to re-implement undo
and redo themselves, and in fact, *many rich text editors store innerHTML of
a contenteditable element* as a string in their internal undo transaction
history (a.k.a undo stack).

Also, there's no way for Web apps to add new undo item and populate undo and
redo menus on user agent's native UI.  In addition, if an editor app has a
widget with input/textarea, then the undo stack of the editor gets confused
when the widget goes away because the undo transaction history exists only
per document.

In order to solve above and numerous other problems, we've come to a
conclusion that we need to *add UndoManager and Transaction*.

*UndoManager* is an interface for managing undo transaction history.  It
exists on a document and an element with the *undoscope* content attribute.
 UndoManager applies new transaction (i.e. make undoable DOM changes) and
manage them.  The main purpose of UndoManager is to communicate the list of
undoable items with the user agent so that the user agent can provide a
native UI (e.g. populating menu items with them).

A *transaction* is a collection of DOM mutations that can be applied,
unapplied, or reapplied. UndoManager manages transactions and execute
unapply and reapply upon undo and redo respectively.

There are two types of DOM transactions:

   - *Managed transaction* - the app supplies apply() and the user agent
   automatically takes care of undo and redo. It is *compatible with user
   editing actions and editing commands*, and allows Web apps to easily add
   new editing operations or fix up DOM after user editing actions or editing
   commands and still have the user agent manage the undo and redo.
   - *Manual transaction* - the app supplies apply(), unapply(), and
   reapply() and *the app takes the full control of undo and redo*. However,
   it is NOT compatible with user editing actions, editing commands, or managed
   transactions, meaning that, the user agents won't be able to undo or redo
   them. This transaction is useful for apps such as a collaborative editor
   that implements domain-specific undo or redo.

You can see more concrete definitions of UndoManager and Transaction at:
https://rniwa.com/editing/undomanager.html and see a list of uses cases at
https://rniwa.com/editing/undomanager-usecases.html.  The documents are
incomplete and I need your feedback in order to refine details.

Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.


From simon at simonheckmann.de  Wed Jul 27 01:18:18 2011
From: simon at simonheckmann.de (Simon Heckmann)
Date: Wed, 27 Jul 2011 10:18:18 +0200
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
	<CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
Message-ID: <2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>

Thank you for your reply, but to me this seems overly complicated. Why do I need a KeyId?

What about the following proposal:

Phase one: The server knows the user's password and encrypts the file.
Phase two: The encrypted file is stored on the local hard drive using the File API.
Pase three: User enters the password, which is hashed and used for decryption:

var password = document.getElementById('passwordfield').value;
var hash = window.crypto.hash('md5', password);
var data = window.crypto.decrypt('aes-256', hash, encfiledata);

This code is just a sample, but it looks way more convenient to me. Additionally there is no need to store the keyid somewhere?!?

Kind regards,
Simon Heckmann


Am 27.07.2011 um 04:14 schrieb Adam Barth <w3c at adambarth.com>:

> Hi Simon,
> 
> That would look something like the following:
> 
> == Phase 1: Key Generation (Client-Side) ==
> 
> crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
>  ... send pubKey to the server ...
>  ... store keyID somewhere??? ...
> });
> 
> == Phase 2: Encryption (Server-Side) ==
> 
> The server encrypts file F under public key pubKey.
> The server sends the encrypted file EF to the client and stores it
> locally using the File API.
> 
> == Phase 3: Decryption (Client-Side) ==
> 
> ... retrieve keyID from somewhere??? ...
> 
> crypto.pk.decrypt(EF, keyID, function(plainText) {
>  ... rejoice ...
> });
> 
> To fill in the ??? we need to store the keyID somewhere.  (To be
> clear, the keyID is just a capability to use the private key, which
> never leaves the user agent's secure key store.)  To complete your
> example, we'd need to provide a facility to protect the keyID with the
> user's password.
> 
> Adam
> 
> 
> On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
>> Okay, I am a little confused now: What about the following use case:
>> 
>> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>> 
>> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>> 
>> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>> 
>> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>> 
>> Thank you very much!
>> 
>> Kind regards,
>> Simon Heckmann
>> 
>> 
>> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>> 
>>> OK, so it would apply to a private video conference, but not to
>>> protect a server-client-delivery. That's good to know, thanks.
>>> Silvia.
>>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>> Silvia:
>>>> 
>>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>> 
>>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>> 
>>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>> 
>>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>> 
>>>> Cheers,
>>>> 
>>>> David
>>>> 
>>>> ----- Original Message -----
>>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>>> To: "David Dahl" <ddahl at mozilla.com>
>>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>> 
>>>> If I understand this correctly, then this is introducing a mechanism
>>>> for Web publishers to provide a secure service to users where the data
>>>> exchanged between the server and the UA is encrypted and not decodable
>>>> by anyone else listening in on that communication or getting access to
>>>> the data stored in the browser for that communication.
>>>> 
>>>> If so, could this be a means to provide a one-session-only decoding
>>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>>> video) from a publisher? I am quite directly thinking that this could
>>>> be a first step towards providing DRM methodology in the browser, but
>>>> also for example for about having secure private video conversations
>>>> without needing to install browser plugins.
>>>> 
>>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>> 
>>>> Cheers,
>>>> Silvia.
>>>> 
>>>> 
>>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>> Hello All:
>>>>> 
>>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>> 
>>>>> Summary:
>>>>> 
>>>>>    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>>>    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>>>    HASH and HMAC methods may be implemented first
>>>>>    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>>>        Keypairs must be generated on a per-origin basis
>>>>>        The Keypair for a specific origin cannot be used in another origin
>>>>>    No private or wrapped key material will be accessible to content scripts
>>>>>    Each implementation will provide a mechanism to clear keys
>>>>>    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>>>    The returned encrypted object format will be a raw ArrayBuffer
>>>>>    The public key format will be a raw ArrayBuffer
>>>>>        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>>>    HASH and HMAC methods should be synchronous to make them simpler
>>>>>        HASH and HMAC methods should be constructors
>>>>>    We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>> 
>>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>> 
>>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>> 
>>>>> Any comments and discussion will be most welcome.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> David Dahl
>>>>> 
>>>> 
>> 


From w3c at adambarth.com  Wed Jul 27 01:57:04 2011
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 27 Jul 2011 01:57:04 -0700
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
	<CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
	<2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>
Message-ID: <CAJE5ia_SC=ChnMesE1hXejkHjWZYByVC1x-9kkUJDXahMJqGRA@mail.gmail.com>

The downside of that sort of API is that you end up storing key
material in the JavaScript heap.  There's some question about whether
we should avoid doing that, which is part of the motivation to do the
public key API before the symmetric API.

Your example also raise the question of how to do key derivation and
key agreement.  Taking the MD5 hash of a password isn't really the
best key derivation function!  There's a design question of whether we
should design the API to be usable (relatively) safely by non-experts.
 Given that this is an API for the web, you can understand the desire
to make things as "idiot-proof" as possible.

I'd certainly like to see DOMCrypt be able to handle these sorts of
use cases in the future.  It's mostly a question of which use cases to
address first.

Adam


On Wed, Jul 27, 2011 at 1:18 AM, Simon Heckmann <simon at simonheckmann.de> wrote:
> Thank you for your reply, but to me this seems overly complicated. Why do I need a KeyId?
>
> What about the following proposal:
>
> Phase one: The server knows the user's password and encrypts the file.
> Phase two: The encrypted file is stored on the local hard drive using the File API.
> Pase three: User enters the password, which is hashed and used for decryption:
>
> var password = document.getElementById('passwordfield').value;
> var hash = window.crypto.hash('md5', password);
> var data = window.crypto.decrypt('aes-256', hash, encfiledata);
>
> This code is just a sample, but it looks way more convenient to me. Additionally there is no need to store the keyid somewhere?!?
>
> Kind regards,
> Simon Heckmann
>
>
> Am 27.07.2011 um 04:14 schrieb Adam Barth <w3c at adambarth.com>:
>
>> Hi Simon,
>>
>> That would look something like the following:
>>
>> == Phase 1: Key Generation (Client-Side) ==
>>
>> crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
>> ?... send pubKey to the server ...
>> ?... store keyID somewhere??? ...
>> });
>>
>> == Phase 2: Encryption (Server-Side) ==
>>
>> The server encrypts file F under public key pubKey.
>> The server sends the encrypted file EF to the client and stores it
>> locally using the File API.
>>
>> == Phase 3: Decryption (Client-Side) ==
>>
>> ... retrieve keyID from somewhere??? ...
>>
>> crypto.pk.decrypt(EF, keyID, function(plainText) {
>> ?... rejoice ...
>> });
>>
>> To fill in the ??? we need to store the keyID somewhere. ?(To be
>> clear, the keyID is just a capability to use the private key, which
>> never leaves the user agent's secure key store.) ?To complete your
>> example, we'd need to provide a facility to protect the keyID with the
>> user's password.
>>
>> Adam
>>
>>
>> On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
>>> Okay, I am a little confused now: What about the following use case:
>>>
>>> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>>>
>>> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>>>
>>> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>>>
>>> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>>>
>>> Thank you very much!
>>>
>>> Kind regards,
>>> Simon Heckmann
>>>
>>>
>>> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>>>
>>>> OK, so it would apply to a private video conference, but not to
>>>> protect a server-client-delivery. That's good to know, thanks.
>>>> Silvia.
>>>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>> Silvia:
>>>>>
>>>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>>>
>>>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>>>
>>>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>>>
>>>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>>>> To: "David Dahl" <ddahl at mozilla.com>
>>>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>>>
>>>>> If I understand this correctly, then this is introducing a mechanism
>>>>> for Web publishers to provide a secure service to users where the data
>>>>> exchanged between the server and the UA is encrypted and not decodable
>>>>> by anyone else listening in on that communication or getting access to
>>>>> the data stored in the browser for that communication.
>>>>>
>>>>> If so, could this be a means to provide a one-session-only decoding
>>>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>>>> video) from a publisher? I am quite directly thinking that this could
>>>>> be a first step towards providing DRM methodology in the browser, but
>>>>> also for example for about having secure private video conversations
>>>>> without needing to install browser plugins.
>>>>>
>>>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>>>
>>>>> Cheers,
>>>>> Silvia.
>>>>>
>>>>>
>>>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>>> Hello All:
>>>>>>
>>>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>>>> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>>>> ? ?HASH and HMAC methods may be implemented first
>>>>>> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>>>> ? ? ? ?Keypairs must be generated on a per-origin basis
>>>>>> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
>>>>>> ? ?No private or wrapped key material will be accessible to content scripts
>>>>>> ? ?Each implementation will provide a mechanism to clear keys
>>>>>> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>>>> ? ?The returned encrypted object format will be a raw ArrayBuffer
>>>>>> ? ?The public key format will be a raw ArrayBuffer
>>>>>> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>>>> ? ?HASH and HMAC methods should be synchronous to make them simpler
>>>>>> ? ? ? ?HASH and HMAC methods should be constructors
>>>>>> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>>>
>>>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>>>
>>>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>>>
>>>>>> Any comments and discussion will be most welcome.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David Dahl
>>>>>>
>>>>>
>>>
>


From simon at simonheckmann.de  Wed Jul 27 02:13:38 2011
From: simon at simonheckmann.de (Simon Heckmann)
Date: Wed, 27 Jul 2011 11:13:38 +0200
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <CAJE5ia_SC=ChnMesE1hXejkHjWZYByVC1x-9kkUJDXahMJqGRA@mail.gmail.com>
References: <CAHp8n2mVhwvmF1G4Spu9L97mwSZyBW4XxSW7B1tCdJ=X4dSMFA@mail.gmail.com>
	<1156126509.653623.1311719170364.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
	<CAHp8n2nfJH2XtJMarW5241eRNac1Ddoy_V=WLV-aXXsUyiE51w@mail.gmail.com>
	<69AA745C-5A10-487D-A50E-6409AEEAD4C1@simonheckmann.de>
	<CAJE5ia9nRuJcGxTSqgiyZcXm9-YSj2O-2EQYOqbO3jpL0L6BBA@mail.gmail.com>
	<2576C833-0446-4C70-8355-5C0EDC66397D@simonheckmann.de>
	<CAJE5ia_SC=ChnMesE1hXejkHjWZYByVC1x-9kkUJDXahMJqGRA@mail.gmail.com>
Message-ID: <C5A3FA4E-0BB2-4695-A50E-5838E1AB62F8@simonheckmann.de>

I totally agree with you. My code was just an example. I also think it should be idiot proof. 

However, I think the whole API should be loosly coupled. Requiring the client to initialize a cryptographic function on the server seems to tightly linked. I think it should be possible to decrypt any chunk of data with the DOMCrypt API as long as I know the algorithm and the key. But maybe this is out of scope and I am thinking in too universal concepts?

Kind regards,
Simon Heckmann


Am 27.07.2011 um 10:57 schrieb Adam Barth <w3c at adambarth.com>:

> The downside of that sort of API is that you end up storing key
> material in the JavaScript heap.  There's some question about whether
> we should avoid doing that, which is part of the motivation to do the
> public key API before the symmetric API.
> 
> Your example also raise the question of how to do key derivation and
> key agreement.  Taking the MD5 hash of a password isn't really the
> best key derivation function!  There's a design question of whether we
> should design the API to be usable (relatively) safely by non-experts.
> Given that this is an API for the web, you can understand the desire
> to make things as "idiot-proof" as possible.
> 
> I'd certainly like to see DOMCrypt be able to handle these sorts of
> use cases in the future.  It's mostly a question of which use cases to
> address first.
> 
> Adam
> 
> 
> On Wed, Jul 27, 2011 at 1:18 AM, Simon Heckmann <simon at simonheckmann.de> wrote:
>> Thank you for your reply, but to me this seems overly complicated. Why do I need a KeyId?
>> 
>> What about the following proposal:
>> 
>> Phase one: The server knows the user's password and encrypts the file.
>> Phase two: The encrypted file is stored on the local hard drive using the File API.
>> Pase three: User enters the password, which is hashed and used for decryption:
>> 
>> var password = document.getElementById('passwordfield').value;
>> var hash = window.crypto.hash('md5', password);
>> var data = window.crypto.decrypt('aes-256', hash, encfiledata);
>> 
>> This code is just a sample, but it looks way more convenient to me. Additionally there is no need to store the keyid somewhere?!?
>> 
>> Kind regards,
>> Simon Heckmann
>> 
>> 
>> Am 27.07.2011 um 04:14 schrieb Adam Barth <w3c at adambarth.com>:
>> 
>>> Hi Simon,
>>> 
>>> That would look something like the following:
>>> 
>>> == Phase 1: Key Generation (Client-Side) ==
>>> 
>>> crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
>>>  ... send pubKey to the server ...
>>>  ... store keyID somewhere??? ...
>>> });
>>> 
>>> == Phase 2: Encryption (Server-Side) ==
>>> 
>>> The server encrypts file F under public key pubKey.
>>> The server sends the encrypted file EF to the client and stores it
>>> locally using the File API.
>>> 
>>> == Phase 3: Decryption (Client-Side) ==
>>> 
>>> ... retrieve keyID from somewhere??? ...
>>> 
>>> crypto.pk.decrypt(EF, keyID, function(plainText) {
>>>  ... rejoice ...
>>> });
>>> 
>>> To fill in the ??? we need to store the keyID somewhere.  (To be
>>> clear, the keyID is just a capability to use the private key, which
>>> never leaves the user agent's secure key store.)  To complete your
>>> example, we'd need to provide a facility to protect the keyID with the
>>> user's password.
>>> 
>>> Adam
>>> 
>>> 
>>> On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <simon at simonheckmann.de> wrote:
>>>> Okay, I am a little confused now: What about the following use case:
>>>> 
>>>> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's password.
>>>> 
>>>> On the client: Download the file and save it on the hard drive using the File API. Some time later when offline the user can then enter their password. DOMCrypt calculates the MD5 hash of the password and decrypts the locally stored file so it can be viewed by the user.
>>>> 
>>>> As far as I understand your specification this scenario should be supported, right? How would this look like in source code? Could you give an example of the JavaScript DOMCrypt calls required for this?
>>>> 
>>>> Additionally, are there plans or a roapmap to bring the DOMCrypt specification to a W3C technical report?
>>>> 
>>>> Thank you very much!
>>>> 
>>>> Kind regards,
>>>> Simon Heckmann
>>>> 
>>>> 
>>>> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <silviapfeiffer1 at gmail.com>:
>>>> 
>>>>> OK, so it would apply to a private video conference, but not to
>>>>> protect a server-client-delivery. That's good to know, thanks.
>>>>> Silvia.
>>>>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>>> Silvia:
>>>>>> 
>>>>>> The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.
>>>>>> 
>>>>>> I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.
>>>>>> 
>>>>>> Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).
>>>>>> 
>>>>>> The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
>>>>>> To: "David Dahl" <ddahl at mozilla.com>
>>>>>> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
>>>>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>>>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>>>> 
>>>>>> If I understand this correctly, then this is introducing a mechanism
>>>>>> for Web publishers to provide a secure service to users where the data
>>>>>> exchanged between the server and the UA is encrypted and not decodable
>>>>>> by anyone else listening in on that communication or getting access to
>>>>>> the data stored in the browser for that communication.
>>>>>> 
>>>>>> If so, could this be a means to provide a one-session-only decoding
>>>>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>>>>> video) from a publisher? I am quite directly thinking that this could
>>>>>> be a first step towards providing DRM methodology in the browser, but
>>>>>> also for example for about having secure private video conversations
>>>>>> without needing to install browser plugins.
>>>>>> 
>>>>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>>>> 
>>>>>> Cheers,
>>>>>> Silvia.
>>>>>> 
>>>>>> 
>>>>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
>>>>>>> Hello All:
>>>>>>> 
>>>>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>>>>>>> 
>>>>>>> Summary:
>>>>>>> 
>>>>>>>    DOMCrypt is a high-level API that should be usable by web developers after a short period of study
>>>>>>>    DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
>>>>>>>    HASH and HMAC methods may be implemented first
>>>>>>>    The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
>>>>>>>        Keypairs must be generated on a per-origin basis
>>>>>>>        The Keypair for a specific origin cannot be used in another origin
>>>>>>>    No private or wrapped key material will be accessible to content scripts
>>>>>>>    Each implementation will provide a mechanism to clear keys
>>>>>>>    A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
>>>>>>>    The returned encrypted object format will be a raw ArrayBuffer
>>>>>>>    The public key format will be a raw ArrayBuffer
>>>>>>>        **We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
>>>>>>>    HASH and HMAC methods should be synchronous to make them simpler
>>>>>>>        HASH and HMAC methods should be constructors
>>>>>>>    We may implement the HASH and HMAC APIs first then the PublicKey API
>>>>>>> 
>>>>>>> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>>>>>> 
>>>>>>> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>>>> 
>>>>>>> Any comments and discussion will be most welcome.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> David Dahl
>>>>>>> 
>>>>>> 
>>>> 
>> 


From ddahl at mozilla.com  Wed Jul 27 07:16:17 2011
From: ddahl at mozilla.com (David Dahl)
Date: Wed, 27 Jul 2011 07:16:17 -0700 (PDT)
Subject: [whatwg] DOMCrypt update: July 14 Meeting Report
In-Reply-To: <C5A3FA4E-0BB2-4695-A50E-5838E1AB62F8@simonheckmann.de>
Message-ID: <921425056.660750.1311776177162.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

----- Original Message -----
> From: "Simon Heckmann" <simon at simonheckmann.de>
> To: "Adam Barth" <w3c at adambarth.com>
> Cc: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>, "WHATWG Proposals" <whatwg at lists.whatwg.org>, "David Dahl"
> <ddahl at mozilla.com>
> Sent: Wednesday, July 27, 2011 4:13:38 AM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
> I totally agree with you. My code was just an example. I also think it
> should be idiot proof.
> 
> However, I think the whole API should be loosly coupled. Requiring the
> client to initialize a cryptographic function on the server seems to
> tightly linked. 
This is how we can limit the scope and reduce the attacks that are possible cross-domain. The keypair is usable only with the origin that created it.  

> I think it should be possible to decrypt any chunk of
> data with the DOMCrypt API as long as I know the algorithm and the
> key. But maybe this is out of scope and I am thinking in too universal
> concepts?
> 
Perhaps, however, your use cases are not out of the question. We just want to start with a smaller surface, making this API simpler to implement and use.

Regards,

David


From mhanson at mozilla.com  Wed Jul 27 09:30:26 2011
From: mhanson at mozilla.com (Mike Hanson)
Date: Wed, 27 Jul 2011 09:30:26 -0700
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
	<Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
Message-ID: <43DCE7F1-AD1A-4587-A0BA-E61B9F2AA291@mozilla.com>

On Jul 26, 2011, at 2:44 PM, Ian Hickson wrote:

> On Fri, 29 Apr 2011, Simon Heckmann wrote:
>> 
>> I have read a lot in the last month about the future of html and web 
>> applications and I am very impressed by the progress this makes. 
>> However, I have come across some thing that annoys me: Permissions. I 
>> know they are important and I know they are needed but currently I find 
>> this quite inconvenient. And with more and more permissions coming up 
>> this might get worse so I spent some time thinking about it.
> 
> <snip>
> In short, the better solution isn't to ask for permissions up-front, but 
> to ask for fewer permissions. The ideal solution is to not ask for any 
> permission but to base the permission on a natural user gesture. For 
> example, drag-and-drop of files to a site doesn't require permissions, but 
> it is an implicit permission grant. Same with <input type=file>. With 
> getUserMedia() we are doing something similar: instead of asking for 
> permission, the user is asked for a specific input to be selected.
> <snip>
> Indeed. The system shouldn't ask for any permissions. For example instead 
> of reading contact data, it could cause the OS to pop up a contacts list 
> from which you can pick a contact to give access to it to the app.

The challenging use case, and one that we had trouble with when we prototyped the Contacts API, is for ongoing or persistent access.  The best approach we have right now is to use explicit markup to "sandbox" the permissions grant away from untrusted code.

In the Contacts case, for example, autocomplete of email addresses, names, and phone numbers was a desired use case.  A naive approach is to let the web app read the entire database and perform autocompletion in content.  The safe approach, which was harder and less flexible, is to attach autocomplete behavior to input type="tel" and "email", and to set the autocompleted value only when the user has selected it.

There are definite UX limitations to that approach - the content can't provide visual hinting during the autocomplete, for example (it would be nice if a photo gallery could trim down the set of photos from my friends as I narrow in on the name).  The limitations create an incentive for content to try to get the full set of data anyway, through some other channel.  As Roc commented, finding a way to be comfortable with a higher-level permissions grant that persisted over a longer span could be one way to address that.
--
Michael Hanson, Mozilla Labs

From cmhjones at gmail.com  Wed Jul 27 09:59:36 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Wed, 27 Jul 2011 17:59:36 +0100
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
	<Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
Message-ID: <49A84F2A-C13D-4E96-860D-6CB9854E0523@gmail.com>


On 26/07/2011, at 10:44 PM, Ian Hickson wrote:
> Robert O'Callahan posted a good response:
> 
> http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html
> 
> In short, the better solution isn't to ask for permissions up-front, but 
> to ask for fewer permissions. The ideal solution is to not ask for any 
> permission but to base the permission on a natural user gesture. For 
> example, drag-and-drop of files to a site doesn't require permissions, but 
> it is an implicit permission grant. Same with <input type=file>. With 
> getUserMedia() we are doing something similar: instead of asking for 
> permission, the user is asked for a specific input to be selected.
> 
> Permission grants are a bug.
> 

nice recap and clarity on implicit vs explicit permissions. the concept of asking for permission and how to manage this would seem to remain open for explicit permission grants, the most pressing case being geolocation. might there be more use cases in future? this may open the case for more universal management mechanism through the UA, and potentially a generalized specification?

> On Sat, 30 Apr 2011, Glenn Maynard wrote:
>> 
>> Of course, asking each of these while using the application would also 
>> be painfully annoying, and it's not obvious how to make permissions 
>> meaningful to the user (eg. when you use its feature) while also scaling 
>> to lots of permissions.
> 
> Indeed. The system shouldn't ask for any permissions. For example instead 
> of reading contact data, it could cause the OS to pop up a contacts list 
> from which you can pick a contact to give access to it to the app.

yes, possibly permissions should be viewed not in terms of the resource they may require to access (webcam, mic, printer, etc) but the conceptual user interaction - image\video source, audio source, document serialization, etc...

> 
> On Sun, 1 May 2011, Robert O'Callahan wrote:
>> 
>> Notifications are a particularly hard case for the principle of 
>> requesting permissions in response to user action, because the whole 
>> point of notifications is that they happen when the user isn't giving 
>> the application attention :-).
> 
> My proposal for notifications was to have them default to being just 
> inside the page (nothing that a <div> couldn't do), but that they would 
> include explicit UI to promote them to full-system notifications; and 
> vice-versa, so a system notification could be demoted back to just in-page 
> notification with a similar gesture.

possibly the interaction should not be with the system but the browser. this leaves any system-level integration in full control of the browser and restricts the specification to a single level of abstraction.

> On Tue, 3 May 2011, Cameron Heavon-Jones wrote:
>> 
>> The quantity of permission requests can be managed in an effective 
>> manner by the agent allowing the user to store their preferences for the 
>> next command or as a universal setting.
> 
> That doesn't work. It might be appropriate for Bing Maps to have access to 
> my Geolocation information, but I certainly don't want some random blog to 
> have access to it. Defaults don't work here.

the UI concept is that of user preference management, it can apply to permissions, confirmations, or any other user configurable setting.

there is no reason geolocation can't be managed in the same way. if i always want bing maps to have access to my location, it would be nice to be able to register that preference. for some random blog that always asks for my location, it would be nice to block it from asking again.

it's not defaults, but in-process persistent configuration.

>> For web applications to specify their required permissions would seem to 
>> introduce a duplication of specification. If a web application includes 
>> an image file upload which the user chooses to capture from webcam, 
>> first how is the application to know that the user would use a web cam?
> 
> There's no need for the app to know. It can just allow the user to upload 
> a photo, and the browser can offer to use the webcam.

indeed.

> I haven't added anythign to the spec in relation to this proposal.
> 

the proposal for a web app descriptor for implicit permissions would seem to be debunked, however the greater question of how to manage the explicit geolocation feature is both still open and an issue being encountered today. 

what concerns me is the interaction between web application\document and browser shell\chrome which is new territory. the concept of background web pages, introducing notification requirements, is also an area requiring active attention.

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

Thanks,
Cameron Jones



From cmhjones at gmail.com  Wed Jul 27 10:44:34 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Wed, 27 Jul 2011 18:44:34 +0100
Subject: [whatwg] Proposal for a web application descriptor
In-Reply-To: <43DCE7F1-AD1A-4587-A0BA-E61B9F2AA291@mozilla.com>
References: <4BBD6C50-9857-4976-B647-1B2D043023E5@simonheckmann.de>
	<B72B479C-CBE4-4382-ACE7-2DB9396735E8@4d.com>
	<5656C09D-4C7E-4FD2-A65D-D2607AF48F19@simonheckmann.de>
	<Pine.LNX.4.64.1107261949340.2079@ps20323.dreamhostps.com>
	<43DCE7F1-AD1A-4587-A0BA-E61B9F2AA291@mozilla.com>
Message-ID: <1A4DBE8E-BCA7-4325-9EBB-95ED91ADDFC3@gmail.com>


On 27/07/2011, at 5:30 PM, Mike Hanson wrote:
> The challenging use case, and one that we had trouble with when we prototyped the Contacts API, is for ongoing or persistent access.  The best approach we have right now is to use explicit markup to "sandbox" the permissions grant away from untrusted code.
> 
> In the Contacts case, for example, autocomplete of email addresses, names, and phone numbers was a desired use case.  A naive approach is to let the web app read the entire database and perform autocompletion in content.  The safe approach, which was harder and less flexible, is to attach autocomplete behavior to input type="tel" and "email", and to set the autocompleted value only when the user has selected it.

This is a sound approach, i'm not sure of the implementation complexities. 

The mapping of "tel" and "email" inputs to a contacts list is functional, not systematic. Might this be extended for some other inputs: date(*), url, search etc?

This functionality may be declared and defined through a new attribute, since autocomplete is already used, something like "autoassist"? 

Maybe this would be able to over-ride the default "file" input behaviour of launching a popup in the case i just want to manually enter a file:///

> 
> There are definite UX limitations to that approach - the content can't provide visual hinting during the autocomplete, for example (it would be nice if a photo gallery could trim down the set of photos from my friends as I narrow in on the name).  

This would seems to be ok as long as the contents remain sandboxed until selection is confirmed.

> The limitations create an incentive for content to try to get the full set of data anyway, through some other channel.  As Roc commented, finding a way to be comfortable with a higher-level permissions grant that persisted over a longer span could be one way to address that.

It would be nice for a page\site\app to still be able to access a full contacts list if desired. Though it would seem to extend the integration into the full Contacts API which is of far larger scope.

> --
> Michael Hanson, Mozilla Labs


Thanks,
Cameron Jones

From Simetrical+w3c at gmail.com  Wed Jul 27 12:24:15 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 27 Jul 2011 15:24:15 -0400
Subject: [whatwg] Nested list
In-Reply-To: <5a068af50907021505jd494b69n552f7ea68032c344@mail.gmail.com>
References: <5a068af50907021505jd494b69n552f7ea68032c344@mail.gmail.com>
Message-ID: <CAKA+Axmms6zTKNmSiYs+rFKyBh9KSpYPB+mPfwSPt-J360stEQ@mail.gmail.com>

(Ian pointed out this old thread to me that he hadn't yet responded
to, so I'll respond now.)

On Thu, Jul 2, 2009 at 6:05 PM, Ryosuke Niwa <rniwa at google.com> wrote:
> Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
> nested OL or UL without LI. ?See
> http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.2 ?In fact, the
> nested list example is marked deprecated. ?But in practice, all major
> user agents produce nested list when execCommand("Indent"...) is
> executed. ?Is there any chance we can?standardize?nested lists, and in
> particular, what UA produce?

I opened a bug about this a while ago:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12609

> For example, all?major?browsers (Firefox, IE, & WebKit)?produce
> slightly different?versions of HTML?when?indenting?"item?2"?in the
> following HTML (assume it's content-editable):
> <ol>
> <ol id="u1"><li id="i1">item 1</li></ol>
> <li id="i2">item 2</li>
> <ol id="u3"><li id="i3">item 3</li></ol>
> </ol>
>
> In particular, many UA remove arbitrary id attributes.

If you remove the whitespace nodes (which currently confuse my
algorithms in lots of places -- it's a known issue), it produces

<ol><ol id="u1"><li id="i1">item 1</li><li id="i2">ite[m] 2</li><li
id="i3">item 3</li></ol></ol>

according to my implementation.  This is because of the following
steps in the indent algorithm at the time of this writing:

* Let tag be the local name of the parent of first node.
* Wrap node list, with sibling criteria matching only HTML elements
with local name tag and new parent instructions returning the result
of calling createElement(tag) on the ownerDocument of first node.
http://aryeh.name/gitweb.cgi?p=editing;a=blob_plain;f=editing.html;hb=e4c523de#indent

Since the sibling criteria only require the sibling to have local name
tag (in this case "ol"), without regard to attributes, it's considered
valid for merging.  Since both the previous and next siblings match
the sibling criteria, the next sibling is merged into the previous
sibling, so the resulting element has the id of the original first
element.

Chrome 14 dev merges them but keeps the id of the second list, not the
first.  Firefox 7.0a2 merges into the second list, and ignores the
first list even if it has no id -- it seems to ignore previous
siblings if there's a legitimate next sibling.  Opera 11.50 gives the
same output as the spec.  IE10PP2 merges the three items into one list
that has no id at all.  I think that the spec (= Opera) is reasonable
here -- anyone disagree?

I added a few tests to my test suite based on this feedback:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=d4233f8f

On Mon, Jul 13, 2009 at 7:01 AM, Simon Pieters <simonp at opera.com> wrote:
> I think this is a bug in execCommand('indent') and should be fixed in
> browsers.

I disagree.  I found when writing my spec that having <ol>/<ul> nested
inside <li> complicates a lot of things needlessly, because the
<ol>/<ul> is visually part of the parent <ol>/<ul> and not the <li>.
I wound up aggressively normalizing list items so that if they contain
<ol> or <ul>, those are broken out to become siblings in any case
where it might cause problems:

http://aryeh.name/gitweb.cgi?p=editing;a=blob_plain;f=editing.html;hb=e4c523de#normalize-sublists

I don't see that this has any semantic problem.  We can simply define
the semantics of <ol><li>foo</li><ol><li>bar</ol></ol> as being the
same as those of <ol><li>foo<ol><li>bar</ol></ol>.

On Thu, Sep 3, 2009 at 8:29 PM, Ian Hickson <ian at hixie.ch> wrote:
> There are lots of bugs that need fixing with execCommand(); I don't see
> why this wouldn't be one of them.

I've considered the issue carefully and determined that it's HTML5's
authoring requirements that should change here, not browsers'
execCommand() behavior.  Basically, to avoid extra branching, we want
to ensure that all nested lists we deal with are consistent, either
all nested directly or all nested inside <li>'s.  Having them nested
directly makes things simpler.

For instance, suppose you have markup like
<ol><li>foo<ol><li>bar</ol>baz</ol> and the user outdents the middle
item.  This needs to be a special case: you have to notice that you're
a descendant of an <li>, break that into two, and stick the <ol> in
between.  If you first normalize and make the markup look like
<ol><li>foo</li><ol><li>bar</ol><li>baz</ol>, outdenting the middle
item can completely ignore the outer list with no need for a special
case.

Or take another case: consider the markup,
<ol><li>foo<li>bar<ol><li>baz</ol></ol>, and have the user select
"bar" and try to indent it.  It looks like "baz" is a separate item,
so the user will expect it not to get indented along with "bar".  This
means you need to do a bunch of complicated stuff: first you need to
look for a previous list item to move things into ("foo" in this
case), then check if there's already an <ol> at the end of it, merge
into that <ol> if so, otherwise create a new <ol>, move the whole <li>
containing "barbaz" into the new <ol>, move the "baz" <li> out of its
<ol>, remove that.  Or something like that.  If I first normalize to
<ol><li>foo<li>bar</li><ol><li>baz</ol></ol>, I can wrap the bar <li>
with no extra work at all, reusing my "wrap" algorithm that checks for
siblings that match given criteria and creates a new wrapper if none
are found.

There are lots of cases like this.  Often if a list is directly nested
inside another list without an intervening <li>, you can treat it
either like a non-nested list or like an <li>.  I found that not
normalizing lists to be directly nested just created pointless
headaches for no gain.  There's no obstacle to us defining new
semantics in this case and making it valid.


From Simetrical+w3c at gmail.com  Wed Jul 27 12:36:09 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 27 Jul 2011 15:36:09 -0400
Subject: [whatwg] [editing] Proposal: Undeletable elements within
	contentEditable
In-Reply-To: <490014A7-1BFC-4FD1-8737-9FDDF02EC741@elv1s.ru>
References: <490014A7-1BFC-4FD1-8737-9FDDF02EC741@elv1s.ru>
Message-ID: <CAKA+AxkjpvNt6VKPMVem2S3xkmEyy5vPXdS1JB2KbUTDhnxNWA@mail.gmail.com>

(Responding to some old feedback on editing from before I started work
on it, which Hixie sent me.)

On Thu, Jun 24, 2010 at 12:08 PM, Nikita Vasilyev <me at elv1s.ru> wrote:
> The current version of spec
> http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable
> does not define any way to make an element within contentEditable
> undeletable. I propose "undeletable" attribute:
>
> element.undeletable = "true" | "false"
>
> How should it work:
>
> <div contenteditable>
> ?<span undeletable>foo</span>
> </div>
>
> When I focus on the div, select all the text, and delete it, the span
> element MUST be empty, but MUST NOT be deleted.
>
> This behavior would be very useful while building code editors. I'm building
> CSS editor with syntax highlighting and auto-completion based on
> contentEditable. "undeletable" attribute would help me a lot.

I'm very reluctant to add such things, because it adds corner cases
that vastly complicate processing and allow tons more room for bugs.
It means every single algorithm related to editing needs to be aware
of the attribute and check for it before deleting anything.  This is
already a big headache for contenteditable=false, which has tons of
bugs in my algorithms and in browsers that I haven't even tried fixing
systematically yet.

Also, I don't know what use it would be to have the empty wrapper
element hanging around.  I've designed the editing algorithms to avoid
leaving such things: the user can never focus them, typically, so they
don't do much unless you're adding weird styles or such.

If you really wanted this effect, though, I think <span
contenteditable=true> should in theory do what you want.  I've been
designing my spec's algorithms based on the premise that an editing
host should never be deleted or have its attributes modified, but it
can be moved around if it's inside another editing host.  There are
probably loads of bugs in the spec, as I said, and browsers have a
very different view of how things should work in practice, but that's
my goal.

I haven't given a lot of thought to nested editing hosts or nested
non-editable content, though.  I'm not sure what the use-cases are.
It would help a lot if you could explain exactly what you want this
for.

2010/6/24 Joseph Thomas <jthoma12 at calpoly.edu>:
> It seems like the ideal way to handle this would be to handle the
> MutationEvent (and cancel it, but unfortunately they are
> non-cancelable. Perhaps a set of cancelable events, i.e.
> UserMutationEvent.
>
> ( see http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents
> )

Mutation events are a massive headache and we're trying to get rid of
them, so this isn't a feasible long-term suggestion.  See the very
long recent thread on the public-webapps list on this subject.


From ian at hixie.ch  Wed Jul 27 13:37:33 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 27 Jul 2011 20:37:33 +0000 (UTC)
Subject: [whatwg] Why deflate-stream is required to be enabled by the
 WebSocket API?
In-Reply-To: <CABLsOLA0z-+Z4McW8LH2ziZm-o-x8CcPe=_95msWFGyVyiuvGA@mail.gmail.com>
References: <CAH9hSJbb21hXAo+hYE8Vb8boromqXB4g_G-u+e=V+z+=yAaL7Q@mail.gmail.com>
	<o27e27dud46p02bksugedm3cimsvt7pbt3@hive.bjoern.hoehrmann.de>
	<CAJE5ia9aa0+tot0KUCirbSaSna11hNChknQMw0U8k5L+a33bqQ@mail.gmail.com>
	<CABLsOLA0z-+Z4McW8LH2ziZm-o-x8CcPe=_95msWFGyVyiuvGA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107272031190.2079@ps20323.dreamhostps.com>

On Tue, 19 Jul 2011, Takeshi Yoshino wrote:
> 
> Use of deflate-stream is now mandatory in API spec. I think this kind of 
> requirement is useless. How about leave it up to implementors' decision? 

Well we don't want optional features, so it's either in or out.


> I think this requirement doesn't really help us enforce endpoints
> initiate/accept WebSocket with the same configuration. Because
> 
> - non-browser UAs are free to be implemented without deflate-stream

Non-browser clients of Web Sockets are going to be comparatively rare and 
will not have the market power to affect de-facto requirements. So for 
the purpose of the API, they are irrelevant.


> - server developers would see/care only the wire protocol spec

Server developers are only going to care about what browsers need, not 
what specs say.


> So, server developers would simply make their implementation accept both 
> requests with and without deflate-stream, I think.

It's fine if they do.

We just need to make sure they don't require it to be supported, or 
require it to not be supported, and thus force us into one or the other. 
The simplest way to prevent that is to make sure all the browsers act the 
same.


> It's not likely that server implementors are influenced by "the 
> WebSocket API" and have their server check if a UA is browser or not and 
> reject requests w/o deflate-stream.

Not intentionally, maybe, but it is most definitely going to happen.


> The only people who benefit from this requirement is those who implement 
> a server only for their own use and are not interested in serving 
> non-browser clients.

That will likely be the majority of implementors.


On Wed, 20 Jul 2011, Bjoern Hoehrmann wrote:
> 
> The deflate-stream extension, when used for browser to server messages 
> allows an attacker to put whatever bytes he likes on the wire, after a 
> bit of unpredictable junk. Browser vendors were pretty opposed to that 
> for the normal protocol without extensions, and they were opposed to 
> having some way to make browsers send messages "unmasked"; so it would 
> be very odd for browser vendors to implement the extension. And by the 
> looks of it, the hybi Working Group may well drop deflate-stream now. 
> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html> 
> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.

I've changed the spec to make the extension disallowed rather than 
required.

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


From Simetrical+w3c at gmail.com  Wed Jul 27 13:47:43 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 27 Jul 2011 16:47:43 -0400
Subject: [whatwg] DOM Range Deletions
In-Reply-To: <4C175B5C.2050106@ado.is-a-geek.net>
References: <4C175B5C.2050106@ado.is-a-geek.net>
Message-ID: <CAKA+AxmEFbW8USpnvkyD+i5ZdJexskHVheg7w4976vpW7PG8Hg@mail.gmail.com>

(answering some old feedback on DOM Range that Hixie pointed me to)

On Tue, Jun 15, 2010 at 6:52 AM, Andrew Oakley <andrew at ado.is-a-geek.net> wrote:
> I've been trying to implement DOM Range but can't work out how ranges
> are supposed to work under mutation.

This should now be more or less fully defined in the DOM Range spec,
with a pretty decent test suite:

http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation

I wrote up the new definitions a couple of months ago.  They aim to be
both precise and compatible with browser behavior, which means they
mostly match DOM 2 Range but differ in some respects.

> In the following examples I use *this* to indicate a range being deleted
> and slashes to indicate another range.
>
>
> Section 2.6 - Deleting Content with a Range gives the example of
>
> <FOO>X*Y<BAR>Z*W</BAR>Q</FOO> -> <FOO>X^<BAR>W</BAR>Q</FOO>
>
>
> Section 2.12.2 - Deletions says:
>
> "If a boundary-point of the original Range is within the content being
> deleted, then after the deletion it will be at the same position as the
> resulting boundary-point of the (now collapsed) Range used to delete the
> contents."

This is not what browsers do, and not what the new DOM Range spec
requires.  DOM 2 Range treats deletions as deletions of ranges, but
browsers and DOM Range both treat deletions as node-by-node.
deleteContents() specially modifies the range you call it on so that
it's always collapsed, as is defined in detail:

http://html5.org/specs/dom-range.html#dom-range-deletecontents

Note how the last step is "Set the context object's start and end to
(new node, new offset)", so the range you call the method on is
changed differently from other ranges.

If you have a range <FOO>X[Y<BAR>Z]W</BAR>Q</FOO> (using [] to denote
the endpoints), then the algorithm works as follows:

* "If original start node is an ancestor container of original end
node, set new node to original start node and new offset to original
start offset."  Original start node here is the Text node "XY", and
original end node is the Text node "ZW".  The former is neither equal
to nor an ancestor of the latter, so this doesn't apply, and we go to
the other branch.

* "Let reference node equal original start node."  So reference node
is now the Text node "XY".

* "While reference node's parent is not null and is not an ancestor
container of original end node, set reference node to its parent."
Reference node's parent is <FOO>, which is not null, but is an
ancestor container of original end node.  Thus we do nothing in this
step.

* "Set new node to the parent of reference node, and new offset to one
plus the index of reference node."  Thus new node is <FOO>, and new
offset is 1.

So the Range you delete will eventually collapse to
<FOO>X{}<BAR>W</BAR>Q</FOO>.  Note that here I use curly braces
instead of brackets, to indicate that the endpoint of the Range is in
an Element node, not a Text node.  The old DOM 2 Range standard is
unclear on that point, but my spec matches what browsers do.

> We then have the example of:
>
> <P>ABCD *efgh The <EM>R*ange</EM> ijkl</P>
> ? ? ? ? ? ? ?/ ? ? ? ? ? ?\
>
> Goes to
>
> <P>ABCD <EM>ange</EM> ijkl</P>
> ? ? ? ? ? / ? ?\

In the syntax I'm using, that's: <P>ABCD [efgh T[[he <EM>R]ange]]</EM>
ijkl</P>, where I use single brackets for the range being deleted and
double brackets for the other, for lack of better syntax.

The new specification uses entirely different rules when the Range
being deleted is different from the one being modified, as I noted.
The deletion is treated as a sequence of separate mutations of
individual nodes.  In this case, deleteContents() will do the
following:

1) Call deleteData() on the Text node "ABCD efgh The ", with offset 5
and count 9.  This deletes "efgh The " and leaves only "ABCD ".
Current DOM Core defines this as replacing data with offset 5, count
9, and data "", so we look at the "When something replaces data of a
CharacterData node" case at
<http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation>.

The first boundary point of the [[ range has offset 11, and 5 < 11 <=
5 + 9, so we hit the case "For every boundary point whose node is
node, and whose offset is greater than offset but less than or equal
to offset plus count, set its offset to offset."  Thus the offset is
set to offset, i.e., 5.  This gives us:

<P>ABCD [[<EM>Range]]</EM> ijkl</P>

2) Call deleteData() on the Text node "Range", with offset 0 and count
1.  This deletes "R" and leaves "ange".  We're replacing data with
offset 0, count 1, and data "", and the second boundary point of the
]] range has offset 5, and 5 > 0 + 1, so we hit the case "For every
boundary point whose node is node, and whose offset is greater than
offset plus count, add the length of data to its offset, then subtract
count from it."  The length of data is 0 and count is 1, so we set the
new offset to 5 + 0 - 1 = 4.  This gives us:

<P>ABCD [[<EM>ange]]</EM> ijkl</P>

The example in DOM 2 Range implies something more like <P>ABCD
<EM>[[ange]]</EM> ijkl</P>.  I agree this is wrong according to DOM 2
Range itself.  DOM 2 Range is a decent spec for its time, but we've
moved to much greater levels of precision these days.  One thing it
often does is not clearly distinguishing boundary points that "look"
the same, in that no nodes or characters lie between them.

> I assume that the range indicated by the underline in the spec and like
> *this* here collapses to just before the <EM> tag as this document has
> the same structure as the other example I pulled out of the spec. ?This
> would mean that the start point of the other range should also be just
> before the <EM>, but that isn't what has happened in this example.

The example is buggy, yes.  The starting <EM> tag should be
highlighted according to both specs and according to browser behavior.

> Any idea what I've got wrong? ?Some browsers (e.g. Safari) seem to
> behave as in the example, others (e.g. Firefox) put the end point before
> the <EM> (as I would have expected).

Here's a test case:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1086

Firefox 7.0a2, Chrome 14 dev, and Opera 11.50 all log "ABCD", "5",
"ange", "4", which matches my spec.  IE10PP2 logs "ABCD", "5",
"undefined", "1".  The "undefined" winds up being because it puts the
new endpoint in the <em> with offset 1, instead of in the Text node
"ange" with offset 4.  IE might or might not be able to argue that
it's correct per DOM 2 Range, but it's not correct according to the
new spec.

I have a reasonably comprehensive test suite for range mutation
behavior, by the way:

http://aryeh.name/spec/dom-range/test/Range-mutations.html

It only tests what happens with basic DOM operations like replaceData,
though, it doesn't check if things like Range.deleteContents do any
additional magic.


From timdown at gmail.com  Wed Jul 27 15:55:04 2011
From: timdown at gmail.com (Tim Down)
Date: Wed, 27 Jul 2011 23:55:04 +0100
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
	<CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
	<CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>
Message-ID: <CAOYSAj0xN-ZnzSB0ogkks-NPM4-R4Y-XHV63ySkZBuoLVA8+hA@mail.gmail.com>

On 21 July 2011 20:59, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Wed, Jul 20, 2011 at 6:23 PM, Tim Down <timdown at gmail.com> wrote:
>> Yes, but it's significantly better than the alternative, which is to
>> write your own code to search for text that spans nodes.
>
> It shouldn't be *too* hard to write that code. ?First do the search in
> textContent and get a list of the offsets of all the results. ?Then
> get a list of Text nodes, and iterate through them. ?Record the sum of
> their lengths as you go, and when you get to the right place, store
> the result. ?I'd guess it would be 20 lines or so. ?Something like
> this (untested):
>
> function findStrings(root, search) {
> ? ?var offsets = [];
> ? ?for (var i = root.textContent.indexOf(search); i != -1; i =
> root.textContent.indexOf(search, i + 1)) {
> ? ? ? ?offsets.push(i);
> ? ?}
> ? ?var results = [];
> ? ?var treeWalker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT);
> ? ?var currentOffset = 0;
> ? ?while (treeWalker.nextNode()) {
> ? ? ? ?while (offsets.length
> ? ? ? ?&& currentOffset <= offsets[offsets.length - 1]
> ? ? ? ?&& offsets[offsets.length - 1] < currentOffset +
> treeWalker.currentNode.length) {
> ? ? ? ? ? ?results.push([treeWalker.currentNode,
> offsets[offsets.length - 1] - currentOffset]);
> ? ? ? ? ? ?offsets.pop();
> ? ? ? ?}
> ? ? ? ?currentOffset += treeWalker.currentNode.length;
> ? ?}
> ? ?return results;
> }
>
> Probably buggy, but something like that should work. ?(And hey, it's
> 19 lines, good guesswork.) ?Granted, if you wanted to do any kind of
> normalization it would be more complicated to author, but also more
> complicated to spec. ?So I don't see really a use-case here that's
> strong enough to justify this, if we can get rid of it.

There's also the perennial problem of dealing with non-visible text
(c.f. Selection.toString(), innerText), which some browsers handle (a
quick tests suggests WebKit searches non-visible text and Firefox
doesn't). Also, don't forget that you're in the habit of writing this
sort of code. Knocking that kind of code out quickly is beyond what a
large percentage of web developers are capable of.


>> Agreed. My number two feature (well, it would make the top 5, at
>> least) would be removing the restriction on execCommand() only working
>> on editable content. This very use case shows that its usefulness
>> extends beyond editable content. The temporarily-switch-designMode-on
>> workaround is ugly, and destroys the selection in some browsers.
>
> As I said elsewhere, I disagree. ?Wanting to only modify editable
> content is an important use-case. ?It's easy to emulate the behavior
> you want if that restriction is in place (temporarily turn on
> designMode), but nearly impossible to emulate the opposite behavior if
> it's not built in to start with. ?If execCommand() worked on any
> content at all, then text editors would be permanently forced to use
> iframes with designMode instead of being able to use contenteditable,
> just to avoid the user randomly bolding or deleting interface text.
> Also, it would mean that (for instance) execCommand("delete") works
> differently from the backspace key.
>
> If turning designMode on destroys the selection in some browsers,
> that's a bug that can easily be fixed, and doesn't justify a change to
> the spec. ?Changing specs to work around easily-fixed browser bugs
> makes much less sense than just fixing the bugs. ?The only
> disadvantage I see to requiring this is that it's error-prone: the
> obvious way to do it is to turn designMode on and then turn it off,
> which will have an unexpected side effect if it had already been on.
> But that's a minor issue, and I don't see a good way to avoid it.
>
> Why exactly do you not want to turn designMode on and off, other than
> easily-fixed browser bugs? ?What do you think is "ugly" about it?

I absolutely agree that restricting mutation to editable content is
important. My issues with using designMode are a combination of side
effects and implementation quirks in current and older browsers, which
I agree doesn't justify a change to the spec, and a gut feeling that
it's the wrong approach. There is no reason why your algorithms can't
work on non-editable nodes, so why require the user to change such a
fundamental property of the DOM (even temporarily)? I'd prefer an
alternative mechanism for specifying whether a command should apply to
only editable content that is part of the editing API. In my
execCommand implementation, it's specified as a property of an options
object passed to execCommand(). If that's not an option, another
command could be used, similar to the styleWithCSS command, to switch
between modes. applyToNonEditable, or something.

Tim


From ian at hixie.ch  Wed Jul 27 16:38:47 2011
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 27 Jul 2011 23:38:47 +0000 (UTC)
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <BANLkTikmAr2GZZMYEXj3rjQfQS=1OuzwTA@mail.gmail.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>
	<4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
	<AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com>
	<4bf304a4.513dd80a.189a.1578@mx.google.com>
	<AANLkTimYMfwCc-FZqLSpIv2rqVD1Vvljazsh6Btobvzr@mail.gmail.com>
	<AANLkTim1o2OgWVyrIjQXcFpWSNe_2Rujf8SXSSq31H8S@mail.gmail.com>
	<4bf3ec37.e198d80a.29a8.380e@mx.google.com>
	<Pine.LNX.4.64.1008032356060.7470@ps20323.dreamhostps.com>
	<4c5a2147.d908e30a.2998.6700@mx.google.com>
	<Pine.LNX.4.64.1008261714270.3392@ps20323.dreamhostps.com>
	<AANLkTimxi8OwZ_Px1c-rFpXbvS36H3OTWxS2wKERdkNK@mail.gmail.com>
	<Pine.LNX.4.64.1012072350120.26618@ps20323.dreamhostps.com>
	<AANLkTi=WJa9vLK7k23ROFsRxfSZO1yYS_g7sUdECqJ58@mail.gmail.com>
	<Pine.LNX.4.64.1104282129150.19153@ps20323.dreamhostps.com>
	<BANLkTimk9_0GEyxaTTH5TTO1m_C5eLg5XA@mail.gmail.com>
	<Pine.LNX.4.64.1104282212170.25791@ps20323.dreamhostps.com>
	<BANLkTikmAr2GZZMYEXj3rjQfQS=1OuzwTA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107272332230.2079@ps20323.dreamhostps.com>

On Fri, 29 Apr 2011, Bjartur Thorlacius wrote:
> On 4/28/11, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 28 Apr 2011, Bjartur Thorlacius wrote:
> >> All current UAs would understand the link (and most probably present it
> >> to the user). Inline presentation is an optional luxury: the important
> >> thing is getting the media across. I, for one, can't find any sign of
> >> <source> support in wget, and a few other "non-mainstream" UAs.
> >
> > Well for <video> fallback people are likely to use <a> as well, but I
> > don't think it makes sense to force every <source> to be a link.
>
> Writing both <source> and <a> for every source seems like unnecessary
> duplication to me. The primary difference between the two is that the
> resource referenced by the former is to be displayed inline, but the
> resource referenced by the latter is to be accessible interactively.
> <a style="content: url(attr(href));" href="/usr/videos/lolcatz">Funny
> cats jumping around</a>.
> Ok, this isn't valid CSS, but you get my thinking (I hope).

While I can see where you're coming from, I don't think overloading one 
element for all hyperlink and resource link features makes sense. 
Different links have different needs. The incremental cost of adding new 
ways to get resources in wget(1) is much lower than the cost of 
overloading all the various linking mechanisms into one element, IMHO.

It is, in any case, too late for <video>. However, I will keep in mind 
what you have said for future features.

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


From rniwa at webkit.org  Wed Jul 27 16:51:31 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Wed, 27 Jul 2011 16:51:31 -0700
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
Message-ID: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>

Feedback on  sections 1 through 3:

   - WebKit treats any font-weight above or equal to 600 as bold because
   that's what user sees, and boldness is a binary concept in execCommand;
   Firefox 5 appears to do the same.
   - WebKit compares colors in rgb/rgba format; e.g. red is first parsed as
   rgb(255, 0, 0).  Firefox 5 seems to does the same as well.
   - WebKit compares font sizes in legacy font size used in font element;
   See CSSStyleSelector::legacyFontSize or legacyFontSizeFromCSSValue in
   EditingStyle.cpp
   - Throwing SYNTAX_ERR might cause a backward compatibility issue because
   the UAs don't throw an error now.  We can probably throwing console messages
   first to give authors some grace period to transition.
   - For font element vs. span with style issue, we could add another
   boolean flag that forces UAs to toggle font-element; i.e. add StyleWithFont
   command.
   - 3.2: Prefix "webkit-" doesn't seem natural given all editing commands
   use Camel case.  Maybe Ms, Gecko, WebKit and Opera?  e.g.
   WebKitFontSizeDelta.  But again this might cause a backward compatibility
   because we do implement few editing commands that are not in the spec and
   they are not prefixed.
   - 3.3: The return value of queryCommandEnable depends on beforecut,
   beforecopy, and beforepaste events and selection state in WebKit; WebKit
   returns false if default actions are prevented in those events or selection
   is not a range.  Firefox 5 appears to do the same for selection but doesn't
   seem to fire beforecut, beforecopy, and beforepaste.

- Ryosuke

On Tue, Jul 26, 2011 at 2:26 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> Since February, I've been working on writing a detailed specification
> for browser editing, primarily the document.execCommand() and
> document.queryCommand*() methods.  These were created by Microsoft in
> the 1990s and were subsequently adopted in some form by all other
> browsers, and today browsers have to implement them to be compatible
> with web content, but no detailed specification ever existed.
> Interoperability is practically nonexistent as a result, which has
> driven all major content editing frameworks away from using
> execCommand().  Hopefully we can start to fix that and make these APIs
> a part of the web platform that just works.
>
> The current version of the specification is at
> <http://aryeh.name/spec/editing/editing.html>.  It's about fifty pages
> printed, and supersedes the Editing APIs section of HTML
> <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis
> >
> (which is more like two pages).  In the style of modern web specs, it
> is phrased in terms of algorithms that attempt to cover all corner
> cases unambiguously and leave no behavior undefined, and it tries to
> match the behavior of existing browsers to the greatest extent
> possible.  At this point, it's stable and complete enough that I
> believe it's ready for serious review by implementers, and I would
> like as much detailed feedback as possible.
>
> There is a basically complete JavaScript implementation, which is used
> to produce expected results for a largely undocumented and entirely ad
> hoc test suite:
> <http://aryeh.name/spec/editing/autoimplementation.html>.  I used the
> tests as an aid to writing the spec, and they probably aren't well
> suited to aid implementers in implementing it.  I will probably get
> around to porting them to something like testharness.js at some point.
>  I haven't tried testing my implementation on real-world sites, only
> on artificial input, so I don't know at this point how implementable
> it really is, but the JS implementation means that it at least has
> large parts that make sense.
>
> Anyone reviewing the spec should be advised that I put extensive
> rationale in HTML comments.  If you want to know why the spec says
> what it does, check the HTML source.  I plan to change this to use
> <details> or such in the near future.  There are lots of minor known
> issues still left, but none that I thought was important enough that
> it needs to delay review.  Feedback can be sent to the whatwg list,
> CCing me, with [editing] in the subject.  (I'm also fine receiving
> feedback on public-html or public-webapps, but I don't know if the
> chairs would be okay with that, since it's off-topic.)  I should be
> available to respond to all feedback promptly at least through the end
> of August.  After that, I can't make specific guarantees about my
> availability, but I do plan to continue maintaining the spec in the
> long term.
>
> I've CCd or BCCd everyone who's commented on or contributed to this
> spec at some point.
>


From ian at hixie.ch  Wed Jul 27 17:21:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 28 Jul 2011 00:21:10 +0000 (UTC)
Subject: [whatwg] Form element invalid message
In-Reply-To: <BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>

On Fri, 29 Apr 2011, Jonas Sicking wrote:
> On Fri, Apr 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 29 Dec 2010, Mounir Lamouri wrote:
> >> On 12/29/2010 07:41 AM, Ian Hickson wrote:
> >> >>
> >> >> I actually think that the customerrormessage attribute that has 
> >> >> been suggested is a decent solution too. [...]
> 
> For example, if I go to www.google.com and click on the "sign in" link 
> at the top, then without entering anything press the "sign in" button. 
> At this point the page displays a error message in red that says "Enter 
> your email address." [...]
> 
> In general it makes a lot of sense to want to display a different 
> message when the user has failed to enter a valid value in a field. 
> Clearly the user failed to enter what was requested the first time, and 
> so the context around the field was not enough for the user to enter 
> what was requested. Hence a more detailed description is appropriate.
> >
> > I don't understand how such an attribute would work. Take <input 
> > type=number> for example, with an explicit min, max, step, etc. How 
> > would you know what value to put in the attribute? There are going to 
> > be different needs when the control's value is too low, too high, not 
> > aligned to a step, missing, etc.
> 
> Consider the example above from googles login page. Here there are two 
> possible errors:
> 
> 1. The field is empty
> 2. The field doesn't contain an email address
> 
> In both cases the message "Enter your email address." seems appropriate. 
> And it seems better than what we as a browser could generate.

A text input field could have a number of error conditions:

   <label> Offer code:
    <input type=text maxlength=8 pattern="[a-z1-9]+" required>
   </label>

Suppose the code is printed as two groups of four characters, for example 
something like "1A2B 3C4D".

The user could have entered the code with the space (the site doesn't want 
the space). Or the user could have read an O as a 0 (the code never has 
any zeroes to avoid that). Or the user could have forgotten to enter the 
code. In each of these cases, I think you'd want a different message.


Anyway. I guess we can have a dedicated attribute that user agents can use 
to provide a message, rather than the current solution of just using the 
title="" attribute for pattern=""'s error message. If it's present, user 
agents could use it to replace or augment their message, and authors could 
make the message more specific by dynamically changing the attribute when 
during the 'invalid' event handler.

   <label> Offer code:
    <input type=text maxlength=8 pattern="[a-z1-9]+" required
           oninput="setCustomValidity(input.match(/0/) ?
                    'Codes contain no zeroes, only Os.' : '')"
           validitymessage="Enter the code without spaces.">
   </label>


If we add this, do you think it should be displayed with, instead of, or 
replaced by the setCustomValidity() message, when both are given?

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


From ajvincent at gmail.com  Wed Jul 27 20:34:59 2011
From: ajvincent at gmail.com (Alex Vincent)
Date: Wed, 27 Jul 2011 20:34:59 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Message-ID: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>

>
> In the last couple of weeks, I've been working with developers of CKEditor,
> TinyMCE, and Google Docs to come up with *new API for undo and redo*.
>

I'd like to take a look at this and be very closely involved in this
specification.  About a month ago, I wrote this:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031191.html

I've been working on my own prototype editor project for years (it may
replace Duke Nukem Forever as king of vaporware at the rate I'm going, but
I'm still working on it), and I've had some definite thoughts on undo
management.  API's like this interest me quite a bit.

Also see https://bugzilla.mozilla.org/show_bug.cgi?id=617532 - where Mozilla
is considering their own API proposals.

One use case I've envisioned is an undo popup menu, where each item of the
undo stack has an actual label to go with it, describing the transaction.
Then you could easily see how many items you wanted to go back!

I'd be happy to take this off-list, or keep it on-list, whatever you prefer.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From jkorpela at cs.tut.fi  Wed Jul 27 20:37:09 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 28 Jul 2011 06:37:09 +0300
Subject: [whatwg] Form element invalid message
In-Reply-To: <Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
Message-ID: <4E30D965.6000704@cs.tut.fi>

28.07.2011 03:21, Ian Hickson wrote:

> A text input field could have a number of error conditions:

Indeed. Therefore it would be essential to be able to set the error 
message for _each_ check that a browser is supposed to do on the basis 
of HTML markup alone. If this is not possible, it is easier to authors 
to code all data checking in JavaScript. Setting the error messages is 
important both for context dependency and for localization (using the 
language of the browser's UI would be odd when it differs from the 
language of the page - if the page is in Greek and the instructions 
there are in Greek, I would expect the messages of the data error to be 
Greek, even when my browser speaks Hebrew).

> I guess we can have a dedicated attribute that user agents can use
> to provide a message, rather than the current solution of just using the
> title="" attribute for pattern=""'s error message.

The title="" attribute is generally supposed to contain an advisory 
title for an element, and deviating from this that way is very odd and 
confusing - especially since user agents may show its value in a tooltip 
or speak it out when entering the field.

A dedicated attribute is much better. In particular, it does not 
interfere with the existing use of existing attributes.

> If it's present, user
> agents could use it to replace or augment their message, and authors could
> make the message more specific by dynamically changing the attribute when
> during the 'invalid' event handler.
>
>     <label>  Offer code:
>      <input type=text maxlength=8 pattern="[a-z1-9]+" required
>             oninput="setCustomValidity(input.match(/0/) ?
>                      'Codes contain no zeroes, only Os.' : '')"
>             validitymessage="Enter the code without spaces.">
>     </label>

It would be more logical and descriptive to call it errormessage rather 
than validitymessage.

But the main problem is that attributes like maxlength, pattern, and 
required are supposed to provide some data validation in a simple manner 
that does not need to involve JavaScript and works even when it is 
disabled. To make them useful, it should be possible to set the error 
message for each of them separately in HTML.

I have no better solution than to use separate attributes, like 
maxlengtherror, patternerror, requirederror. This doesn't sound cool, 
but it would work and would be useful.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From rniwa at webkit.org  Wed Jul 27 21:54:06 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Wed, 27 Jul 2011 21:54:06 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>
References: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>
Message-ID: <CABNRm609JSHpx-N_DyUg8J_0ak-boM5bk2U0mj6sCq__OaeAFQ@mail.gmail.com>

On Wed, Jul 27, 2011 at 8:34 PM, Alex Vincent <ajvincent at gmail.com> wrote:
>
> I'd like to take a look at this and be very closely involved in this
> specification.  About a month ago, I wrote this:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031191.html


Oh, yes.  I do remember your post!  I think my proposal address most of your
concerns.

Also see https://bugzilla.mozilla.org/show_bug.cgi?id=617532 - where Mozilla
> is considering their own API proposals.
>

Jonas' last proposal is very similar to the one I proposed except there are
two types of transactions in my proposal - ManualTransaction and
ManagedTransaction.  The rationale for having two types of transactions is
to let the Web app pick whether UA or script should implement undo/redo.

One use case I've envisioned is an undo popup menu, where each item of the
> undo stack has an actual label to go with it, describing the transaction.
> Then you could easily see how many items you wanted to go back!
>

My proposal addresses this use case.  See "label" property on
AbstractTransaction.

- Ryosuke


From rniwa at webkit.org  Wed Jul 27 22:32:49 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Wed, 27 Jul 2011 22:32:49 -0700
Subject: [whatwg] [editing] Proposal: Undeletable elements within
	contentEditable
In-Reply-To: <CAKA+AxkjpvNt6VKPMVem2S3xkmEyy5vPXdS1JB2KbUTDhnxNWA@mail.gmail.com>
References: <490014A7-1BFC-4FD1-8737-9FDDF02EC741@elv1s.ru>
	<CAKA+AxkjpvNt6VKPMVem2S3xkmEyy5vPXdS1JB2KbUTDhnxNWA@mail.gmail.com>
Message-ID: <CABNRm60Xfs_oNriuJwN_FGK6_HeGjyqGaywjE7r4jvNO=KzDzA@mail.gmail.com>

On Wed, Jul 27, 2011 at 12:36 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> I'm very reluctant to add such things, because it adds corner cases
> that vastly complicate processing and allow tons more room for bugs.
> It means every single algorithm related to editing needs to be aware
> of the attribute and check for it before deleting anything.  This is
> already a big headache for contenteditable=false, which has tons of
> bugs in my algorithms and in browsers that I haven't even tried fixing
> systematically yet.
>

I concur with Aryeh here.  I would be strongly against adding such a feature
unless it's absolutely required to address some use case.  User agents are
barely coping with nested editability now and adding another layer of
complexity is very undesirable.

- Ryosuke


From hsivonen at iki.fi  Wed Jul 27 23:37:56 2011
From: hsivonen at iki.fi (Henri Sivonen)
Date: Thu, 28 Jul 2011 09:37:56 +0300
Subject: [whatwg] date meta-tag invalid
In-Reply-To: <CA547099.10D90%aykut.sensoy@bild.de>
References: <CA547099.10D90%aykut.sensoy@bild.de>
Message-ID: <1311835076.2473.15.camel@shuttle>

On Tue, 2011-07-26 at 11:27 +0000, aykut.sensoy at bild.de wrote:
> http://www.google.com/support/news_pub/bin/answer.py?answer=93994
> 
> See Link above, Google says, that they provide "DC.date.issued", but this
> is also not part auf the whatwg metaextensions list.

It's part of the list now.

I wonder what possessed the Google News team to use dc.date.issued
instead of dc.issued or dcterms.issued.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From stefan.lk.hakansson at ericsson.com  Wed Jul 27 23:59:42 2011
From: stefan.lk.hakansson at ericsson.com (=?iso-8859-1?Q?Stefan_H=E5kansson_LK?=)
Date: Thu, 28 Jul 2011 08:59:42 +0200
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),
	and other feedback
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D616C389F15E@ESESSCMS0362.eemea.ericsson.se>

>On Tue, Jul 26, 2011 at 07:30, Ian Hickson <ian at hixie.ch> wrote:
>>
>>
>> > If you send two MediaStream objects constructed from the same
>> > LocalMediaStream over a PeerConnection there needs to be a way to
>> > separate them on the receiving side.
>>
>> What's the use case for sending the same feed twice?
>>
>
>There's no proper use case as such but the spec allows this.
The question is how serious a problem this is. If you want to fork, and make both (all) versions available at the peer, would you not transmit the full stream and fork at the receiving end for efficiency reasons? And if you really want to fork at the sender, one way to separate them is to use one PeerConnection per fork.

Stefan

From rniwa at webkit.org  Thu Jul 28 00:38:46 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Thu, 28 Jul 2011 00:38:46 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CAEZ8442askS4tPSjfMwM9pScEjiffKSODAWAh5mCb7D1kfpHXg@mail.gmail.com>
References: <CAEZ8443cznaHfDHd8gfYJu4g6S1GvDsH2HzmwumLit9_vPegZA@mail.gmail.com>
	<CABNRm60cFn6D1gQDpD5tWLwMG8drDe78CNLGx+f2jdDsePynvw@mail.gmail.com>
	<CAEZ8442askS4tPSjfMwM9pScEjiffKSODAWAh5mCb7D1kfpHXg@mail.gmail.com>
Message-ID: <CABNRm60ydYXQNQSPOWFdNfj3Tq1Khs5NBocak9oUyhNgmiNZEg@mail.gmail.com>

On Wed, Jul 27, 2011 at 11:44 PM, Alex Vincent <ajvincent at gmail.com> wrote:
>
> I'm seeing one major hole in your interface:  you don't clearly specify how
> to *end* a transaction group.  This really matters for when I want to
> start a group manually, do a bunch of little things, and then end the group.
>

You can end a transaction group if you call transact or replace with
merge=false.

Personally, I think Jonas's API is better than yours, for its simplicity,
> but it doesn't allow for adding manual transactions in the middle of a
> grouped transaction. With his model, one explicitly calls out when a
> transaction should happen - there's no ambiguity, and when I don't want a
> transaction, I don't get one.  With your model, it's harder to tell, and
> very much either implementation-dependent or specification-dependent when a
> transaction happens natively and when it doesn't.  That makes it prone to
> bugginess / inconsistent behavior.


I don't quite get what you mean here.  Could you elaborate a little?

I'd personally take elements of both API's, myself:  add your
> ManualTransaction interface and
> UndoManager.applyManualStep(ManualTransaction) to Jonas's last UndoManager
> interface.


That was my initial thinking as well.  However,


> I also like the tendency of your API to make each transaction its own
> object, where we can store properties besides just the title on each
> transaction.


making all transactions objects will allow authors and UAs to
provide arbitrary properties on them.  Also, I wanted the transaction
objects be provided during undo, redo, and hypothetical edit action or new
transaction events.

- Ryosuke


From scott.gonzalez at gmail.com  Thu Jul 28 02:16:16 2011
From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=)
Date: Thu, 28 Jul 2011 05:16:16 -0400
Subject: [whatwg] Form element invalid message
In-Reply-To: <4E30D965.6000704@cs.tut.fi>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
Message-ID: <CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>

On Wed, Jul 27, 2011 at 11:37 PM, Jukka K. Korpela <jkorpela at cs.tut.fi>wrote:

> 28.07.2011 03:21, Ian Hickson wrote:
>
>  A text input field could have a number of error conditions:
>>
>
> Indeed. Therefore it would be essential to be able to set the error message
> for _each_ check that a browser is supposed to do on the basis of HTML
> markup alone. If this is not possible, it is easier to authors to code all
> data checking in JavaScript. Setting the error messages is important both
> for context dependency and for localization (using the language of the
> browser's UI would be odd when it differs from the language of the page - if
> the page is in Greek and the instructions there are in Greek, I would expect
> the messages of the data error to be Greek, even when my browser speaks
> Hebrew).


I agree that it's extremely important to be able to define error messages
per error condition, but it's not necessary to code all data checking in
JavaScript to achieve that today. You can simply code the error message by
letting the browser do the validation, then using the validity flags to set
your own message with setCustomValidity. Since this is possible today, it's
probably worth building a prototype that reads the custom error messages out
of data- attributes, e.g., data-patternerror. I have a feeling you'll still
end up with a few shortcomings because you won't have control over the order
in which the checks are done, so you won't be able to specify which error
message to show when there are multiple errors. Perhaps the best you could
do is provide another option which allows multiple errors to be displayed at
once.


>  I guess we can have a dedicated attribute that user agents can use
>> to provide a message, rather than the current solution of just using the
>> title="" attribute for pattern=""'s error message.
>>
>
> The title="" attribute is generally supposed to contain an advisory title
> for an element, and deviating from this that way is very odd and confusing -
> especially since user agents may show its value in a tooltip or speak it out
> when entering the field.
>

I'd prefer not using the title attribute as well. In many cases where a
title attribute is already specified it won't make sense as an error
message. In cases where it will get specified specifically for pattern error
messages, authors will almost definitely use wording that doesn't make sense
for the title.

A dedicated attribute is much better. In particular, it does not interfere
> with the existing use of existing attributes.
>
>
>  If it's present, user
>> agents could use it to replace or augment their message, and authors could
>> make the message more specific by dynamically changing the attribute when
>> during the 'invalid' event handler.
>>
>>    <label>  Offer code:
>>     <input type=text maxlength=8 pattern="[a-z1-9]+" required
>>            oninput="setCustomValidity(**input.match(/0/) ?
>>                     'Codes contain no zeroes, only Os.' : '')"
>>            validitymessage="Enter the code without spaces.">
>>    </label>
>>
>
> It would be more logical and descriptive to call it errormessage rather
> than validitymessage.
>
> But the main problem is that attributes like maxlength, pattern, and
> required are supposed to provide some data validation in a simple manner
> that does not need to involve JavaScript and works even when it is disabled.
> To make them useful, it should be possible to set the error message for each
> of them separately in HTML.
>
> I have no better solution than to use separate attributes, like
> maxlengtherror, patternerror, requirederror. This doesn't sound cool, but it
> would work and would be useful.
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>


From jkorpela at cs.tut.fi  Thu Jul 28 03:25:40 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 28 Jul 2011 13:25:40 +0300
Subject: [whatwg] Form element invalid message
In-Reply-To: <CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
	<CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
Message-ID: <4E313924.7060507@cs.tut.fi>

28.07.2011 12:16, Scott Gonz?lez wrote:

> I agree that it's extremely important to be able to define error
> messages per error condition, but it's not necessary to code all data
> checking in JavaScript to achieve that today.

It's not, but if you cannot set the error messages in HTML, what's the 
point? Doing everything in JavaScript is simpler, especially because you 
should anyway duplicate the checks - for example, using JavaScript to 
get the pattern attribute value and run the check in it, to deal with 
the many situations where the user has JavaScript enabled and the 
browser does not support the pattern attribute (but still includes its 
value into the DOM).

> You can simply code the
> error message by letting the browser do the validation, then using the
> validity flags to set your own message with setCustomValidity.

Pardon? You would let the browser run the checks specified in HTML, then 
check the flags and turn an error to a custom error for which you can 
set the error message. This sounds like more complicated than doing it 
all in JavaScript, where you can directly do whatever error processing 
needs to be done. To make the HTML way a feasible option, the spec 
should define an easy way to set the error message(s) directly.

>  I have a feeling you'll still end up with a few
> shortcomings because you won't have control over the order in which the
> checks are done, so you won't be able to specify which error message to
> show when there are multiple errors.

Yes that would be a problem too, but a tolerable one. Besides, I guess 
the spec could say that the checks are carried out in the order in which 
the attributes are specified (though this admittedly deviates from the 
DOM-centric approach), and it could have yet another Boolean attribute 
that specifies whether all checks are carried out or the first failure 
aborts the processing. But more realistically, and more logically 
DOM-wise, the spec could simply define the order (e.g., required, 
maxlength, pattern) and specify that when a check fails, an error 
message is issued and further processing is suppressed.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From scott.gonzalez at gmail.com  Thu Jul 28 03:46:33 2011
From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=)
Date: Thu, 28 Jul 2011 06:46:33 -0400
Subject: [whatwg] Form element invalid message
In-Reply-To: <4E313924.7060507@cs.tut.fi>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
	<CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
	<4E313924.7060507@cs.tut.fi>
Message-ID: <CAO8i3idMLAZ37GK=U4+oVznDpasCGZ-55ioptdNQcD742W4xXw@mail.gmail.com>

2011/7/28 Jukka K. Korpela <jkorpela at cs.tut.fi>

> 28.07.2011 12:16, Scott Gonz?lez wrote:
>
>  I agree that it's extremely important to be able to define error
>> messages per error condition, but it's not necessary to code all data
>> checking in JavaScript to achieve that today.
>>
>
> It's not, but if you cannot set the error messages in HTML, what's the
> point? Doing everything in JavaScript is simpler, especially because you
> should anyway duplicate the checks - for example, using JavaScript to get
> the pattern attribute value and run the check in it, to deal with the many
> situations where the user has JavaScript enabled and the browser does not
> support the pattern attribute (but still includes its value into the DOM).


Doing everything in JavaScript is easier for developers, but an easily
configurable JavaScript plugin is easier for a very large percentage of web
content authors. A first pass might look something like:

$( "#age" ).validation({
    required: "You must enter an email address.",
    min: "You must be at least 13 to post nonsense on the web."
});

As for duplicating the checks anyway, I completely agree and I personally
just use JavaScript anyway. As one of the development leads for jQuery UI, I
can tell you that I have mixed feelings about all of the new features. As a
developer, I want to leverage as much of the semantics and information as I
can, but I also want complete control over the results of providing those
semantics and information. This generally means we want the attributes
without any of their actual functionality, which is a shame.


>  You can simply code the
>> error message by letting the browser do the validation, then using the
>> validity flags to set your own message with setCustomValidity.
>>
>
> Pardon? You would let the browser run the checks specified in HTML, then
> check the flags and turn an error to a custom error for which you can set
> the error message. This sounds like more complicated than doing it all in
> JavaScript, where you can directly do whatever error processing needs to be
> done. To make the HTML way a feasible option, the spec should define an easy
> way to set the error message(s) directly.


This is purely a suggestion of how to implement what I've described above.

There are essentially three choices (this applies to most new markup-driven
features):
1) Provide the information in the appropriate attributes and let the browser
do its thing.
2) Provide the information in a script and do everything via scripting.
3) Provide the information in the appropriate attributes, but handle them
via scripting.

#1 will never be as flexible as #3. #2 is a decent compromise and can be
made more flexible by allowing additional configuration via scripts. I think
the spec needs to make #1 as good as it can, but also do what it can to
encourage #2 over #3 where possible/reasonable.


>   I have a feeling you'll still end up with a few
>> shortcomings because you won't have control over the order in which the
>> checks are done, so you won't be able to specify which error message to
>> show when there are multiple errors.
>>
>
> Yes that would be a problem too, but a tolerable one. Besides, I guess the
> spec could say that the checks are carried out in the order in which the
> attributes are specified (though this admittedly deviates from the
> DOM-centric approach), and it could have yet another Boolean attribute that
> specifies whether all checks are carried out or the first failure aborts the
> processing. But more realistically, and more logically DOM-wise, the spec
> could simply define the order (e.g., required, maxlength, pattern) and
> specify that when a check fails, an error message is issued and further
> processing is suppressed.
>
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>


From shadow2531 at gmail.com  Thu Jul 28 04:06:25 2011
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Thu, 28 Jul 2011 07:06:25 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
 implementer feedback
In-Reply-To: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
Message-ID: <op.vzbs4rrf1ejg13@vertiform346>

Thanks for working on this. Much appreciated!

A few things so far:

At the end of section 4, there's:

> the state of insertOrderedList and insertOrderedList might be true both  
> before and after calling

Is one of those supposed to be insertUnorderedList?

At the beginning of section 5, there's:

> An editing host is a node that is either an Element with a  
> contenteditable attribute set to the true state, or the Element child of  
> a Document whose designMode is enabled.

What does "Element child" refer to specifically in the latter? Is it the  
HTML body element or is that implementation-specific?

Still in section 5:

> A collapsed line break is a br that begins a line box which has nothing  
> else in it, and therefore has zero height.
>
> An extraneous line break is a br that has no visual effect, in that  
> removing it from the DOM would not change layout, except that a br that  
> is the sole child of an li is not extraneous.
>Is this a good definition at all?

Don't really have much opinion on the names or the definition.

Which one refers to a <br> that acts like a placeholder for a line (so the  
line is selectable) where the <br> disappears once the user starts editing  
that line or closes the paragraph?

At the end of section 5:

> When the user agent is instructed to run a particular method, it must  
> follow the steps defined for that method in the appropriate  
> specification, not act as though the method had actually been called  
> from JavaScript. In particular, if the author has overridden the method  
> with a custom method, the standard method must be run rather than the  
> custom one.

Is this saying that doing something like:

HTMLDocument.prototype.execCommand = function(a, b, c) {
     // stuff
};

, will have no effect or should throw an error or something?

If so, is this just matching what browsers do now or just something you  
think is a good thing to prevent?

In section 6.1 with:

> To set the tag name of an Element element to new name:
>
> 1. If element is an HTML element with local name equal to new name,  
> return element.
>
> 2. If element's parent is null, return element.
>
> 3. Let replacement element be the result of calling createElement(new  
> name) on the ownerDocument of element.
>
> 4. Insert replacement element into element's parent immediately before  
> element.
>
> 5. Copy all attributes of element to replacement element, in order.
>
> 6. While element has children, append the first child of element as the  
> last child of replacement element, preserving ranges.
>
> 7. Remove element from its parent.
>
> 8. Return replacement element.

I pretty much translate that as:

var replacementElement = document.createElement("differentTagName");
parent.insertBefore(replacementElement, element);
for (var i = 0; i < element.attributes.length; ++i) {
     replacementElement.setAttribute(element.attributes[i].name,  
element.attributes[i].value);
}
while (element.hasChildNodes()) {
     replacementElement.appendChild(element.removeChild(element.lastChild));
}
parent.removeChild(element);

That seems to be removing attributes and nodes from one element and  
appending them to another while they're both being displayed in the parent.

Do you intend for that to be strictly done like that or is doing it a  
different way (like copying to the replacementElement in the DOM and then  
doing a replace) allowed as long as it gives the same end result? Or, will  
that mess up the range preservation?

-- 
Michael


From timeless at gmail.com  Thu Jul 28 06:48:39 2011
From: timeless at gmail.com (timeless)
Date: Thu, 28 Jul 2011 09:48:39 -0400
Subject: [whatwg] Form element invalid message
In-Reply-To: <CAO8i3idMLAZ37GK=U4+oVznDpasCGZ-55ioptdNQcD742W4xXw@mail.gmail.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
	<CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
	<4E313924.7060507@cs.tut.fi>
	<CAO8i3idMLAZ37GK=U4+oVznDpasCGZ-55ioptdNQcD742W4xXw@mail.gmail.com>
Message-ID: <CAACrNNf42uenUSruuOy7nZu9pOtFWBjBPOO+LA9hXo-CE+LWwQ@mail.gmail.com>

Your 13 example is a good argument against splitting between markup
and script. If the minimum value is updated in the html but not the
js, you get confused users. - I've seen the results of letting logic
get out of sync from error reporting, it isn't pretty.

On 7/28/11, Scott Gonz?lez <scott.gonzalez at gmail.com> wrote:
> 2011/7/28 Jukka K. Korpela <jkorpela at cs.tut.fi>
>
>> 28.07.2011 12:16, Scott Gonz?lez wrote:
>>
>>  I agree that it's extremely important to be able to define error
>>> messages per error condition, but it's not necessary to code all data
>>> checking in JavaScript to achieve that today.
>>>
>>
>> It's not, but if you cannot set the error messages in HTML, what's the
>> point? Doing everything in JavaScript is simpler, especially because you
>> should anyway duplicate the checks - for example, using JavaScript to get
>> the pattern attribute value and run the check in it, to deal with the many
>> situations where the user has JavaScript enabled and the browser does not
>> support the pattern attribute (but still includes its value into the DOM).
>
>
> Doing everything in JavaScript is easier for developers, but an easily
> configurable JavaScript plugin is easier for a very large percentage of web
> content authors. A first pass might look something like:
>
> $( "#age" ).validation({
>     required: "You must enter an email address.",
>     min: "You must be at least 13 to post nonsense on the web."
> });
>
> As for duplicating the checks anyway, I completely agree and I personally
> just use JavaScript anyway. As one of the development leads for jQuery UI, I
> can tell you that I have mixed feelings about all of the new features. As a
> developer, I want to leverage as much of the semantics and information as I
> can, but I also want complete control over the results of providing those
> semantics and information. This generally means we want the attributes
> without any of their actual functionality, which is a shame.
>
>
>>  You can simply code the
>>> error message by letting the browser do the validation, then using the
>>> validity flags to set your own message with setCustomValidity.
>>>
>>
>> Pardon? You would let the browser run the checks specified in HTML, then
>> check the flags and turn an error to a custom error for which you can set
>> the error message. This sounds like more complicated than doing it all in
>> JavaScript, where you can directly do whatever error processing needs to
>> be
>> done. To make the HTML way a feasible option, the spec should define an
>> easy
>> way to set the error message(s) directly.
>
>
> This is purely a suggestion of how to implement what I've described above.
>
> There are essentially three choices (this applies to most new markup-driven
> features):
> 1) Provide the information in the appropriate attributes and let the browser
> do its thing.
> 2) Provide the information in a script and do everything via scripting.
> 3) Provide the information in the appropriate attributes, but handle them
> via scripting.
>
> #1 will never be as flexible as #3. #2 is a decent compromise and can be
> made more flexible by allowing additional configuration via scripts. I think
> the spec needs to make #1 as good as it can, but also do what it can to
> encourage #2 over #3 where possible/reasonable.
>
>
>>   I have a feeling you'll still end up with a few
>>> shortcomings because you won't have control over the order in which the
>>> checks are done, so you won't be able to specify which error message to
>>> show when there are multiple errors.
>>>
>>
>> Yes that would be a problem too, but a tolerable one. Besides, I guess the
>> spec could say that the checks are carried out in the order in which the
>> attributes are specified (though this admittedly deviates from the
>> DOM-centric approach), and it could have yet another Boolean attribute
>> that
>> specifies whether all checks are carried out or the first failure aborts
>> the
>> processing. But more realistically, and more logically DOM-wise, the spec
>> could simply define the order (e.g., required, maxlength, pattern) and
>> specify that when a check fails, an error message is issued and further
>> processing is suppressed.
>>
>>
>> --
>> Yucca,
>> http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>>
>

-- 
Sent from my mobile device


From roblevin at hotmail.com  Thu Jul 28 09:25:02 2011
From: roblevin at hotmail.com (Rob Levin)
Date: Thu, 28 Jul 2011 17:25:02 +0100
Subject: [whatwg] CSP feedback
Message-ID: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>

Hello,

 

I posted this to the whatwg forums last week, and was advised to post to the
mailing list.  Here goes.

 

 

I've been thinking for some time about XSS attacks and ways to mitigate
them, and two observations struck me:

 

(1) XSS attacks nearly always occur in the <body> block of a html document,
and not the <head> block. This is because the attack surface of the <body>
is generally larger than the <head> block, and user-generated content is
usually (but not always) placed in the <body> of a document.

 

(2) With the rise of Javascript frameworks like JQuery, it is becoming best
practice to separate the code from the content. All legitimate code can be
placed in the <head> block without too much effort, for many sites.

 

So I came to the conclusion that adding a simple html mechanism to allow an
author to tell a user-agent that scripts should only be executed from the
<head> block would give a powerful weapon to authors to prevent XSS
exploits. Authors would write their own scripts, include them in their
<head> block, and instruct the user-agent that any scripts in the <body>
block should be ignored. This would be easy implement on the user-agent side
and easy to use on the author side. And it would degrade gracefully in older
user-agents.

 

Excited with this idea, I set out to find the right people to contact to get
this moving, which eventually led me to WHATWG. I did some research on the
mailing list archives, and realised that other people have had my ideas
first (many years ago), and are well on the way to implementing them. Oh
well, never mind! So I've read about sandboxing on IFrames, and the CSP
unofficial draft, and clearly these efforts are solving bigger problems in a
more comprehensive way, which largely encompass my ideas. Well done to all
involved on these major efforts.

 

But... there are a few things that strike me.

 

 

Firstly, whatever is done to mitigate XSS should be really really simple to
use and understand by authors. I'm not sure that CSP hits the sweet spot
between usability and security; I am worried it is going to be too difficult
to use for the mass market, and hence fail in part of its mission.

 

For me, the instruction to inform a user-agent that a script should be
ignored in the body should look something like:

 

<head>

<security request="NoBodyScripts"></security>

</head>

 

 

this would be intuitive to most authors, and would stop an awful lot of
attacks.

 

How can I achieve the same effect with CSP? I may have it wrong, but the
only way I can see to implement this with CSP would be to do something like:

 

<head>

<meta http-equiv="X-Content-Security-Policy" script-nonce="[a strong dynamic
random token]">

</head>

 

...and include this nonce with every script on the page.

 

 

Secondly, creating and implementing a protocol such as CSP is only part of
the story to really eliminate XSS in the wild. The social aspect needs to be
thought through. I think the best way to encourage authors to use it would
be to show some consistent visual feedback given to users that their site
has implemented "Web Security" and that the user-agent is enforcing it. This
would then start a virtuous feedback cycle where more sites implement the
security, putting pressure on more user-agents to implement it etc.

 

Users are already used to a padlock symbol showing a secure socket
connection; a similar common symbol could be recommended to user-agents to
display to users when CSP is invoked. This should be part of the spec, in my
opinion.

 

thanks,

-rob



From rob at drunkenfist.com  Thu Jul 28 09:32:57 2011
From: rob at drunkenfist.com (Rob Larsen)
Date: Thu, 28 Jul 2011 12:32:57 -0400
Subject: [whatwg] CSP feedback
In-Reply-To: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>
References: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>
Message-ID: <36419b00351c9485afcbdd1cc20dfb51.squirrel@QuestMail.FutureQuest.net>

> Hello,
> (2) With the rise of Javascript frameworks like JQuery, it is becoming
> best
> practice to separate the code from the content. All legitimate code can be
> placed in the <head> block without too much effort, for many sites.

In practice many developers prefer to place almost all script tags right
before the closing body tag

http://developer.yahoo.com/performance/rules.html#js_bottom



From Simetrical+w3c at gmail.com  Thu Jul 28 11:15:53 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 28 Jul 2011 14:15:53 -0400
Subject: [whatwg] Specification of window.find()
In-Reply-To: <CAOYSAj0xN-ZnzSB0ogkks-NPM4-R4Y-XHV63ySkZBuoLVA8+hA@mail.gmail.com>
References: <6A6628DC1DD90E418BBE7106BBAF58620381A6@008-AM1MPN1-021.mgdnok.nokia.com>
	<Pine.LNX.4.64.1101062153070.29066@ps20323.dreamhostps.com>
	<CAOYSAj0+2BcDaOKPO577uMx7NO7YchLFSzoLi-=g+9UHzG=ZdA@mail.gmail.com>
	<CAKA+AxkqF=6w4CLGwsJo9EAQfq_42LLP8am8PJ=Ad2m9327w8w@mail.gmail.com>
	<CAOYSAj3R-5WpsFQOsTxw+Ab=aB5=pCNEXDGpaDpb5r3Ex3PX5A@mail.gmail.com>
	<CAKA+Axkamrd2B+Owca3mQpPJYG6wPK6h4Sg47Sn_aFjX2_6DbQ@mail.gmail.com>
	<CAOYSAj0xN-ZnzSB0ogkks-NPM4-R4Y-XHV63ySkZBuoLVA8+hA@mail.gmail.com>
Message-ID: <CAKA+Ax=s_gYLu=7F1h5qt1epif-JObZJV4A4NocFGr0weRH+6Q@mail.gmail.com>

On Wed, Jul 27, 2011 at 6:55 PM, Tim Down <timdown at gmail.com> wrote:
> There's also the perennial problem of dealing with non-visible text
> (c.f. Selection.toString(), innerText), which some browsers handle (a
> quick tests suggests WebKit searches non-visible text and Firefox
> doesn't).

True.  Of course, that's a rabbit hole I've mostly managed to avoid
going down so far.

> Also, don't forget that you're in the habit of writing this
> sort of code. Knocking that kind of code out quickly is beyond what a
> large percentage of web developers are capable of.

Right, but that's why we have libraries like jQuery.  If it's in
demand and it can be done in JavaScript, libraries can do it, and then
we don't want to make browsers do it too unless either it's an
extremely common use-case or they can do it better somehow.  Or they
have to for compat.

> There is no reason why your algorithms can't
> work on non-editable nodes, so why require the user to change such a
> fundamental property of the DOM (even temporarily)? I'd prefer an
> alternative mechanism for specifying whether a command should apply to
> only editable content that is part of the editing API. In my
> execCommand implementation, it's specified as a property of an options
> object passed to execCommand(). If that's not an option, another
> command could be used, similar to the styleWithCSS command, to switch
> between modes. applyToNonEditable, or something.

Having a behavior switch like styleWithCSS is a possible option.  The
problem I have with that kind of switch is that it breaks down if two
scripts on the same page are both relying on the switch being a
particular value: you can't rely on the current state of the switch
unless you run it before every single command execution.  I saw at
least one execCommand()-using library that did exactly that, running
styleWithCSS *and* useCSS before every single command.

Defining an extra argument to execCommand() would be possible, but I'm
leery about it, because it already has one useless boolean argument
that no browser but IE supports.  What we could consider is
overloading it with a form like execCommand(command, options), where
options is an object, so you could do execCommand("forecolor", {value:
"red", styleWithCSS: false, restrictToEditable: true}) or something.
But it's awkward to have to specify the same options all the time, and
the syntax is incompatible and doesn't fall back gracefully.

It's definitely worth considering at some point, though.  I added a
TODO: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=aff4441e


From Simetrical+w3c at gmail.com  Thu Jul 28 13:17:34 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 28 Jul 2011 16:17:34 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
Message-ID: <CAKA+Axm4Ry1Ahp_mZE-86-6fKCha2pgBgP=pSw3Zgc5_dBFB6A@mail.gmail.com>

Thanks to both of you for the feedback!

On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> WebKit treats any font-weight above or equal to 600 as bold because that's
> what user sees, and boldness is a binary concept in execCommand; Firefox 5
> appears to do the same.

Yes, bold is not a big problem.  If you look at "the bold command"
section, it explicitly defines the values "bold", "600", "700", "800",
or "900" as corresponding to "on", so it's simple string comparison.
The bigger problem is things like colors and sizes, where there are
lots of units that are related in complicated ways.

What I'd really like to do is have CSSOM define a reliable way of
uniquely serializing CSS values, and then say that two values are
equal if they serialize to the same thing.  But I guess for now I
should just make up my own definition.  For most things it's pretty
straightforward in principle, but it still needs to be specced.

> WebKit compares colors in rgb/rgba format; e.g. red is first parsed as
> rgb(255, 0, 0). ?Firefox 5 seems to does the same as well.

Yeah, that's the obvious way to do it.  If I have to write the
definition for this, I guess I'll just say two CSS colors are equal if
their R/G/B/A channels are all equal.

> WebKit compares font sizes in legacy font size used in font element;
> See?CSSStyleSelector::legacyFontSize or?legacyFontSizeFromCSSValue in
> EditingStyle.cpp

I more or less reverse-engineered that to define
queryCommandValue("fontSize") -- translate the computed font-size to
pixels, then round to the nearest corresponding legacy font size.
Other browsers do different things that are less useful.  But there
are cases when I want to compare CSS values for equality more
precisely.  For instance, per spec, if you have

<span style=font-size:large>foo[bar]baz</span>

and run execCommand("fontSize", false, "4"), it does nothing.  WebKit
seems to break up the span and add a new span or font element, but
this adds extra clutter.  However, if you have

<span style=font-size:18px>foo[bar]baz</span>

then the spec says to break up the span, because 18px != large, even
though queryCommandValue() says the same thing for both.

> Throwing SYNTAX_ERR might cause a backward compatibility issue because the
> UAs don't throw an error now. ?We can probably throwing console messages
> first to give authors some grace period to transition.

Yeah, this was a bad idea.  The only case where anyone throws
exceptions for bad values is Opera with formatBlock.  I've removed
this:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=ff9f4629

Don't know why I added it in the first place.

> For font element vs. span with style issue, we could add another boolean
> flag that forces UAs to toggle font-element; i.e. add StyleWithFont command.

I guess.

> 3.2: Prefix "webkit-" doesn't seem natural given all editing commands use
> Camel case. ?Maybe Ms, Gecko, WebKit and Opera? ?e.g. WebKitFontSizeDelta.
> ?But again this might cause a backward compatibility because we do implement
> few editing commands that are not in the spec and they are not prefixed.

I copied this from HTML5, and I think at least Opera has some commands
with this syntax, but you're right it doesn't make much sense.  I've
changed it: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=e9369d6c

> 3.3: The return value of queryCommandEnable depends on beforecut,
> beforecopy, and beforepaste events and selection state in WebKit; WebKit
> returns false if default actions are prevented in those events or selection
> is not a range. ?Firefox 5 appears to do the same for selection but doesn't
> seem to fire beforecut, beforecopy, and beforepaste.

How does WebKit know if those events will be prevented or not, without
running the handlers?  If the page runs queryCommandEnabled(), nothing
actually happened, so surely WebKit doesn't fire any events?  Also,
are you only talking about the cut/copy/paste commands, or other
commands too?

On Thu, Jul 28, 2011 at 7:06 AM, Michael A. Puls II
<shadow2531 at gmail.com> wrote:
> At the end of section 4, there's:
>
>> the state of insertOrderedList and insertOrderedList might be true both
>> before and after calling
>
> Is one of those supposed to be insertUnorderedList?

Yeah, thanks.  Fixed:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=eb346d01

> At the beginning of section 5, there's:
>
>> An editing host is a node that is either an Element with a contenteditable
>> attribute set to the true state, or the Element child of a Document whose
>> designMode is enabled.
>
> What does "Element child" refer to specifically in the latter? Is it the
> HTML body element or is that implementation-specific?

It just means what the literal words imply: any Element that is the
child of a Document whose designMode is enabled.  The Nodes model
<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#nodes-model>
implies that any Document will always have either zero or one child
that's an Element.  If one exists, it will be returned by
document.documentElement.  For HTML documents, the Element child of a
Document is generally <html>, although you could change it with DOM
manipulation if you really wanted.

(I noticed that the word "child" wasn't linked here, and I fixed that,
although I don't think that's what caused your confusion.)

> Still in section 5:
>
>> A collapsed line break is a br that begins a line box which has nothing
>> else in it, and therefore has zero height.
>>
>> An extraneous line break is a br that has no visual effect, in that
>> removing it from the DOM would not change layout, except that a br that is
>> the sole child of an li is not extraneous.
>> Is this a good definition at all?
>
> Don't really have much opinion on the names or the definition.
>
> Which one refers to a <br> that acts like a placeholder for a line (so the
> line is selectable) where the <br> disappears once the user starts editing
> that line or closes the paragraph?

That would be "collapsed block prop", which is admittedly a terrible
term whose definition is confusing.  I added a note to clarify what
the intent is:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=6e16b641

> At the end of section 5:
>
>> When the user agent is instructed to run a particular method, it must
>> follow the steps defined for that method in the appropriate specification,
>> not act as though the method had actually been called from JavaScript. In
>> particular, if the author has overridden the method with a custom method,
>> the standard method must be run rather than the custom one.
>
> Is this saying that doing something like:
>
> HTMLDocument.prototype.execCommand = function(a, b, c) {
> ? ?// stuff
> };
>
> , will have no effect or should throw an error or something?

It's saying that even if the author does that, when the spec says to
do execCommand("foo"), it has to use the real implementation and not
the author-overridden one.  For instance, I often say things like "Let
replacement element be the result of calling createElement(new name)
on the ownerDocument of element", so this means that even if you
replace createElement(), it will still act like it called the original
unreplaced one.  DOM Range uses similar terminology.  An alternative
approach would be to make sure there are unambiguous ways of saying
the same thing in prose, but that doesn't scale well in my experience.

I tried to clarify:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=2ddd02d2

Does that seem better?

> If so, is this just matching what browsers do now or just something you
> think is a good thing to prevent?

This is what browsers do now.  I'm just clarifying what the spec
means, not requiring specific author-visible behavior.

> I pretty much translate that as:
>
> var replacementElement = document.createElement("differentTagName");
> parent.insertBefore(replacementElement, element);
> for (var i = 0; i < element.attributes.length; ++i) {
> ? ?replacementElement.setAttribute(element.attributes[i].name,
> element.attributes[i].value);
> }
> while (element.hasChildNodes()) {
> ? ?replacementElement.appendChild(element.removeChild(element.lastChild));
> }
> parent.removeChild(element);
>
> That seems to be removing attributes and nodes from one element and
> appending them to another while they're both being displayed in the parent.

Essentially, yes, but you missed the "preserving ranges" part.  You
can see my implementation here:

http://aryeh.name/gitweb.cgi?p=editing;a=blob;f=implementation.js;h=8d3a9856

Note that browsers don't repaint until the event loop spins, so the
intermediate state here should never be visible to the user.  Opera
currently repaints sometimes event between event loop spins, but
that's probably a bug, and anyway I doubt they'll repaint in the
middle of an execCommand() execution.

> Do you intend for that to be strictly done like that or is doing it a
> different way (like copying to the replacementElement in the DOM and then
> doing a replace) allowed as long as it gives the same end result? Or, will
> that mess up the range preservation?

The way I've currently specced it, it has to be done in that order or
else the "preserving ranges" part won't work.  It would be possible
for me to rework that if necessary.  UAs can always do whatever they
want as long as the results are black-box identical, of course.


From rniwa at webkit.org  Thu Jul 28 13:31:55 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Thu, 28 Jul 2011 13:31:55 -0700
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CAKA+Axm4Ry1Ahp_mZE-86-6fKCha2pgBgP=pSw3Zgc5_dBFB6A@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
	<CAKA+Axm4Ry1Ahp_mZE-86-6fKCha2pgBgP=pSw3Zgc5_dBFB6A@mail.gmail.com>
Message-ID: <CABNRm62uCT5KrkwzLT5aXX5V4WdAjG6hLyiyqVnkVRP6fuD+mw@mail.gmail.com>

On Thu, Jul 28, 2011 at 1:17 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:
>
>  > 3.3: The return value of queryCommandEnable depends on beforecut,
> > beforecopy, and beforepaste events and selection state in WebKit; WebKit
> > returns false if default actions are prevented in those events or
> selection
> > is not a range.  Firefox 5 appears to do the same for selection but
> doesn't
> > seem to fire beforecut, beforecopy, and beforepaste.
>
> How does WebKit know if those events will be prevented or not, without
> running the handlers?  If the page runs queryCommandEnabled(), nothing
> actually happened, so surely WebKit doesn't fire any events?  Also,
> are you only talking about the cut/copy/paste commands, or other
> commands too?
>

WebKit fires those events :(  I don't know why we do that.  I think it's a
WebKit bug but I'm just pointing that out in the case there are some
websites out there that depends on this quirky behavior.  Just
cut/copy/paste for now as far as I know.

- Ryosuke


From roblevin at hotmail.com  Thu Jul 28 14:51:19 2011
From: roblevin at hotmail.com (Rob Levin)
Date: Thu, 28 Jul 2011 22:51:19 +0100
Subject: [whatwg] CSP feedback
In-Reply-To: <36419b00351c9485afcbdd1cc20dfb51.squirrel@QuestMail.FutureQuest.net>
References: <COL122-DS88CC2BA2CD851336B4B90C8340@phx.gbl>
	<36419b00351c9485afcbdd1cc20dfb51.squirrel@QuestMail.FutureQuest.net>
Message-ID: <COL122-DS254673C4DE52C23AB0959BC8340@phx.gbl>

> > (2) With the rise of Javascript frameworks like JQuery, it is becoming 
> > best practice to separate the code from the content. All legitimate 
> > code can be placed in the <head> block without too much effort, for 
> > many sites.

> In practice many developers prefer to place almost all script tags right
before the closing body tag
>
> http://developer.yahoo.com/performance/rules.html#js_bottom

Yes, I agree.  There can be a performance optimisation from placing scripts
at the bottom of the page.  In the absence of any other factors, this has
been the primary driver of advice where to place the scripts.  

But from a security point of view, mixing the scripts and the content is
quite dangerous - it gives malicious content more opportunities to sneak in
a live malicious script.  If placing scripts only in the head block could
give a simple and significant security enhancement, then the best-practice
advice could quickly change.  And hopefully with modern browsers the same
performance benefits can now be realised using scripts in the head block,
with the defer and/or async attribute

http://stackoverflow.com/questions/3952009/defer-attribute-chrome




From annevk at opera.com  Thu Jul 28 15:05:37 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 28 Jul 2011 15:05:37 -0700
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
References: <4DDFF77F.9050605@mit.edu>
	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>
	<4DFB8783.7070802@mit.edu> <4DFB8C23.7070808@mit.edu>
	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>
	<4DFB9F2D.3070404@mit.edu>
	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
Message-ID: <op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>

On Fri, 17 Jun 2011 11:57:20 -0700, Ian Hickson <ian at hixie.ch> wrote:
> I'm all in favour of making this generic across all vocabularies. I'm
> happy to work with Anne and Ms2ger to move all the HTML and SVG event
> handler attributes (does MathML have any?) to Element. It would not be an
> uncontroversial change.

So the SVG WG discussed this and they would like this as well. (They  
basically want the same behavior as HTML has here and converge as much as  
possible.) The change to the current mechanism required for SVG is to  
expose an "evt" variable somehow in scope of the Function.

Now does it make sense to have the IDL attributes on Element but not have  
the content attributes on all elements? That would mean it still depends  
on the markup language what you can use as on* attributes which is not  
very straightforward.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From ian at hixie.ch  Thu Jul 28 15:22:10 2011
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 28 Jul 2011 22:22:10 +0000 (UTC)
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
References: <4DDFF77F.9050605@mit.edu>
	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>
	<4DFB8783.7070802@mit.edu> <4DFB8C23.7070808@mit.edu>
	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>
	<4DFB9F2D.3070404@mit.edu>
	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
Message-ID: <Pine.LNX.4.64.1107282221080.3775@ps20323.dreamhostps.com>

On Thu, 28 Jul 2011, Anne van Kesteren wrote:
> On Fri, 17 Jun 2011 11:57:20 -0700, Ian Hickson <ian at hixie.ch> wrote:
> > I'm all in favour of making this generic across all vocabularies. I'm 
> > happy to work with Anne and Ms2ger to move all the HTML and SVG event 
> > handler attributes (does MathML have any?) to Element. It would not be 
> > an uncontroversial change.
> 
> So the SVG WG discussed this and they would like this as well. (They 
> basically want the same behavior as HTML has here and converge as much 
> as possible.) The change to the current mechanism required for SVG is to 
> expose an "evt" variable somehow in scope of the Function.
> 
> Now does it make sense to have the IDL attributes on Element but not 
> have the content attributes on all elements? That would mean it still 
> depends on the markup language what you can use as on* attributes which 
> is not very straightforward.

As far as HTML goes, I'd suggest that we'd have a 1:1 mapping of IDL to 
content attribute, and have them be the same for every element (except 
<body>, <frameset>, and <marquee>).

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


From chuck at jumis.com  Thu Jul 28 16:06:50 2011
From: chuck at jumis.com (Charles Pritchard)
Date: Thu, 28 Jul 2011 16:06:50 -0700
Subject: [whatwg] Canvas fallback content: IAccessible accLocation
Message-ID: <4E31EB8A.5030205@jumis.com>

Tab,

I do understand your position when you recommend SVG for UI and the 
vendor-level support that will/can evolve from markup
as well as [standard] retained-mode semantics.
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0184.html


My position evolved from experience.
I need a method for canvas to share path data with the browser 
accessibility API:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0187.html

I'd prefer to call it setClickableRegion(element); and I'd prefer that 
it delegates mouse events
to the canvas subdom, as well as sharing region info with the AT. I 
require it to fill out IAccessible accLocation,
the rest is just up to the editor / WG and good practices.

You have opposed the addition of such a method -- the method would 
essentially bring image map-level accessibility data to canvas uis;
currently, there is no way to inform the accessibility tree with such 
information -- image maps were ruled out, and focus management
only applies to the actively focused element.


I'm approaching this issue having put into practice, in as many ways as 
I could approach,
the WHATWG specs in building a "Web Application". The WHATWG picked up 
Canvas early,
and I feel an obligation to contribute: SVG implementations in 2007 were 
not workable;
nor was VML -- work by the WHATWG truly helped us move forward.

Thanks to large investments, RIM and Microsoft pushed SVG support 
forward in two
major browser families.  Thanks to other investments, ARIA support was 
also greatly
enhanced across browser families and ATs. Mozilla has had brought, 
though uneven,
support for SVG for some time.

So, in 2011, we have a much improved landscape for SVG, as well as a full
landscape for Canvas. And yes, I started code bases prior to 2011, when 
Canvas
was the sole interface I could use to target the market; VML too slow 
and inflexible,
SVG mostly unimplemented.

The formalism required by SVG is expensive; just as the formalism 
required by ARIA
is costly. We're supporting both, because SVG output ensures a 
standards-based
interoperable file format serialization and ARIA ensures standards-based 
interoperable
ui serialization and interaction.

The costs of building an SVG 1.x implementation are expensive, relative 
to Canvas. In the order
of a magnitude. SVG Tiny is less costly, though still more so than 
Canvas; and the
design decisions made by an SVG Tiny vendor are not something that can 
be worked-around
by additional javascript coding. As such, we are much more beholden to 
vendors
with SVG than we are with Canvas. That catches us up to present.

Presently, SVG implementations are not performant for InkML use cases. 
We are
still left with Canvas as a solution for that issue. I believe that 
Doug's proposal
to investigate a new graphics API to encompass the functionality of 
SVG+Canvas
should also integrate WebGL+InkML as well as ARIA; that's the stack we have
had to use in practice to deliver a desktop quality application 
experience with Web Apps apis.

As for general UI: CSS3 serves most of the use cases we initially used
Canvas for; and CSS3 support has really caught on in 2010/2011. Just as
with SVG, we certainly work with CSS3 -- round rectangles and gradients 
are super.
Many CSS extensions are still vendor specific.

Canvas serves most of the existing market; and while CSS3 naming and 
semantics
are fantastically useful, Canvas output gives us a level of visual 
control and compatibility
that CSS-only solutions do not. We're also able to stay away from 
vendor-specific prefixes;
using them on a case-by-case basis as a progressive enhancement.

While stand-by, eager to engage in features put forward by CSS4 and 
SVG2, we need
to complete our ARIA support of our Canvas-based UIs. The alternative,
of supporting a completely different, stripped down interface, for 
AT-users, is not
palatable. It does not fit with the concept of "universal design", nor 
of fallback content.

WHATWG has supported every accessibility interface we need, except 
accLocation.
The focus event handling of canvas fallback content, and 
scrollPathIntoView, are
immensely helpful in allowing us to meet WCAG principles. I've personally
tested NVDA, Window-Eyes, JAWS, ZoomText, Windows UI Automation and MSAA 
trees,
and the packaged support in OS X and iOS for accessibility in the browsers.

I've tested the full spectrum of HTML forms as well as some of the new 
input elements
put forward by the WHATWG. I've tested the spectrum of SVG, as well as 
off-loading
filters onto the GPU via WebGL.

And I've done all of this, because writing web apps, on the belief that 
browsers can
deliver a "native-application level" experience, is my livelihood. I'm 
writing applications,
and just as with every other API/stack, writing applications requires a 
lot of work.

I'm invested, because my income is built on my ability to deliver usable 
applications.

I'm very much invested into the Web stack, in any form that is supported;
at this point, I'm one blocking issue away from clearing up my 
accessibility testing bug list.
And so I'm putting in a great deal of effort into confronting that issue.

The proposal put forward is internally consistent, it's cost effective, it's
understandable by existing authors, there are hundreds of existing 
applications
that could use the method, and it completes the IAccessible obligations 
that vendors have to accessibility APIs.

While I understand your position on Canvas UI uses, I appeal to you, to  
understand my obligation to WCAG,
to end users, and the limits of what existing Canvas applications can 
support in practice.

Please consider the merits of allowing Canvas developers to send path 
data to assistive technology,
on their own. I believe they are worthwhile; we are talking simply, 
about setClickableRegion(element) sending
an event, with current method, and the element parameter, to the browser 
vendor's accessibility API.

That's what I've been pushing hard for, for the past few months, and 
that completes the list of issues
I've encountered, from the past four years.


-Charles


From ian at hixie.ch  Thu Jul 28 17:24:49 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:24:49 +0000 (UTC)
Subject: [whatwg] questions regarding submit event timing
In-Reply-To: <BANLkTikSfhtx+aAPKNpiOUu7vUD727TCPQ@mail.gmail.com>
References: <BANLkTi=2egZS7RmJG8ds0VEjczaUTwVZwQ@mail.gmail.com>
	<BANLkTinoev9GyBdzftvwJiz9pZ9XeOq=8Q@mail.gmail.com>
	<BANLkTikfNU_15fWORuhmKmzN+9TiUQ+RtA@mail.gmail.com>
	<BANLkTikSfhtx+aAPKNpiOUu7vUD727TCPQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107280132320.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Hallvord R M Steen wrote:
>
> Some questions related to possibly clarifying this section: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit
> 
> 1) What methods exactly cause the "scripted submit" flag to be set? It's 
> obviously set if you call form.submit(), but will it be set in these two 
> cases:
> 
> HTML: <form><input type="submit"></form>
> JS: form.elements[0].click()
> 
> or
> HTML: <form><input type="submit"></form>
> JS: form.elements[0].dispatchEvent( evt ) /* where evt is a 'click'
> event object  */
> 
> I believe the answer should be yes in both cases but I'm not sure if 
> it's clear from the spec.

On Mon, 2 May 2011, Glenn Maynard wrote:
> 
> The only place in the HTML5 spec itself that sets this flag is submit() 
> (http://www.whatwg.org/specs/web-apps/current-work/#dom-form-submit), 
> although other specs could also use that flag.

Indeed.


On Mon, 2 May 2011, Jonas Sicking wrote:
> 
> Isn't the purpose of this flag mostly backwards compatibility, but 
> otherwise a fairly awkward feature. If so, it seems like we should limit 
> its scope as much as possible, both to make implementation easier, and 
> to make the forms API otherwise as simple as we can.

On Thu, 5 May 2011, Hallvord R M Steen wrote:
> 
> It seems to have two purposes:
> 1) avoid doing form validation on form.submit()
> Definitely a backwards compatibility feature, and one that yours truly 
> probably caused by complaining when form.submit() was specified to throw 
> an exception when the form didn't validate. This broke websites left, 
> right and center when implemented in Opera.
> 
> 2) Avoid firing a submit event.
> What is more intuitive for button.click() or a synthetic click event on 
> the button - submit event firing? I guess so, in that case the spec 
> as-is is OK though it's a bit counter-intuitive that other scripted ways 
> to submit a form than .submit() don't set the scripted-submit flag.

On Thu, 5 May 2011, Jonas Sicking wrote:
> 
> From a behavioral perspective I think it's most intuitive that the 
> events fire and that validation occurs. That way calling .click() 
> behaves as if the user clicked.
> 
> However I agree that a name like "scripted-submit" could be interpreted 
> to mean that it should include other things than calls to .submit.
> 
> Maybe renaming the flag would make the spec more intuitive?

I've renamed it to "submitted from submit() method".


On Mon, 2 May 2011, Hallvord R M Steen wrote:
>
> 2) Is the event fired synchronously? (And is it fired synchronously for 
> all three cases of scripted submits mentioned above?) Again, I think the 
> answer is yes but I couldn't find this information in the spec when 
> looking for it.

On Mon, 2 May 2011, Glenn Maynard wrote:
> 
> All events in the HTML5 spec are effectively synchronous; it uses tasks 
> to get the effect of what DOM Events calls an "asynchronous event".  
> Step 6 says "fire a simple event that is cancelable named submit, at 
> form", which is strictly synchronous; if it was firing it asynchronously 
> it'd say "queue a task to fire a simple event".
> 
> (It's also possible for an entire algorithm to be running from a task, 
> in which case the event is synchronous with respect to the algorithm, 
> but the algorithm itself, including the event, is asynchronous with 
> respect to any script that triggered it.  Handling these common but more 
> complicated interactions is why this method is much clearer and more 
> powerful than the overgeneric "asynchronous event" concept.)

Indeed.

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


From ian at hixie.ch  Thu Jul 28 17:36:26 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:36:26 +0000 (UTC)
Subject: [whatwg] Spec references in multipage
In-Reply-To: <BANLkTinzZ==FhG5FZ4bJuEt+rxYAHST0Fw@mail.gmail.com>
References: <BANLkTinzZ==FhG5FZ4bJuEt+rxYAHST0Fw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107290035321.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Glenn Maynard wrote:
>
> This is probably a known issue, but the reference lists in the multipage 
> version of the specs only list references within the same section of the 
> spec.  Clicking "submitted" in [1] shows only two references.  Clicking 
> the same thing in the single-page version shows nine.  It would be very 
> helpful if external references were included.
> 
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit

Yeah, this is the result of the dfn.js script only looking in the current 
document. If anyone is interested in fixing this, let me know and I can 
try to explain the problem space. (One solution is to change the spec 
splitter to output data that a new dfn.js can use.)

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


From ian at hixie.ch  Thu Jul 28 17:43:34 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:43:34 +0000 (UTC)
Subject: [whatwg] Browser inconsistencies in rendering <optgroup> and
 <option>
In-Reply-To: <4DBF4571.1060109@mit.edu>
References: <4CBF2FEB.5010903@mit.edu>
	<Pine.LNX.4.64.1101050143390.29066@ps20323.dreamhostps.com>
	<4D23EBEC.9030503@mit.edu>
	<Pine.LNX.4.64.1105022323000.19153@ps20323.dreamhostps.com>
	<4DBF4571.1060109@mit.edu>
Message-ID: <Pine.LNX.4.64.1107290040260.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Boris Zbarsky wrote:
> On 5/2/11 7:26 PM, Ian Hickson wrote:
> >
> > I think it'd be better for [the rendering of <option>s in a <select> 
> > being one to a line] to be a style scoped to the binding that defines 
> > the <select>, personally.
> 
> OK, but more on this below.
> 
> > > I would clearly prefer that the behavior be defined in terms of CSS; 
> > > UAs that under the hood want to ignore the styles and just do 
> > > something magic can still do that, of course.
> > 
> > The behaviour is defined in terms of CSS and a hypothetical binding 
> > language similar to XBL; in theory that should be sufficient for your 
> > needs, no?
> 
> I don't think so; we need to define at least some details of the 
> binding. That's what I meant by sites depending on the details.  For 
> example, width calculations for <select> need to work in a particular 
> way (or rather small range of ways)....
> 
> > If not, I guess we have to work out what we can get browser vendors to 
> > converge on. I am concerned that this might not end up being exactly 
> > what you need, though, which would be of no more help to you than the 
> > status quo, but with more complicated rules.
> 
> That's entirely possible, yes.  At the moment we're getting bug reports 
> because people write their HTML+CSS, test in only WebKit or only IE, and 
> then it breaks in Gecko.  I would assume that there are others who only 
> test in Gecko and then it breaks in other browsers....

That makes sense.

My intent at this point is to continue to define this in terms of abstract 
bindings. However, that doesn't mean we can't define the constraints that 
those bindings should work under. If you would like particular constraints 
specified, e.g. the width of a <select>, please do raise them.

Given this model, though, I don't think the initial request (having a 
UA-level rule for <option> that sets display:block outside the context of 
a binding) makes sense.

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


From ian at hixie.ch  Thu Jul 28 17:54:40 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 00:54:40 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <4DC7C90F.4080405@gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
Message-ID: <Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 3:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 31 Dec 2010, Jonas Sicking wrote:
> >> >
> >> > The thing that makes this different than "Google suggest"-style UI 
> >> > is that in the latter case you need a script that continually polls 
> >> > for more appropriate suggestions and updates the list -- for this 
> >> > kind of thing we'd probably want to use a direct API, we wouldn't 
> >> > want to have scripts have to poke at the <datalist> DOM in real 
> >> > time.
> >>
> >> Why not?
> >>
> >> The firefox implementation should allow this (though I haven't tried 
> >> this myself). Feel free to try it out and let us know how well/poorly 
> >> it works.
> >
> > I just meant that it would be a poor authoring experience. I agree 
> > that it should in theory be possible with the current API; it just 
> > seems that if that's the use case we want to address, we should 
> > instead just have people point to a URL and be done with it:
> >
> >   <input type=text autosuggest="/cgi-bin/autocomplete.pl">
> >
> > ...or some such.
> 
> Sure, but that seems like a significantly more complex solution to 
> design. We'd likely have to add features like deciding how many 
> milliseconds to wait for another keystroke before sending the request. 
> We'd also have to come up with a file-format for the response, and a 
> definition of how the typed value is supposed to be sent with the 
> request.

Yes. Doing the hard work to make it easier for authors is our job. :-)


> I'd also be worried about making it possible to write keyloggers on 
> sites that filter out scripts, but do allow form controls to be 
> inserted.

These would presumably be forms that cannot be submitted? I'm not sure I 
understand how this attack scenario would work in practice.


On Tue, 3 May 2011, Aryeh Gregor wrote:
> On Mon, May 2, 2011 at 6:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I just meant that it would be a poor authoring experience. I agree 
> > that it should in theory be possible with the current API; it just 
> > seems that if that's the use case we want to address, we should 
> > instead just have people point to a URL and be done with it:
> >
> > ? <input type=text autosuggest="/cgi-bin/autocomplete.pl">
> >
> > ...or some such.
> 
> This is too inflexible.  It splits the logic between the browser and 
> server in a rigid way, and doesn't allow client-side script to have any 
> say.  It would be much more useful to have a script API that lets you 
> assign a list of suggestions to an input.  Basically the same 
> functionality as datalist, just easier to script.  This way, the author 
> has control over when and how the results are fetched and displayed, can 
> use any format on the server side, can retrieve results from the client 
> side if they like, etc.
> 
> There's no need to use the subjunctive here, by the way.  As I said, I 
> did actually write such a search-suggestion thing for MediaWiki using 
> the datalist API, and it works great in Firefox 4 as far as I can tell.  
> It was just complicated unnecessarily by the need to add datalist 
> elements to the DOM instead of plugging a list directly into the input.

We could certainly also support scripted delivery of the suggestions.


On Tue, 3 May 2011, Jonas Sicking wrote:
> >>
> >> It seems to me that a simple boolean attribute and a few lines of 
> >> script solves 80% of the use cases.
> >
> > What boolean attribute would that be?
> 
> The mozNoFilter attribute we added in Firefox 4.

On Wed, 4 May 2011, Aryeh Gregor wrote:
>
> I don't see any use-case where you wouldn't want to use mozNoFilter. Why 
> doesn't it just work that way always?

On Mon, 9 May 2011, Mounir Lamouri wrote:
> 
> Basically, when you want to use the datalist to suggest a few things you 
> might not want to filter and when the list is long, you very likely want 
> to filter.
> 
> You might not want to filter when the list is a real set of suggestions 
> and you can type anything else. For example, a field in a support form 
> can ask you "What is your problem?" and you could type a brief summary 
> but some pre-written issues will be available. It's equivalent to a 
> select element followed by an input field that you can use if you select 
> "other" in the list. As I see it, when you filter, you have a very long 
> list and you very likely want the user to select something in the list 
> like a list of bugzilla emails, a list o metro stations, etc. Writing 
> anything not in the list might not work.

So why don't you just automatically filter if the list is long, and not 
filter if the list is short?

I don't really understand the reason for this attribute.



I haven't added anything to the spec yet.

I think mozNoFilter is unnecessary; UAs should be clever enough to 
determine when the UI would be better with filtering and when it would be 
better without. This seems rather trivial as it is (just filter when the 
list is greater than seven, and don't filter the list to zero unless 
you're confident that none of the suggestions apply at all).

I think there is a use case for script- or server-driven suggestions for 
which we could do a more targetted feature, distinct from the current 
feature which is optimised for the static autocomplete combo box case. 
However, I think we should wait a while to get the implementations 
solidified and to see how people use the current feature before adding 
more stuff here.

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

From ian at hixie.ch  Thu Jul 28 18:07:03 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 01:07:03 +0000 (UTC)
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > <select> in a <datalist> is completely ignored for form submission. In 
> > fact, any form element at all in <datalist> is ignored for form 
> > submission. See the "construct the form data set" algorithm:
> >
> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
> >
> > It's so that you can do things like:
> >
> > ? <input ... list=options>
> > ? <datalist id=options>
> > ? ? <select ...>
> > ? ? ? <option>...</option>
> > ? ? </select>
> > ? ? ...maybe other form controls here...
> > ? </datalist>
> >
> > Basically everything in the <datalist> except the <option> elements is 
> > for fallback in legacy UAs and is ignored in new UAs.
> 
> Couldn't this be accomplished using a few lines of javascript?

Not when scripts are disabled, no.


> That seems like a better solution than one that for all eternity adds 
> browser code complexity both to do a deep search for <option> elements 
> when building the list for <datalist>, and that requires walking the 
> parent chain whenever submitting form controls.

It doesn't seem that bad. Surely code for both of those is so widely used 
in a browser that both of those operations are basically one-liners.

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

From ian at hixie.ch  Thu Jul 28 18:15:51 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 01:15:51 +0000 (UTC)
Subject: [whatwg] link.sizes and [PutForwards=value]
In-Reply-To: <BANLkTin_kiRTHBZ5zHyLRQECHq5QVSoXbQ@mail.gmail.com>
References: <4CB709B6.5040706@helsinki.fi>
	<op.vkl8act164w2qv@anne-van-kesterens-macbook-pro.local>
	<4CB88535.9070007@helsinki.fi>
	<Pine.LNX.4.64.1101050126330.29066@ps20323.dreamhostps.com>
	<4D2444C8.8040502@gmail.com>
	<Pine.LNX.4.64.1105022326190.19153@ps20323.dreamhostps.com>
	<BANLkTi=me4SCesFWo-QM8tc2J8whmO=jmA@mail.gmail.com>
	<BANLkTin_kiRTHBZ5zHyLRQECHq5QVSoXbQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107290107420.2079@ps20323.dreamhostps.com>

On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 4:37 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 5 Jan 2011, Mounir Lamouri wrote:
> >> On 01/05/2011 02:29 AM, Ian Hickson wrote:
> >> > On Thu, 14 Oct 2010, Olli Pettay wrote:
> >> >>
> >> >> may I wonder why on earth any new API, like link.sizes uses 
> >> >> PutForwards? IMHO, PutForwards should be limited to the awkward 
> >> >> DOM0 APIs like window.location.
> >> >
> >> > On Fri, 15 Oct 2010, Olli Pettay wrote:
> >> >>
> >> >> It makes getters and setters work in a very different way. 
> >> >> Inconsistency in APIs isn't a good thing.
> >> >
> >> > The idea is to make the attribute appear to work like a DOMString 
> >> > for most purposes, but to allow methods to be invoked on it. (All 
> >> > the attributes that have [PutForwards] set also have a stringifier 
> >> > on their object's interface.)
> >>
> >> Is there a use case for [PutForwards] (except saving a few characters 
> >> for the authors) that could justify the inconsistency?
> >
> > The idea is to be consistent with all the other reflecting attributes, 
> > which can mostly all be treated as either strings or numbers. Contrast 
> > this with the way attributes are reflected in SVG, where there's a 
> > step of indirection to get to the string value due to the animation 
> > API. I think this is a case where [PutForwards] and stringification 
> > makes sense.
> 
> It's inconsistent in that all other objects in javascript stringify to 
> "[Object Foo]", whereas this object doesn't.

[PutForwards] doesn't affect that, that's the stringifier. Location, <a>, 
and <area> all already have stringifiers, as do lots of objects in JS.

Are we really concerned about objects stringifying to "[Object Foo]"?

It seems that the usefulness of such stringification is far outweighed by 
the usefulness of being able to treat the attribute as a string attribute 
like any other reflecting attribute while also being able to use methods 
on it. In fact, it is consistent with every DOMString attribute: they 
don't stringify to "[Object String]", yet you can call methods on them. 
What's the difference?


> If the concern is that link.sizes should be consistent with other 
> attribute-mapping properties then you're only half-way there since 
> typeof tests still behaves differently.

I'm not particularly concerned about such edge cases (who does typeof on 
reflecting attributes in a way where the difference here would matter?). 
It's the common use that I'm concerned about.


> I definitely agree that the way SVG does it is not ideal. How about 
> simply creating a second property, like link.parsedSizes which returns 
> the tokenlist?

That's what we're doing (for legacy reasons) with className/classList and 
rel/relList, but I consider that an ugly and unfortunate wart on the API. 
As much as possible, attributes that take space-separated lists are using 
DOMSettableTokenList to avoid this (including a few legacy ones that 
aren't as high-profile as class and rel).


On Mon, 2 May 2011, Jonas Sicking wrote:
> 
> Of course, an even simpler solution is to remove access to a 
> DOMTokenList representing link.sizes entirely. What is the use case? Is 
> it really that common to modify link.sizes that we need syntax sugar for 
> it?

All the space-separated lists are exposed this way. It would be rather odd 
to exclude just one on the basis that we couldn't think of a reason why 
this particular one would get changed much.

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


From bzbarsky at MIT.EDU  Thu Jul 28 18:59:07 2011
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 28 Jul 2011 21:59:07 -0400
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
References: <4DDFF77F.9050605@mit.edu>	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>	<4DFB8783.7070802@mit.edu>
	<4DFB8C23.7070808@mit.edu>	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>	<4DFB9F2D.3070404@mit.edu>	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
Message-ID: <4E3213EB.8020508@mit.edu>

On 7/28/11 6:05 PM, Anne van Kesteren wrote:
> So the SVG WG discussed this and they would like this as well. (They
> basically want the same behavior as HTML has here and converge as much
> as possible.) The change to the current mechanism required for SVG is to
> expose an "evt" variable somehow in scope of the Function.

Why, exactly?  I thought for SVG the "evt" thing was only relevant for 
content attributes, not IDL attributes.

> Now does it make sense to have the IDL attributes on Element but not
> have the content attributes on all elements? That would mean it still
> depends on the markup language what you can use as on* attributes which
> is not very straightforward.

It might make sense to look into that too; I did not propose it because 
that's not what UAs do right now.  At least Gecko doesn't; I didn't look 
at others.

-Boris



From jonas at sicking.cc  Thu Jul 28 19:34:17 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 28 Jul 2011 19:34:17 -0700
Subject: [whatwg] Form element invalid message
In-Reply-To: <Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei8Xw_PkKRVKbH482mJ+v=14x_p6GOyqFTwitorH3ZO=Cg@mail.gmail.com>

On Wed, Jul 27, 2011 at 5:21 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Apr 2011, Jonas Sicking wrote:
>> On Fri, Apr 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Wed, 29 Dec 2010, Mounir Lamouri wrote:
>> >> On 12/29/2010 07:41 AM, Ian Hickson wrote:
>> >> >>
>> >> >> I actually think that the customerrormessage attribute that has
>> >> >> been suggested is a decent solution too. [...]
>>
>> For example, if I go to www.google.com and click on the "sign in" link
>> at the top, then without entering anything press the "sign in" button.
>> At this point the page displays a error message in red that says "Enter
>> your email address." [...]
>>
>> In general it makes a lot of sense to want to display a different
>> message when the user has failed to enter a valid value in a field.
>> Clearly the user failed to enter what was requested the first time, and
>> so the context around the field was not enough for the user to enter
>> what was requested. Hence a more detailed description is appropriate.
>> >
>> > I don't understand how such an attribute would work. Take <input
>> > type=number> for example, with an explicit min, max, step, etc. How
>> > would you know what value to put in the attribute? There are going to
>> > be different needs when the control's value is too low, too high, not
>> > aligned to a step, missing, etc.
>>
>> Consider the example above from googles login page. Here there are two
>> possible errors:
>>
>> 1. The field is empty
>> 2. The field doesn't contain an email address
>>
>> In both cases the message "Enter your email address." seems appropriate.
>> And it seems better than what we as a browser could generate.
>
> A text input field could have a number of error conditions:
>
> ? <label> Offer code:
> ? ?<input type=text maxlength=8 pattern="[a-z1-9]+" required>
> ? </label>
>
> Suppose the code is printed as two groups of four characters, for example
> something like "1A2B 3C4D".
>
> The user could have entered the code with the space (the site doesn't want
> the space). Or the user could have read an O as a 0 (the code never has
> any zeroes to avoid that). Or the user could have forgotten to enter the
> code. In each of these cases, I think you'd want a different message.
>
>
> Anyway. I guess we can have a dedicated attribute that user agents can use
> to provide a message, rather than the current solution of just using the
> title="" attribute for pattern=""'s error message. If it's present, user
> agents could use it to replace or augment their message, and authors could
> make the message more specific by dynamically changing the attribute when
> during the 'invalid' event handler.
>
> ? <label> Offer code:
> ? ?<input type=text maxlength=8 pattern="[a-z1-9]+" required
> ? ? ? ? ? oninput="setCustomValidity(input.match(/0/) ?
> ? ? ? ? ? ? ? ? ? ?'Codes contain no zeroes, only Os.' : '')"
> ? ? ? ? ? validitymessage="Enter the code without spaces.">
> ? </label>
>
>
> If we add this, do you think it should be displayed with, instead of, or
> replaced by the setCustomValidity() message, when both are given?

I don't feel strongly which would be given precedence. On one hand it
seems simpler and more consistent to *always* use the attribute, and
thus give it precedence over setCustomValidity. On the other hand it
seems weird to make setCustomValidity ignore its argument. On the
third hand, it seems likely that people would end up having to
duplicate the same string in the attribute as in the argument to
setCustomValidity. On the fourth hand it would be easy to do
elem.setCustomValidity(elem.customerror).

/ Jonas


From cmhjones at gmail.com  Fri Jul 29 04:32:44 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 12:32:44 +0100
Subject: [whatwg] Proposal to extend registerProtocolHandler
In-Reply-To: <CALmvxBf3+3g5eH1CG3yFEeF8sfOjJM05hp+X184iFaq5zyOT=A@mail.gmail.com>
References: <BANLkTi=7dVCy6iWtmMScWOfQdt=CSzdEKA@mail.gmail.com>
	<Pine.LNX.4.64.1107222232070.2079@ps20323.dreamhostps.com>
	<CALmvxBf3+3g5eH1CG3yFEeF8sfOjJM05hp+X184iFaq5zyOT=A@mail.gmail.com>
Message-ID: <2E5F42EB-F195-4583-ADD0-29B5705DD55D@gmail.com>

This kind of permission may be synonymous with that of geolocation privileges and their explcit management requirements.

See this thread for discussion on this:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032631.html

Thanks,
Cameron Jones

On 26/07/2011, at 4:31 AM, James Kozianski wrote:

> Hi Ian,
> 
> Here are the use cases I had in mind:
> 
> 1. Allow sites to conditionally show UI to promote the advantages of
> registering the site as a handler.
>   (requires isRegistered)
> 
> 2. Allow sites to provide settings screens which allow users to register
> / deregister handlers from within the site.
>   (requires isRegistered, and deregisterProtocolHandler)
> 
> The presence of an ignored list - sites who don't have permission to use
> registerProtocolHandler - necessitates Michael Davidson's suggestion that
> isRegistered() should return a tri-state value (REGISTERED, DECLINED,
> NOTASKED). Otherwise sites that have been 'ignored' by a user won't be able
> to tell if they should show their promotional UI or not.
> 
> Cheers,
> James
> 
> 
> On Sat, Jul 23, 2011 at 8:33 AM, Ian Hickson <ian at hixie.ch> wrote:
> 
>> On Thu, 21 Apr 2011, James Kozianski wrote:
>>> 
>>> I'd like to propose the following changes to the registerProtocolHandler
>>> spec. [...]
>> 
>> Before I study the proposals in detail, is there a description of the
>> kind of experience we're trying to enable here?
>> 
>> What are the UIs we expect to see page use wih registerProtocolHandler()?
>> 
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> 



From cmhjones at gmail.com  Fri Jul 29 05:10:10 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 13:10:10 +0100
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <BANLkTi=LG=k0xQ+PZZSN8e=ot1t9p5hpgg@mail.gmail.com>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<op.vtxacccbo84pey@pc36.virtualebrana>
	<BANLkTi=LG=k0xQ+PZZSN8e=ot1t9p5hpgg@mail.gmail.com>
Message-ID: <DED83CC8-3719-4945-8F8F-273BB7B15981@gmail.com>


On 15/04/2011, at 10:56 PM, Aryeh Gregor wrote:
> Trying to add more features to the
> new form stuff is premature when we only have one really good
> implementation (IMO: Gecko's), and that implementation is partial.
> The time to talk about new features is when we have some amount of
> stability and interoperability in existing features.

However, features resulting from new, or more clarified, requirements would seem to require immediate attention in order to avoid such 'complete' implementations and their expectation of validity and continuance.

Thanks,
Cameron Jones

From cmhjones at gmail.com  Fri Jul 29 05:11:03 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 13:11:03 +0100
Subject: [whatwg] Decimal comma in numeric input
In-Reply-To: <4E211923.1080608@cs.tut.fi>
References: <273A0E8BC9384EC7B421122859493331@JukanPC>
	<1302774012.2116.80.camel@shuttle>
	<21B04E943C1341F0A867C1234DB30723@JukanPC>
	<BANLkTi=_8R2CRbTcXSFtSVAsD66682rznQ@mail.gmail.com>
	<A55C1FCDFFB64FC691F042DEC8F33905@JukanPC>
	<Pine.LNX.4.64.1107152053500.2079@ps20323.dreamhostps.com>
	<4E211923.1080608@cs.tut.fi>
Message-ID: <EC14C220-7ADB-4317-9409-4851532A2C4F@gmail.com>


On 16/07/2011, at 5:52 AM, Jukka K. Korpela wrote:

> 16.07.2011 00:01, Ian Hickson wrote:
> 
>> Much discussion on this topic happened when we started on this work in
>> 2004 and 2005, I highly recommend perusing the archives around that time.
> 
> Authors and implementors will need to be able to understand the topic without checking discussions archives, so the specs should say at least a little about the issue that the rules for user?s input may be quite different from the rules for the as stored and forwared. And users will be confused anyway, when user interfaces work oddly.

Yes, or if you have the knowledge of these discussions perhaps some additional assistance in locating any specific items would be helpful? 

>> On Thu, 14 Apr 2011, John Tamplin wrote:
>>> 
>>> The entire web application, which includes both client and server-side
>>> code, must have the same idea about what locale the user is using.  If
>>> the app provides a drop-down box or preference setting to choose a
>>> different locale, as most localized apps do, the web browser has to be
>>> using the same locale for any native locale processing it uses.
>>> Otherwise, you run a serious risk of having incorrect data -- if a user
>>> types "10,000" in a field when they think they are using a locale with a
>>> comma as the decimal separator, does the app receive that as 10000 or
>>> 10.000?  If the app is running in en-US because the user requested it or
>>> their system locale isn't supported by the app, and the browser sends
>>> "10.000" as the value because the system locale is "de", then that is a
>>> problem.
>> 
>> Indeed. To solve this, we need help from CSS. That's one of the reasons we
>> created<output>  in HTML.
> 

Concerned about <output>.

> This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. It will probably cause _further_ confusion.
> 
> I?m afraid the new input types for numeric data and for dates and times, even when implemented in browsers, will be of very limited usefulness and will cause more damage than good, unless the localization issues will be properly addressed.
> 
> It is part of the risk that they often _seemingly_ work. For example, an author would use <input type=number> and test the software thoroughly by his own standards, but the standards don?t include testing with the system?s UI language being other than English. So things seem to work until someone tries to put a bid of 10,000 dollars but gets it turned to 10 dollars and loses, or makes a date for 7/4/2012 and gets it interpreted as April 7 when he meant July 4, or vice versa.
> 
> I?m afraid many authors will start using the new types eagerly when browser support comes sufficiently widespread. It looks so much better, cooler, and easier than parsing data yourself or requiring the user to type data in specifically instructed format. But it?s a dangerous illusion.
> 
> -- 
> Yucca, http://www.cs.tut.fi/~jkorpela/


Yes, i agree. I've opened a bug about the handling of i18n by user agents:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13408

In response to the question of how to manage the formatting and encoding of i18n data values, the element's declared or derived lang should be used. the form element also contains a lang attribute and it is this which should be used to encode the data for submission and processing, as the author has declared they expect to accept. ie:

<form lang="en-US">
	<input type="number" lang="fi"/>
	<input type="submit"/>
</form>

This input should parse and format the number in the Finish locale, and the form should encode the number in en-US locale.

Thanks,
Cameron Jones





From cmhjones at gmail.com  Fri Jul 29 05:30:30 2011
From: cmhjones at gmail.com (Cameron Heavon-Jones)
Date: Fri, 29 Jul 2011 13:30:30 +0100
Subject: [whatwg] proposal: extend <time> to markup durations
In-Reply-To: <Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
References: <CAOACb=LSSE0mhiSw9NLALcmAn_8_V9+bn4PW=2_Q0tW8P156vw@mail.gmail.com>
	<Pine.LNX.4.64.1107142133400.3775@ps20323.dreamhostps.com>
Message-ID: <AD1C2FBA-C958-42FE-9105-BA9474096BBE@gmail.com>


On 14/07/2011, at 10:36 PM, Ian Hickson wrote:
> I haven't studied the above yet, but I just wanted to bring up a trial 
> balloon for a possible alternative solution: drop <time> and replace it 
> with a generic solution.
> 
> There are several use cases for <time>:
> 
> A. Easier styling of dates and times from CSS.

This may be a case of a disconnect between what a programmer thinks of style compared to what a user thinks of style.

A localized user thinks that 1/1/01 is a date, whereas this is just a style of formatting to a programmer who thinks of date's in the non-ambigous serialization of 2001-01-01

The question: is i18n formatting stylistic or semantic? 

> 
> B. A way to mark up the publication date/time for an article (e.g. for 
> conversion to Atom).

I have concerns about the granularity of such an attribute as pubdate. 

> 
> C. A way to mark up machine-readable times and dates for use in 
> Microformats or microdata.
> 
> Use cases A and B do not seem to have much traction.
> 
> Use case C applies to more than just dates, and the lack of solution for 
> stuff outside dates and times is being problematic to many communities.
> 
> Proposal: we dump use cases A and B, and pivot <time> on use case C, 
> changing it to <data> and making it like the <abbr> for machine-readable 
> data, primarily for use by Microformats and HTML's microdata feature.
> 

This sounds like a great area of research in hope of a simpler, yet more flexible and generic solution.

The inclusion of date\time\etc may amount to a similar situation as encountered in HTML4 with it's stylistic attributes and their resulting obsoletion when a better solution is found, in that case it was CSS.

> 
> (I've also filed this as a bug here:
>   http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240
> I generally prefer to only have issues discussed either in e-mail or in a 
> bug, but Tantek informs me that for technical reasons he can't discuss 
> this on the bug and his input is more important to me than convention, 
> thus my bringing this up here again!)
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Thanks,
Cameron Jones

From gisolfi at us.ibm.com  Fri Jul 29 08:13:32 2011
From: gisolfi at us.ibm.com (Dan Gisolfi)
Date: Fri, 29 Jul 2011 11:13:32 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
Message-ID: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>

On behalf of the Open Cooperative Web Framework Project (
http://opencoweb.org), with respect to the HTML Editing APIs specification 
(http://aryeh.name/spec/editing/editing.html), it would seem the current 
version of the spec lacks APIs for getting / setting the caret
position.

An example scenario for such a requirement (addition of such methods) 
would be the following:
When developing an cooperative web enabled rich-text-editor, whereby 
multiple simultaneous users can co-author shared content, the editor must 
be able to allow each participant to get/set caret/cursor position in 
order to reflect the multiple positions of each active author in a 
cooperative web session.

Dan Gisolfi

From jonas at sicking.cc  Fri Jul 29 08:29:44 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 08:29:44 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>

On Thu, Jul 28, 2011 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 3 May 2011, Jonas Sicking wrote:
>> >>
>> >> It seems to me that a simple boolean attribute and a few lines of
>> >> script solves 80% of the use cases.
>> >
>> > What boolean attribute would that be?
>>
>> The mozNoFilter attribute we added in Firefox 4.
>
> On Wed, 4 May 2011, Aryeh Gregor wrote:
>>
>> I don't see any use-case where you wouldn't want to use mozNoFilter. Why
>> doesn't it just work that way always?
>
> On Mon, 9 May 2011, Mounir Lamouri wrote:
>>
>> Basically, when you want to use the datalist to suggest a few things you
>> might not want to filter and when the list is long, you very likely want
>> to filter.
>>
>> You might not want to filter when the list is a real set of suggestions
>> and you can type anything else. For example, a field in a support form
>> can ask you "What is your problem?" and you could type a brief summary
>> but some pre-written issues will be available. It's equivalent to a
>> select element followed by an input field that you can use if you select
>> "other" in the list. As I see it, when you filter, you have a very long
>> list and you very likely want the user to select something in the list
>> like a list of bugzilla emails, a list o metro stations, etc. Writing
>> anything not in the list might not work.
>
> So why don't you just automatically filter if the list is long, and not
> filter if the list is short?

I'm not a big fan of try-to-guess-what-the-author-wants-to-do
solutions like that. Guessing will likely be as often wrong and
annoying as it will be correct and helpful.

/ Jonas


From jonas at sicking.cc  Fri Jul 29 08:39:01 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 08:39:01 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>

On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 2 May 2011, Jonas Sicking wrote:
>> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >
>> > <select> in a <datalist> is completely ignored for form submission. In
>> > fact, any form element at all in <datalist> is ignored for form
>> > submission. See the "construct the form data set" algorithm:
>> >
>> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
>> >
>> > It's so that you can do things like:
>> >
>> > ? <input ... list=options>
>> > ? <datalist id=options>
>> > ? ? <select ...>
>> > ? ? ? <option>...</option>
>> > ? ? </select>
>> > ? ? ...maybe other form controls here...
>> > ? </datalist>
>> >
>> > Basically everything in the <datalist> except the <option> elements is
>> > for fallback in legacy UAs and is ignored in new UAs.
>>
>> Couldn't this be accomplished using a few lines of javascript?
>
> Not when scripts are disabled, no.

The number of cases when a site can use this solution to get an
acceptable UI *and* care about supporting users with scripts disabled
*and* is planning to roll out support within the timeframe when
there's some support for HTML5 forms, but not enough to rely on it, is
extremely small.

My experience is that it's much more likely that people will use other
solutions until there is wide enough browser support to reliably use
it, and then use javascript as a fallback and not care about users
with JS disabled. And that goes even if we add this feature or not.

>> That seems like a better solution than one that for all eternity adds
>> browser code complexity both to do a deep search for <option> elements
>> when building the list for <datalist>, and that requires walking the
>> parent chain whenever submitting form controls.
>
> It doesn't seem that bad. Surely code for both of those is so widely used
> in a browser that both of those operations are basically one-liners.

"It's easy to implement" is the worst reason ever to add a feature.

/ Jonas


From jonas at sicking.cc  Fri Jul 29 08:43:07 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 08:43:07 -0700
Subject: [whatwg] Form element invalid message
In-Reply-To: <4E30D965.6000704@cs.tut.fi>
References: <006301cb5914$9b35bf80$d1a13e80$@com>
	<AEC939FC-9BAF-40DC-844B-3ED8CD0646B4@googlemail.com>
	<001c01cb5a68$cc202b30$64608190$@com>
	<B7718345-A20D-4545-8121-CD0327896022@googlemail.com>
	<009401cb5aae$aee147c0$0ca3d740$@com>
	<Pine.LNX.4.64.1012290101070.26618@ps20323.dreamhostps.com>
	<4D1B0C2A.6010109@gmail.com>
	<AANLkTi=NOWv5T=2b7+fzvp5okzC0tgz7PTV-RVS1FX0_@mail.gmail.com>
	<Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
	<BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
	<Pine.LNX.4.64.1107272340510.2079@ps20323.dreamhostps.com>
	<4E30D965.6000704@cs.tut.fi>
Message-ID: <CA+c2ei_oGfVx5tzEuwP6SeoHGb9jN6iOBFKEtBefthECWoSLLg@mail.gmail.com>

On Wed, Jul 27, 2011 at 8:37 PM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 28.07.2011 03:21, Ian Hickson wrote:
>
>> A text input field could have a number of error conditions:
>
> Indeed. Therefore it would be essential to be able to set the error message
> for _each_ check that a browser is supposed to do on the basis of HTML
> markup alone.

That would require not just a message for each check, but a message
for all combinations of checks. That is for most practical purposes
not going to be a workable solution. This is why I think it's better
to let the page deal with checking the different combinations that it
desires and choose a message based on that.

> If this is not possible, it is easier to authors to code all
> data checking in JavaScript.

Yup, I think that's basically the situation.

>> I guess we can have a dedicated attribute that user agents can use
>> to provide a message, rather than the current solution of just using the
>> title="" attribute for pattern=""'s error message.
>
> The title="" attribute is generally supposed to contain an advisory title
> for an element, and deviating from this that way is very odd and confusing -
> especially since user agents may show its value in a tooltip or speak it out
> when entering the field.

Indeed. I think the extra use for @title is a bad idea and should be removed.

/ Jonas


From ian at hixie.ch  Fri Jul 29 09:28:15 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:28:15 +0000 (UTC)
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
Message-ID: <Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Dan Gisolfi wrote:
>
> On behalf of the Open Cooperative Web Framework Project ( 
> http://opencoweb.org), with respect to the HTML Editing APIs 
> specification (http://aryeh.name/spec/editing/editing.html), it would 
> seem the current version of the spec lacks APIs for getting / setting 
> the caret position.
> 
> An example scenario for such a requirement (addition of such methods) 
> would be the following: When developing an cooperative web enabled 
> rich-text-editor, whereby multiple simultaneous users can co-author 
> shared content, the editor must be able to allow each participant to 
> get/set caret/cursor position in order to reflect the multiple positions 
> of each active author in a cooperative web session.

Surely all but the local one would not be real carets?

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


From ian at hixie.ch  Fri Jul 29 09:29:27 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:29:27 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> > On Mon, 9 May 2011, Mounir Lamouri wrote:
> >>
> >> Basically, when you want to use the datalist to suggest a few things 
> >> you might not want to filter and when the list is long, you very 
> >> likely want to filter.
> >>
> >> You might not want to filter when the list is a real set of 
> >> suggestions and you can type anything else. For example, a field in a 
> >> support form can ask you "What is your problem?" and you could type a 
> >> brief summary but some pre-written issues will be available. It's 
> >> equivalent to a select element followed by an input field that you 
> >> can use if you select "other" in the list. As I see it, when you 
> >> filter, you have a very long list and you very likely want the user 
> >> to select something in the list like a list of bugzilla emails, a 
> >> list o metro stations, etc. Writing anything not in the list might 
> >> not work.
> >
> > So why don't you just automatically filter if the list is long, and 
> > not filter if the list is short?
> 
> I'm not a big fan of try-to-guess-what-the-author-wants-to-do solutions 
> like that. Guessing will likely be as often wrong and annoying as it 
> will be correct and helpful.

Showing the user an autocomplete list with hundreds of entries is going to 
be far more annoying.

This to me seems to be entirely a UI issue.

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


From gisolfi at us.ibm.com  Fri Jul 29 09:38:35 2011
From: gisolfi at us.ibm.com (Dan Gisolfi)
Date: Fri, 29 Jul 2011 12:38:35 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
Message-ID: <OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>

Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:28:15 PM:

> From: Ian Hickson <ian at hixie.ch>
> To: Dan Gisolfi/Somers/IBM at IBMUS
> Cc: whatwg at lists.whatwg.org, ayg at aryeh.name
> Date: 07/29/2011 12:28 PM
> Subject: Re: [whatwg] [editing] Caret Position Access Methods
> 
> On Fri, 29 Jul 2011, Dan Gisolfi wrote:
> >
> > On behalf of the Open Cooperative Web Framework Project ( 
> > http://opencoweb.org), with respect to the HTML Editing APIs 
> > specification (http://aryeh.name/spec/editing/editing.html), it would 
> > seem the current version of the spec lacks APIs for getting / setting 
> > the caret position.
> > 
> > An example scenario for such a requirement (addition of such methods) 
> > would be the following: When developing an cooperative web enabled 
> > rich-text-editor, whereby multiple simultaneous users can co-author 
> > shared content, the editor must be able to allow each participant to 
> > get/set caret/cursor position in order to reflect the multiple 
positions 
> > of each active author in a cooperative web session.
> 
> Surely all but the local one would not be real carets?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Not sure what you mean by "real caret", but the scenario implies that each 
co-authoring conference(session) participant would have a corresponding 
cursor (caret) position depicting their associated reference point for 
edits. 

From ian at hixie.ch  Fri Jul 29 09:43:47 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:43:47 +0000 (UTC)
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 2 May 2011, Jonas Sicking wrote:
> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> >
> >> > <select> in a <datalist> is completely ignored for form submission. In
> >> > fact, any form element at all in <datalist> is ignored for form
> >> > submission. See the "construct the form data set" algorithm:
> >> >
> >> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
> >> >
> >> > It's so that you can do things like:
> >> >
> >> > ? <input ... list=options>
> >> > ? <datalist id=options>
> >> > ? ? <select ...>
> >> > ? ? ? <option>...</option>
> >> > ? ? </select>
> >> > ? ? ...maybe other form controls here...
> >> > ? </datalist>
> >> >
> >> > Basically everything in the <datalist> except the <option> elements is
> >> > for fallback in legacy UAs and is ignored in new UAs.
> >>
> >> Couldn't this be accomplished using a few lines of javascript?
> >
> > Not when scripts are disabled, no.
> 
> The number of cases when a site can use this solution to get an 
> acceptable UI *and* care about supporting users with scripts disabled 
> *and* is planning to roll out support within the timeframe when there's 
> some support for HTML5 forms, but not enough to rely on it, is extremely 
> small.

That's possible. The entire Web Forms 2 feature set is designed with this 
kind of fallback in mind, though.


> My experience is that it's much more likely that people will use other 
> solutions until there is wide enough browser support to reliably use it, 
> and then use javascript as a fallback and not care about users with JS 
> disabled. And that goes even if we add this feature or not.

If that's the case, we should probably rethink the entire design of the 
WF2 features, because maybe there's better ways to do things.

Looking specifically at <datagrid>'s ability to fall back to <select>, I 
agree that it's not necessarily doing to be widely used, but given that 
it's so simple to support and provides such a clean way to do fallback, I 
really don't see the harm in supporting it.


> >> That seems like a better solution than one that for all eternity adds 
> >> browser code complexity both to do a deep search for <option> 
> >> elements when building the list for <datalist>, and that requires 
> >> walking the parent chain whenever submitting form controls.
> >
> > It doesn't seem that bad. Surely code for both of those is so widely 
> > used in a browser that both of those operations are basically 
> > one-liners.
> 
> "It's easy to implement" is the worst reason ever to add a feature.

It's not the reason to add the feature. I'm just saying that browser 
complexity in this case isn't a reason to _remove_ the feature.

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

From ian at hixie.ch  Fri Jul 29 09:47:08 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 16:47:08 +0000 (UTC)
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
	<OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
Message-ID: <Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Dan Gisolfi wrote:
> Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:28:15 PM:
> > >
> > > An example scenario for such a requirement (addition of such 
> > > methods) would be the following: When developing an cooperative web 
> > > enabled rich-text-editor, whereby multiple simultaneous users can 
> > > co-author shared content, the editor must be able to allow each 
> > > participant to get/set caret/cursor position in order to reflect the 
> > > multiple positions of each active author in a cooperative web 
> > > session.
> > 
> > Surely all but the local one would not be real carets?
> 
> Not sure what you mean by "real caret"

By "real caret" I mean a caret that supports all the complexity of the 
system caret: relationship to the system selection, being movable by the 
user, effect on execCommand() APIs, effect on local system focus, etc.


> but the scenario implies that each co-authoring conference(session) 
> participant would have a corresponding cursor (caret) position depicting 
> their associated reference point for edits.

I don't think those are system carets. Why wouldn't using a <span> element 
be sufficient for this?

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


From ian at hixie.ch  Fri Jul 29 10:05:12 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 17:05:12 +0000 (UTC)
Subject: [whatwg] sic element
In-Reply-To: <51294D8114214B45AF44C1F847FA8E94@Vodka6000>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
Message-ID: <Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Jukka K. Korpela wrote:
> 
> But I'm afraid we cannot completely put aside the issue. The reason is 
> that recently the <u> element was promoted from obsolete physical markup 
> to conforming semantic markup, though with semantics that really 
> confuses me: "The u element represents a span of text with an 
> unarticulated, though explicitly rendered, non-textual annotation, such 
> as labeling the text as being a proper name in Chinese text (a Chinese 
> proper name mark), or labeling the text as being misspelt."
> 
> So the question "which markup should I use to indicate a word as 
> intentionally misspelt?" is currently "the <u> element".

You may use the <u> element to mark up an element that is misspelt. I 
wouldn't say "should", and the intention is orthogonal to the element's 
definition. In fact, given the element's definition, you equally use it to 
mark up words that are intentionally spelt _correctly_. The point is just 
that <u> is used to explicitly annotate some text without saying why in a 
textual manner. This makes it quite distinct from [sic], which is an 
explicitly articulated annotation.


> This sounds somewhat unnatural, though, since in the absence of 
> stylesheet rules for <u>, and when styles are disabled, <u> is rendered 
> as underlined in visual presentation. This tends to draw attention more 
> than is desirable in most situations.

I would not expect authors to use <u> where [sic] is appropriate.

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


From ian at hixie.ch  Fri Jul 29 10:08:17 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 17:08:17 +0000 (UTC)
Subject: [whatwg] Submit controls should be barred from constraint
 validation in favor of a new pseudo-class
In-Reply-To: <4DBFE155.40008@gmail.com>
References: <4C9BD80F.9000806@gmail.com>
	<Pine.LNX.4.64.1012310114340.28593@ps20323.dreamhostps.com>
	<4D1DB69A.1060902@gmail.com>
	<Pine.LNX.4.64.1105022241460.19153@ps20323.dreamhostps.com>
	<4DBFE155.40008@gmail.com>
Message-ID: <Pine.LNX.4.64.1107291707000.1701@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Mounir Lamouri wrote:
> On 05/02/2011 10:44 PM, Ian Hickson wrote:
> > On Fri, 31 Dec 2010, Mounir Lamouri wrote:
> > > On 12/31/2010 02:20 AM, Ian Hickson wrote:
> > > > far as I can tell. Anything that's visible and submitted is a candidate
> > > > for constraint validation.
> > > 
> > > Except<keygen>  and<object>.
> > > But do we agree that "it's visible and submittable so it should be able
> > > to be invalid" is not a sane rule? At least, we should not include
> > > non-editable but visible submittable controls like submit controls.
> > 
> > This only affects people who go out of their way to make submit controls
> > invalid, right? I guess I don't really care one way or the other, but it
> > seems easier all around to just make things as consistent as possible and
> > just allow it.
> > 
> > At the end of the day, on this, I'll spec whatever gets implemented. Do we
> > have multiple implementations one way or the other yet?
> 
> Opera 11.20 allows submit controls to be invalid and Gecko (since 2.0) 
> does not. I haven't check Webkit but IIRC, it has the same behavior as 
> Opera.

Indeed.

In fact, in testing this I found that the resulting UI would actually be 
kind of useful in certain scenarios. For example, an EULA "decline" button 
could be marked invalid with the message "If you decline this license 
agreement, you cannot use this site" or some such.

I've left the spec as is for now. I don't see much value in preventing 
submit buttons from being able to participate in this mechanism.

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


From ian at hixie.ch  Fri Jul 29 10:34:18 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 17:34:18 +0000 (UTC)
Subject: [whatwg] self-closing tags in html5
In-Reply-To: <31617157.post@talk.nabble.com>
References: <i7vd5ss1r3.fsf@hilbert.math.albany.edu> <4C9FAA89.3010400@mit.edu>
	<Pine.LNX.4.64.1012310303140.28593@ps20323.dreamhostps.com>
	<op.vok6yfgyte2ec8@aimac.local> <31617157.post@talk.nabble.com>
Message-ID: <Pine.LNX.4.64.1107291726280.1701@ps20323.dreamhostps.com>

On Tue, 3 May 2011, Roger H?gensen wrote:
> 
> Is there a need for say a <pbr> ? (short for paragraph break) default 
> behavior being the same as two <br>.

Isn't that just two paragraphs separate from each other?


  <p> ... </p> <p> ... </p>


> Then again getting folks to change would be hard, so maybe a <cp> and 
> </cp> would make more sense. (closed paragraph)

How is that different from <p>?


> Myself I always tend to use <br><br> for readability when I don't feel 
> like the text should be split into different paragraphs. And I use <p> 
> and </p> for it's intended purpose, to markup actual paragraphs.
> 
> Now if <p> was turned into a synonym for <br><br> and </p> simply 
> ignored, I'd be happy to move to using say <cp> and </cp> for 
> paragraphs.

I'm pretty sure that's a non-starter from a compatibility persepective.


On Sat, 14 May 2011, yuhong wrote:
>
> FYI, the reason is that IE5 supported mixing foreign XML content into 
> HTML long before HTML5 added this support. It is used for VML for 
> example.

Note that this support has been removed from IE10.

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

From gisolfi at us.ibm.com  Fri Jul 29 11:07:57 2011
From: gisolfi at us.ibm.com (Dan Gisolfi)
Date: Fri, 29 Jul 2011 14:07:57 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
	<OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
	<Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>
Message-ID: <OF3175D5B4.23130152-ON852578DC.00628044-852578DC.00639B8D@us.ibm.com>

Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:47:08 PM:

> From: Ian Hickson <ian at hixie.ch>
> To: Dan Gisolfi/Somers/IBM at IBMUS
> Cc: whatwg at lists.whatwg.org, ayg at aryeh.name
> Date: 07/29/2011 12:47 PM
> Subject: Re: [whatwg] [editing] Caret Position Access Methods
> 
> On Fri, 29 Jul 2011, Dan Gisolfi wrote:
> > Ian Hickson <ian at hixie.ch> wrote on 07/29/2011 12:28:15 PM:
> > > >
> > > > An example scenario for such a requirement (addition of such 
> > > > methods) would be the following: When developing an cooperative 
web 
> > > > enabled rich-text-editor, whereby multiple simultaneous users can 
> > > > co-author shared content, the editor must be able to allow each 
> > > > participant to get/set caret/cursor position in order to reflect 
the 
> > > > multiple positions of each active author in a cooperative web 
> > > > session.
> > > 
> > > Surely all but the local one would not be real carets?
> > 
> > Not sure what you mean by "real caret"
> 
> By "real caret" I mean a caret that supports all the complexity of the 
> system caret: relationship to the system selection, being movable by the 

> user, effect on execCommand() APIs, effect on local system focus, etc.
> 
> 
> > but the scenario implies that each co-authoring conference(session) 
> > participant would have a corresponding cursor (caret) position 
depicting 
> > their associated reference point for edits.
> 
> I don't think those are system carets. Why wouldn't using a <span> 
element 
> be sufficient for this?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

My example use case is pertinent to a collaboration environment. In such a 
case the web developer would handle the remote vs. local caret issues 
using our framework.

My point herein and motivation for the suggestion is that this 
functionality (get/set caret) is available in the textarea element. Using 
a textarea element you can get/set caret position via 
get/setSelectionRange(). These two methods should be implemented for a 
contentEditable div or the likes. Within a contentEditable div, there is 
no way to [a] tell where the caret is in relation to the text, such as the 
index; [b] direct the caret to a specific position within the text.

My assumptions is that such a request would be within the scope of the 
HTML Edit API spec. If I am mistaken, my apologies.

Dan Gisolfi

From rniwa at webkit.org  Fri Jul 29 11:14:40 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Fri, 29 Jul 2011 11:14:40 -0700
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF3175D5B4.23130152-ON852578DC.00628044-852578DC.00639B8D@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
	<Pine.LNX.4.64.1107291627420.18680@ps20323.dreamhostps.com>
	<OF5E3EB807.86521E4A-ON852578DC.005B0F9D-852578DC.005B6D00@us.ibm.com>
	<Pine.LNX.4.64.1107291644200.18680@ps20323.dreamhostps.com>
	<OF3175D5B4.23130152-ON852578DC.00628044-852578DC.00639B8D@us.ibm.com>
Message-ID: <CABNRm62hPRf6FDTBiGx1eTq9rmr+jdbs-_E22V0ZnX70h1wJ3A@mail.gmail.com>

On Fri, Jul 29, 2011 at 11:07 AM, Dan Gisolfi <gisolfi at us.ibm.com> wrote:
>
> My point herein and motivation for the suggestion is that this
> functionality (get/set caret) is available in the textarea element. Using
> a textarea element you can get/set caret position via
> get/setSelectionRange(). These two methods should be implemented for a
> contentEditable div or the likes. Within a contentEditable div, there is
> no way to [a] tell where the caret is in relation to the text, such as the
> index; [b] direct the caret to a specific position within the text.
>

So what you want is Range/Selection <-> TextIndex API?  I think that makes a
sense.  Ideally such an API provide an index of selection/range within the
textContent of the editing host.  WebKit already implements very similar
mechanism internally and use it extensively in editing, spell checking, and
IME code.

- Ryosuke


From Simetrical+w3c at gmail.com  Fri Jul 29 11:24:12 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 29 Jul 2011 14:24:12 -0400
Subject: [whatwg] [editing] Caret Position Access Methods
In-Reply-To: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
References: <OF5A67D357.8EC9B728-ON852578DC.00523973-852578DC.0053A381@us.ibm.com>
Message-ID: <CAKA+AxnOuEro=bp3uR36=xcHMjT-ZwSRvZZgop89GqLBP7bLEw@mail.gmail.com>

On Fri, Jul 29, 2011 at 11:13 AM, Dan Gisolfi <gisolfi at us.ibm.com> wrote:
> On behalf of the Open Cooperative Web Framework Project
> (http://opencoweb.org), with respect to the HTML Editing APIs specification
> (http://aryeh.name/spec/editing/editing.html), it would seem the current
> version of the spec lacks APIs for getting / setting the caret
> position.

As far as I can tell, this is covered by the Selection interface in DOM Range:

http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface

Anne van Kesteren, Ms2ger, and I have agreed that it probably makes
sense to move the Selection part of DOM Range into the editing spec
and the Range part into DOM Core at some point, but for now it's in a
separate specification.

> An example scenario for such a requirement (addition of such methods) would
> be the following:
> When developing an cooperative web enabled rich-text-editor, whereby
> multiple simultaneous users can co-author shared content, the editor must be
> able to allow each participant to get/set caret/cursor position in order to
> reflect the multiple positions of each active author in a cooperative web
> session.

The Selection interface and getSelection() will allow you to inspect
and modify the selection (and cursor position, which is just one side
or other of the selection) of the current user, meaning the place that
will be affected when the user types or such.  Is this all you need,
or is there something missing from it?

On Fri, Jul 29, 2011 at 2:07 PM, Dan Gisolfi <gisolfi at us.ibm.com> wrote:
> My point herein and motivation for the suggestion is that this functionality
> (get/set caret) is available in the textarea element. Using a textarea
> element you can get/set caret position via get/setSelectionRange(). These
> two methods should be implemented for a contentEditable div or the likes.
> Within a contentEditable div, there is no way to [a] tell where the caret is
> in relation to the text, such as the index; [b] direct the caret to a
> specific position within the text.

getSelection() is very similar to the selectionStart, selectionEnd,
and setSelectionRange() properties on textareas.  It's more
complicated, though, because rich text is more complicated than plain
text.  Examples:

Collapse the selection and set the cursor to the beginning of a specific node:

  getSelection().collapse(node, 0)

Select characters three through five in a Text node, that's the first
child of a specific element:

  var range = document.createRange();
  range.setStart(element.firstChild, 3);
  range.setEnd(element.firstChild, 5);
  getSelection().removeAllRanges();
  getSelection().addRange(range);

Alternatively (simpler but does not work in some browsers):

  getSelection().collapse(element.firstChild, 3);
  getSelection().extend(element.firstChild, 5);

Retrieve the first range in the current selection:

  var range;
  if (getSelection().rangeCount) {
    // There is some cursor or selection
    range = getSelection().getRangeAt(0);
    // range is now a Range object that you can look at
  } else {
    // Nothing is selected and there is no cursor position
  }

If you see something missing from the Selection APIs that would be
useful to you, please say so.  This list is fine for feedback on DOM
Range.


From jkorpela at cs.tut.fi  Fri Jul 29 11:57:06 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Fri, 29 Jul 2011 21:57:06 +0300
Subject: [whatwg] sic element
In-Reply-To: <Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
Message-ID: <4E330282.2030404@cs.tut.fi>

29.07.2011 20:05, Ian Hickson wrote:

> The point is just
> that <u>  is used to explicitly annotate some text without saying why in a
> textual manner. This makes it quite distinct from [sic], which is an
> explicitly articulated annotation.

I fail to see how [sic] would be more explicit than underlining.

Anyway, aren't you saying that <u> says "this text is annotated but no 
annotation is given"? In that case, saying that <u> draws attention to 
its content might be more appropriate.

But the whole idea of transmogrifying the old <u> element, one of the 
simplest elements of traditional HTML, to some purportedly semantic 
element without saying what it _really_ means, is just doomed. Of 
course, it's not compatible with existing practice where <u> means 
underlining (and is therefore physical markup). But it also makes 
people's minds dizzy (to no avail) if they try to take the specs seriously.

I wonder what speech-based user agents are supposed to make out of <u>. 
The good old <u> is simple: you can either ignore it (saying that 
underlining has no recognizable meaning that could be conveyed in 
speech), or you can interpret it as some kind of emphasis, expressed by 
a change of voice somehow. But if the new <u> is supposed to be 
semantic, can it be ignored in speech? How do you express an explicit 
but completely unspecified "annotation"?

This really sounds like an odd game where HTML specs are meant to say to 
authors and to vendors of authoring software that they can keep using 
<u> as before (and pass validation), but when interrogated, they are 
supposed to tell that it does not mean underlining but... eh... explicit 
annotation without explicitly articulated annotation.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From chuck at jumis.com  Fri Jul 29 13:44:07 2011
From: chuck at jumis.com (Charles Pritchard)
Date: Fri, 29 Jul 2011 13:44:07 -0700
Subject: [whatwg] Canvas 2d: proposal to add path(DOMString)
Message-ID: <4E331B97.4010907@jumis.com>

Having spoken to several developers, I think that we're clear to add a 
new method to the canvas 2d api;
though there is some question about how it should be added.

The method would take a DOMString using SVG path semantics.

I'm not certain which route is better:
ctx.path('M....z')
or
ctx.fillPath('M ..z'), ctx.strokePath('M...z');

This usually takes ~80 lines of JavaScript to support,
we're eager to see it added to native implementations.

All browser vendors have SVG support now, and could easily re-use
code from their SVG implementations to implement this canvas 2d 
supplemental.


-Charles


From ayg at aryeh.name  Fri Jul 29 13:47:53 2011
From: ayg at aryeh.name (Aryeh Gregor)
Date: Fri, 29 Jul 2011 16:47:53 -0400
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
	implementer feedback
In-Reply-To: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
Message-ID: <CAKA+AxmVPg5yXV=Lo958ScZLX0pvKOLPVLWczyG7w5gNBnCMXA@mail.gmail.com>

On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> WebKit treats any font-weight above or equal to 600 as bold because that's
> what user sees, and boldness is a binary concept in execCommand; Firefox 5
> appears to do the same.
> WebKit compares colors in rgb/rgba format; e.g. red is first parsed as
> rgb(255, 0, 0). ?Firefox 5 seems to does the same as well.
> WebKit compares font sizes in legacy font size used in font element;
> See?CSSStyleSelector::legacyFontSize or?legacyFontSizeFromCSSValue in
> EditingStyle.cpp

Okay, I've now defined precisely how values have to be compared (in
two different ways), and painstakingly used them everywhere they're
necessary:

http://aryeh.name/tmp/editing/editing.html#equivalent-values

This should be well-defined now.

On Thu, Jul 28, 2011 at 4:31 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> WebKit fires those events :( ?I don't know why we do that. ?I think it's a
> WebKit bug but I'm just pointing that out in the case there are some
> websites out there that depends on this quirky behavior. ?Just
> cut/copy/paste for now as far as I know.

How do the cut/copy/paste commands work at all in WebKit?  I tried
using them but they did nothing.  queryCommandSupported() returns
false for all three.  Is there some special switch?


From ian at hixie.ch  Fri Jul 29 13:56:55 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 20:56:55 +0000 (UTC)
Subject: [whatwg] sic element
In-Reply-To: <4E330282.2030404@cs.tut.fi>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
Message-ID: <Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jukka K. Korpela wrote:
> 29.07.2011 20:05, Ian Hickson wrote:
> >
> > The point is just that <u> is used to explicitly annotate some text 
> > without saying why in a textual manner. This makes it quite distinct 
> > from [sic], which is an explicitly articulated annotation.
> 
> I fail to see how [sic] would be more explicit than underlining.

[sic] has an explicitly articulated meaning. Underlining, on the other 
hand, does not; it is an annotation but the reader cannot know, without 
context, what its meaning is.


> Anyway, aren't you saying that <u> says "this text is annotated but no 
> annotation is given"? In that case, saying that <u> draws attention to 
> its content might be more appropriate.

The physical line is an annotation. It's just not articulated.


> But the whole idea of transmogrifying the old <u> element, one of the 
> simplest elements of traditional HTML, to some purportedly semantic 
> element without saying what it _really_ means, is just doomed.

Doomed in what sense? If you are concerned that people are going to use it 
for a different meaning that it has, then the whole language suffers from 
this problem and so calling this one out specifically as "doomed" seems to 
be a case of missing the wood for the trees.


> I wonder what speech-based user agents are supposed to make out of <u>. 
> The good old <u> is simple: you can either ignore it (saying that 
> underlining has no recognizable meaning that could be conveyed in 
> speech), or you can interpret it as some kind of emphasis, expressed by 
> a change of voice somehow. But if the new <u> is supposed to be 
> semantic, can it be ignored in speech? How do you express an explicit 
> but completely unspecified "annotation"?

If it's ok if it's entirely ignored, then it's presentational, and not 
conveying any useful information.

If it isn't ignored, then clearly it doesn't mean "underline". Indeed, it 
means pretty much what HTML now says it does, and always has. A different 
voice, inflexion, auditory icons -- there are lots of ways of conveying 
this kind of thing in speech, just like there is in the visual medium.


> This really sounds like an odd game where HTML specs are meant to say to 
> authors and to vendors of authoring software that they can keep using 
> <u> as before (and pass validation), but when interrogated, they are 
> supposed to tell that it does not mean underlining but... eh... explicit 
> annotation without explicitly articulated annotation.

If you interpret the spec as saying that <u> is underline and it's fine to 
use it as before then you are misreading the spec.

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


From jkorpela at cs.tut.fi  Fri Jul 29 14:26:02 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sat, 30 Jul 2011 00:26:02 +0300
Subject: [whatwg] sic element
In-Reply-To: <Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
	<Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
Message-ID: <4E33256A.3030609@cs.tut.fi>

29.07.2011 23:56, Ian Hickson wrote:

>> Anyway, aren't you saying that <u>  says "this text is annotated but no
>> annotation is given"? In that case, saying that <u>  draws attention to
>> its content might be more appropriate.
>
> The physical line is an annotation. It's just not articulated.

I think you are using the word "annotation" to mean something different 
from "a note added by way of comment or explanation" 
(http://www.merriam-webster.com/dictionary/annotation). What would an 
annotation be without a note - without a comment or explanation?

>> But the whole idea of transmogrifying the old <u>  element, one of the
>> simplest elements of traditional HTML, to some purportedly semantic
>> element without saying what it _really_ means, is just doomed.
>
> Doomed in what sense?

People won't take it seriously or, perhaps worse still, some people 
think they understand it and will start using <u> for something they 
regard as annotations. This implies that the default rendering is 
underlined, creating confusion with links.

There's nothing to be gained from adopting this new semantics for <u>. 
The suggested semantics has no solid ground on which browsers or search 
engines or other software could build their actions on.

> If you are concerned that people are going to use it
> for a different meaning that it has, then the whole language suffers from
> this problem

I'm not really concerned that way - rather, redefinition of <u> is an 
unnecessary complication to the language. I'm more concerned that some 
people may actually try to use <u> by the spec and cause confusion.

> If it's ok if it's entirely ignored, then it's presentational, and not
> conveying any useful information.

Presentational markup may convey useful information, for example that a 
quotation from printed matter contains an underlined word. Underlining 
also has specialized usage e.g. in some transliteration systems.

> A different
> voice, inflexion, auditory icons -- there are lots of ways of conveying
> this kind of thing in speech, just like there is in the visual medium.

I can't imagine how e.g. different voice would convey the meaning of an 
"annotation" that does not attach any note to anything.

> If you interpret the spec as saying that <u> is underline and it's fine to
> use it as before then you are misreading the spec.

I'm saying that people will keep treating it as underline, except for 
some souls that will get confused and won't know what it is.

It would be _so_ much simpler to keep <u>, <i>, <b> as physical markup, 
like they have always been and will actually be used. If you wish to say 
that authors must not use them, then say so (but it won't have much 
effect). It seems that there's the issue of wanting to disallow them 
(because they're physical markup) and wanting to allow them (because 
programs generate them). That might be a tricky situation, but trying to 
rescue them by artificial redefinitions can't possibly be the right way.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From jonas at sicking.cc  Fri Jul 29 14:47:56 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 14:47:56 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>

On Fri, Jul 29, 2011 at 9:29 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> > On Mon, 9 May 2011, Mounir Lamouri wrote:
>> >>
>> >> Basically, when you want to use the datalist to suggest a few things
>> >> you might not want to filter and when the list is long, you very
>> >> likely want to filter.
>> >>
>> >> You might not want to filter when the list is a real set of
>> >> suggestions and you can type anything else. For example, a field in a
>> >> support form can ask you "What is your problem?" and you could type a
>> >> brief summary but some pre-written issues will be available. It's
>> >> equivalent to a select element followed by an input field that you
>> >> can use if you select "other" in the list. As I see it, when you
>> >> filter, you have a very long list and you very likely want the user
>> >> to select something in the list like a list of bugzilla emails, a
>> >> list o metro stations, etc. Writing anything not in the list might
>> >> not work.
>> >
>> > So why don't you just automatically filter if the list is long, and
>> > not filter if the list is short?
>>
>> I'm not a big fan of try-to-guess-what-the-author-wants-to-do solutions
>> like that. Guessing will likely be as often wrong and annoying as it
>> will be correct and helpful.
>
> Showing the user an autocomplete list with hundreds of entries is going to
> be far more annoying.
>
> This to me seems to be entirely a UI issue.

The problem is the other way around. When wanting to show a short list
that should be filtered based on user input.

/ Jonas


From jonas at sicking.cc  Fri Jul 29 14:51:44 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 14:51:44 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>

On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Mon, 2 May 2011, Jonas Sicking wrote:
>> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >> >
>> >> > <select> in a <datalist> is completely ignored for form submission. In
>> >> > fact, any form element at all in <datalist> is ignored for form
>> >> > submission. See the "construct the form data set" algorithm:
>> >> >
>> >> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
>> >> >
>> >> > It's so that you can do things like:
>> >> >
>> >> > ? <input ... list=options>
>> >> > ? <datalist id=options>
>> >> > ? ? <select ...>
>> >> > ? ? ? <option>...</option>
>> >> > ? ? </select>
>> >> > ? ? ...maybe other form controls here...
>> >> > ? </datalist>
>> >> >
>> >> > Basically everything in the <datalist> except the <option> elements is
>> >> > for fallback in legacy UAs and is ignored in new UAs.
>> >>
>> >> Couldn't this be accomplished using a few lines of javascript?
>> >
>> > Not when scripts are disabled, no.
>>
>> The number of cases when a site can use this solution to get an
>> acceptable UI *and* care about supporting users with scripts disabled
>> *and* is planning to roll out support within the timeframe when there's
>> some support for HTML5 forms, but not enough to rely on it, is extremely
>> small.
>
> That's possible. The entire Web Forms 2 feature set is designed with this
> kind of fallback in mind, though.
>
>
>> My experience is that it's much more likely that people will use other
>> solutions until there is wide enough browser support to reliably use it,
>> and then use javascript as a fallback and not care about users with JS
>> disabled. And that goes even if we add this feature or not.
>
> If that's the case, we should probably rethink the entire design of the
> WF2 features, because maybe there's better ways to do things.

I'd be very interested to hear how we would have designed things
differently under those constraints.

> Looking specifically at <datagrid>'s ability to fall back to <select>, I
> agree that it's not necessarily doing to be widely used, but given that
> it's so simple to support and provides such a clean way to do fallback, I
> really don't see the harm in supporting it.

I haven't looked at <datagrid> yet, so I can't comment.

/ Jonas


From Simetrical+w3c at gmail.com  Fri Jul 29 14:59:57 2011
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 29 Jul 2011 17:59:57 -0400
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
Message-ID: <CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>

On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
>> Looking specifically at <datagrid>'s ability to fall back to <select>, I
>> agree that it's not necessarily doing to be widely used, but given that
>> it's so simple to support and provides such a clean way to do fallback, I
>> really don't see the harm in supporting it.
>
> I haven't looked at <datagrid> yet, so I can't comment.

I think he meant <datalist>.  <datagrid> was axed quite some time ago
and hasn't made a reappearance that I know of.


From jonas at sicking.cc  Fri Jul 29 15:20:59 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 15:20:59 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
Message-ID: <CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>

On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> Looking specifically at <datagrid>'s ability to fall back to <select>, I
>>> agree that it's not necessarily doing to be widely used, but given that
>>> it's so simple to support and provides such a clean way to do fallback, I
>>> really don't see the harm in supporting it.
>>
>> I haven't looked at <datagrid> yet, so I can't comment.
>
> I think he meant <datalist>. ?<datagrid> was axed quite some time ago
> and hasn't made a reappearance that I know of.

Ah, well, then it definitely seems like we should get rid of this
feature. The harm is definitely there in that it's adding a feature
without solving any problem.

For what it's worth, I'm not even convinced there is a problem. The
website can always let the <select> be submitted and ignore it on the
server if it contains a empty value, and then make the first <option>
in the <select> look something like <option value="">You can select a
prefilled value here</option>

/ Jonas


From ian at hixie.ch  Fri Jul 29 15:22:41 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 22:22:41 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> 
> The problem is the other way around. When wanting to show a short list 
> that should be filtered based on user input.

Why would it matter if the list is filtered or not when it's short?

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


From jonas at sicking.cc  Fri Jul 29 15:31:07 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 15:31:07 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1012310012410.28593@ps20323.dreamhostps.com>
	<op.vokzexu464w2qv@anne-van-kesterens-macbook-pro.local>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>

On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>>
>> The problem is the other way around. When wanting to show a short list
>> that should be filtered based on user input.
>
> Why would it matter if the list is filtered or not when it's short?

Choosing something at the bottom of a 10 item list is likely about as
annoying as simply writing the whole email address manually and
ignoring the <datalist> feature completely.

Has any browsers implemented the UI you are suggesting? Is any planning to?

/ Jonas


From ian at hixie.ch  Fri Jul 29 15:39:09 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 22:39:09 +0000 (UTC)
Subject: [whatwg] sic element
In-Reply-To: <4E33256A.3030609@cs.tut.fi>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
	<Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
	<4E33256A.3030609@cs.tut.fi>
Message-ID: <Pine.LNX.4.64.1107292224070.18680@ps20323.dreamhostps.com>

On Sat, 30 Jul 2011, Jukka K. Korpela wrote:
> 29.07.2011 23:56, Ian Hickson wrote:
> > > 
> > > Anyway, aren't you saying that <u> says "this text is annotated but 
> > > no annotation is given"? In that case, saying that <u> draws 
> > > attention to its content might be more appropriate.
> > 
> > The physical line is an annotation. It's just not articulated.
> 
> I think you are using the word "annotation" to mean something different 
> from "a note added by way of comment or explanation" 
> (http://www.merriam-webster.com/dictionary/annotation). What would an 
> annotation be without a note - without a comment or explanation?

I was using it in the sense used in Wikipedia:

   "An annotation is a note that is made while reading any form of text. 
   This can be as simple as underlined or highlighted passages."
    -- http://en.wikipedia.org/wiki/Annotation

If you have a word that better conveys this meaning, I'd be happy to 
use that instead.


> > > But the whole idea of transmogrifying the old <u> element, one of 
> > > the simplest elements of traditional HTML, to some purportedly 
> > > semantic element without saying what it _really_ means, is just 
> > > doomed.
> > 
> > Doomed in what sense?
> 
> People won't take it seriously or, perhaps worse still, some people 
> think they understand it and will start using <u> for something they 
> regard as annotations. This implies that the default rendering is 
> underlined, creating confusion with links.

I don't think what you describe here is a big deal. People fail to take 
specs seriously all the time, or use things in confusing ways all the 
time. I don't think this particular example is any more or less egregious 
than anything else in the spec.


> There's nothing to be gained from adopting this new semantics for <u>.

Sure there is. Device independence, for one.


> The suggested semantics has no solid ground on which browsers or search 
> engines or other software could build their actions on.

The ground seems as solid here as for the vast majority of other elements 
in the specification.


> > If you are concerned that people are going to use it for a different 
> > meaning that it has, then the whole language suffers from this problem
> 
> I'm not really concerned that way - rather, redefinition of <u> is an 
> unnecessary complication to the language.

I disagree with the premise of that concern.


> I'm more concerned that some people may actually try to use <u> by the 
> spec and cause confusion.

I would be overjoyed if people followed the spec!

In this particular case, the redefinition is nothing of the sort. The 
definition is explicitly intended to actually match common practice and to 
match the only non-presentational use cases people could come up with for 
having the element be valid at all.


> > If it's ok if it's entirely ignored, then it's presentational, and not 
> > conveying any useful information.
> 
> Presentational markup may convey useful information, for example that a 
> quotation from printed matter contains an underlined word.

HTML is the wrong language for this kind of thing.


> Underlining also has specialized usage e.g. in some transliteration 
> systems.

Could you elaborate on this?


> > A different voice, inflexion, auditory icons -- there are lots of ways 
> > of conveying this kind of thing in speech, just like there is in the 
> > visual medium.
> 
> I can't imagine how e.g. different voice would convey the meaning of an 
> "annotation" that does not attach any note to anything.

Inflexion changes, pauses, changes in timbre, pitch, speed, and other 
aspects of one's voice, are the ways all meaning is conveyed in aural 
conversations. I don't see why it would be different for this case than 
for any other case.


> > If you interpret the spec as saying that <u> is underline and it's 
> > fine to use it as before then you are misreading the spec.
> 
> I'm saying that people will keep treating it as underline, except for 
> some souls that will get confused and won't know what it is.

Well sure, just like some people will keep treating <blockquote> as 
meaning "indent" and just like how some people will persist in failing to 
understand how scripting APIs work.

Personally I have more faith in authors.


> It would be _so_ much simpler to keep <u>, <i>, <b> as physical markup, 
> like they have always been and will actually be used. If you wish to say 
> that authors must not use them, then say so (but it won't have much 
> effect). It seems that there's the issue of wanting to disallow them 
> (because they're physical markup) and wanting to allow them (because 
> programs generate them). That might be a tricky situation, but trying to 
> rescue them by artificial redefinitions can't possibly be the right way.

I think you are confused as to the goals here. The presentational markup 
that was <u>, <i>, <b>, <font>, <small>, etc, is gone. However, there are 
certain use cases that did not yet have elements yet were important enough 
to warrant us supporting them. By reusing existing elements, we are able 
to support them without having to wait for new elements to be implemented. 
By doing so in a way that closely matches how those elements were actually 
used in practice (at least to the same extent as other elements have been 
correctly used in practice) we can not only have older UAs support these 
new elements automatically, but we can do so in a way that does not 
introduce an undue volume of invalid pages.

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


From ian at hixie.ch  Fri Jul 29 15:42:27 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 22:42:27 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
> >>
> >> The problem is the other way around. When wanting to show a short 
> >> list that should be filtered based on user input.
> >
> > Why would it matter if the list is filtered or not when it's short?
> 
> Choosing something at the bottom of a 10 item list is likely about as 
> annoying as simply writing the whole email address manually and ignoring 
> the <datalist> feature completely.

If 10 items is annoying, then it's not short.


> Has any browsers implemented the UI you are suggesting? Is any planning 
> to?

I've no idea. It's incredibly early days in terms of implementations of 
these features. We are still looking for better ways of implementing 
maxlength="", which is something like 15 years old now. It'd be a little 
premature to dismiss something so early on.

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


From jonas at sicking.cc  Fri Jul 29 16:08:32 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 16:08:32 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTinGUMqbE0gnTUTRpcamXPzVA8YAXhajGacDoDtO@mail.gmail.com>
	<AANLkTikNfHUbJyNmHndRRRYNMZ-5Ybfja4=KBiCTPJGq@mail.gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>

On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >>
>> >> The problem is the other way around. When wanting to show a short
>> >> list that should be filtered based on user input.
>> >
>> > Why would it matter if the list is filtered or not when it's short?
>>
>> Choosing something at the bottom of a 10 item list is likely about as
>> annoying as simply writing the whole email address manually and ignoring
>> the <datalist> feature completely.
>
> If 10 items is annoying, then it's not short.

You mean "long", right?

>> Has any browsers implemented the UI you are suggesting? Is any planning
>> to?
>
> I've no idea. It's incredibly early days in terms of implementations of
> these features. We are still looking for better ways of implementing
> maxlength="", which is something like 15 years old now. It'd be a little
> premature to dismiss something so early on.

The ability to configure UI has been one of the big problems with the
existing set of forms, and is one of the biggest concerns with the new
set of forms (in particular the complex widgets like date/time
pickers), so your argument that this particular aspect does not need
to be configurable from the page seems like something that needs some
backing up with more than opinions.

/ Jonas


From ian at hixie.ch  Fri Jul 29 16:24:23 2011
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 29 Jul 2011 23:24:23 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
> >> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
> >> >>
> >> >> The problem is the other way around. When wanting to show a short
> >> >> list that should be filtered based on user input.
> >> >
> >> > Why would it matter if the list is filtered or not when it's short?
> >>
> >> Choosing something at the bottom of a 10 item list is likely about as
> >> annoying as simply writing the whole email address manually and ignoring
> >> the <datalist> feature completely.
> >
> > If 10 items is annoying, then it's not short.
> 
> You mean "long", right?

No, I mean "short". I said that it shouldn't matter if you filter or not 
when the list is short. You said that a list with ten items was annoying. 
I'm arguing that that means the list is long, and thus not short, and 
thus should be filtered.

My overarching point, however, is that this is a UI issue, and not an 
authoring issue. Authors should be able to provide either a complete 
static list of autocomplete suggestions, or a shorter list of relevant 
suggestions based on the current user input. In both cases, the user agent 
should be able to prioritise and/or filter the given suggestions in 
whatever manner makes the lists most helpful to the user. Giving the 
author the ability to prevent the filtering altogether makes sense if the 
UA's filtering is not ideal, but it doesn't make sense to put in the 
standard, since it's not yet at all clear that an ideal filtering is 
simply impossible.

If, in the future, we find that it is in fact impossible for a UA to be 
clever enough to have good UI whether the list is static or dynamic, short 
or long, prefiltered or not, then it would make sense to study what 
further controls we can give authors. It would make a lot of sense to look 
at this at the same time as we look at other suggested augmentations here, 
such as the ability for script to provide prefiltered suggestions directly 
rather than having to manipulate DOM nodes to do so.


> >> Has any browsers implemented the UI you are suggesting? Is any 
> >> planning to?
> >
> > I've no idea. It's incredibly early days in terms of implementations 
> > of these features. We are still looking for better ways of 
> > implementing maxlength="", which is something like 15 years old now. 
> > It'd be a little premature to dismiss something so early on.
> 
> The ability to configure UI has been one of the big problems with the 
> existing set of forms, and is one of the biggest concerns with the new 
> set of forms (in particular the complex widgets like date/time pickers), 
> so your argument that this particular aspect does not need to be 
> configurable from the page seems like something that needs some backing 
> up with more than opinions.

I do not think the premise of this argument is correct.

Styling form controls has certainly been something we have failed to 
provide hooks for, but that's an orthogonal issue, IMHO, and should be 
resolved using some sort of widget binding solution, not more attributes 
in the language itself.

If we had a widget binding solution then authors with especially 
complicated needs could just override <input> and provide an 
implementation of the widget that did exactly what they wanted.

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


From jonas at sicking.cc  Fri Jul 29 17:08:37 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 17:08:37 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>
References: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>
Message-ID: <CA+c2ei_7Xt_HBba1iZ8hAXdW1tyqBpnbxmfB1PfZKiMR7qi6Uw@mail.gmail.com>

On Tue, Jul 26, 2011 at 11:34 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Hi all,
> In the last couple of weeks, I've been working with developers of CKEditor,
> TinyMCE, and Google Docs to come up with new API for undo and redo.
> Why? Because undo and redo are broken on the Web today. Whenever Web apps
> try to add a custom editing operation without using execCommand or do a "fix
> up" after browser executes a user editing action, user agents get confused
> by DOM mutations made by the apps and won't be able to undo or redo user
> editing actions and execCommand. This forces Web apps to re-implement undo
> and redo themselves, and in fact, many rich text editors store innerHTML of
> a contenteditable element as a string in their internal undo transaction
> history (a.k.a undo stack).
> Also, there's no way for Web apps to add new undo item and populate undo and
> redo menus on user agent's native UI. ?In addition, if an editor app has a
> widget with input/textarea, then the undo stack of the editor gets confused
> when the widget goes away because the undo transaction history exists only
> per document.
> In order to solve above and numerous other problems, we've come to a
> conclusion that we need to?add UndoManager and Transaction.
> UndoManager is an interface for managing undo transaction history. ?It
> exists on a document and an element with the undoscope content attribute.
> ?UndoManager applies new transaction (i.e. make undoable DOM changes) and
> manage them. ?The main purpose of UndoManager is to communicate the list of
> undoable items with the user agent so that the user agent can provide a
> native UI (e.g. populating menu items with them).
> A transaction is a collection of DOM mutations that can be applied,
> unapplied, or reapplied. UndoManager manages transactions and execute
> unapply and reapply upon undo and redo respectively.
> There are two types of DOM transactions:
>
> Managed transaction - the app supplies apply() and the user agent
> automatically takes care of undo and redo. It is compatible with user
> editing actions and editing commands, and allows Web apps to easily add new
> editing operations or fix up DOM after user editing actions or editing
> commands and still have the user agent manage the undo and redo.
> Manual transaction - the app supplies apply(), unapply(), and reapply()
> and?the app takes the full control of undo and redo. However, it is NOT
> compatible with user editing actions, editing commands, or managed
> transactions, meaning that, the user agents won't be able to undo or redo
> them. This transaction is useful for apps such as a?collaborative editor
> that implements domain-specific undo or redo.
>
> You can see more concrete definitions of UndoManager and Transaction at:
> https://rniwa.com/editing/undomanager.html and see a list of uses cases
> at?https://rniwa.com/editing/undomanager-usecases.html. ?The documents are
> incomplete and I need your feedback in order to refine details.

This is awesome and much more thought through than my proposal!

I really do like the undoscope attribute, that is something that is
definitely needed. But I think it should simply be a boolean
attribute, a'la disabled for example. It does seem undefined how it
interacts with the contenteditable attribute? I was thinking that
contenteditable would create a undoscope, unless there's an element
higher up in the tree which has an explicit undoscope attribute.

It does however seem to me that the proposal is unnecessarily complex
in a few areas:

Why is there a need for a 'reapply' action? How is it different from
the 'apply' action?

What is the purpose of the UndoManager.replace function and it's
replaceGroup argument? In general I'm not sure I fully understand
"transaction groups". Are they different from simply a set of
transactions which have been merged together such that they are
done/undone together?

Why expose explicit Transaction objects. What value does that provide?

Here is my updated proposal, which will surely need to be revised once
I understand the questions above better:

interface UndoManager {
  transaction(Function callback, optional in DOMString label, optional
in Boolean merge);
  manualTransaction(Function apply, Function unapply, optional in
DOMString label, optional in boolean merge);

  readonly attribute unsigned long position;
  readonly attribute unsigned long length;
  DOMString? labelAt(in unsigned long index);

  void undo();
  void redo();

  void clearUndo();
  void clearRedo();

  readonly Node host;
};

/ Jonas


From annevk at opera.com  Fri Jul 29 17:17:08 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 29 Jul 2011 17:17:08 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
	<CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
Message-ID: <op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>

On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking <jonas at sicking.cc> wrote:
> Ah, well, then it definitely seems like we should get rid of this
> feature. The harm is definitely there in that it's adding a feature
> without solving any problem.
>
> For what it's worth, I'm not even convinced there is a problem. The
> website can always let the <select> be submitted and ignore it on the
> server if it contains a empty value, and then make the first <option>
> in the <select> look something like <option value="">You can select a
> prefilled value here</option>

If we are removing the <select> fallback feature we should also change the  
way you find <option> elements for a <datalist> element I think. That  
should be aligned with <select>: A child element search rather than a  
descendant element search.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From jonas at sicking.cc  Fri Jul 29 17:19:52 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 17:19:52 -0700
Subject: [whatwg] Why children of datalist elements are barred from
 constraint validation?
In-Reply-To: <op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
	<CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
	<op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>
Message-ID: <CA+c2ei-5jxE+QCAWQfrcqW4_r7vQpJbcJpz80D=aHHuT2Lj_gA@mail.gmail.com>

On Fri, Jul 29, 2011 at 5:17 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> Ah, well, then it definitely seems like we should get rid of this
>> feature. The harm is definitely there in that it's adding a feature
>> without solving any problem.
>>
>> For what it's worth, I'm not even convinced there is a problem. The
>> website can always let the <select> be submitted and ignore it on the
>> server if it contains a empty value, and then make the first <option>
>> in the <select> look something like <option value="">You can select a
>> prefilled value here</option>
>
> If we are removing the <select> fallback feature we should also change the
> way you find <option> elements for a <datalist> element I think. That should
> be aligned with <select>: A child element search rather than a descendant
> element search.

Indeed!

/ Jonas


From rniwa at webkit.org  Fri Jul 29 17:40:05 2011
From: rniwa at webkit.org (Ryosuke Niwa)
Date: Fri, 29 Jul 2011 17:40:05 -0700
Subject: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In-Reply-To: <CA+c2ei_7Xt_HBba1iZ8hAXdW1tyqBpnbxmfB1PfZKiMR7qi6Uw@mail.gmail.com>
References: <CABNRm60RjJ03nj2XJPmtq=6q5deoSEUrnyZNnNXS5+j-yGX6-Q@mail.gmail.com>
	<CA+c2ei_7Xt_HBba1iZ8hAXdW1tyqBpnbxmfB1PfZKiMR7qi6Uw@mail.gmail.com>
Message-ID: <CABNRm61PMikepKeuGH-nV9-SjKGunPQkrAf5i6Nuw685Wya2bQ@mail.gmail.com>

On Fri, Jul 29, 2011 at 5:08 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> I really do like the undoscope attribute, that is something that is
> definitely needed.


Yes. I've considered other possibilities such as letting scripts to manually
instantiate UndoManager objects, etc... but that turned out to require too
much work just to separate undo transaction histories of two editable
regions.


> It does seem undefined how it
> interacts with the contenteditable attribute? I was thinking that
> contenteditable would create a undoscope, unless there's an element
> higher up in the tree which has an explicit undoscope attribute.
>

I've thought this approach as well but this would break the backward
compatibility as the major browsers currently provide one undo transaction
history per document.  My proposal tries to decouple contenteditable and
undoscope so that if the apps were so desired, they can share the same undo
transaction history between multiple contenteditable regions.

My proposal, however, mentions the editing host when I define a "proper
sequence of managed transactions" in order to support co-existance of
managed and manual transactions.

 Why is there a need for a 'reapply' action? How is it different from
> the 'apply' action?
>

In the case of collaborative editing apps, reapply is different from apply
because the backend server may have a tree of transaction history and may
need to consult on demand in order to determine exactly what mutations have
to happen.

What is the purpose of the UndoManager.replace function and it's
> replaceGroup argument? In general I'm not sure I fully understand
> "transaction groups". Are they different from simply a set of
> transactions which have been merged together such that they are
> done/undone together?
>

Yeah, sorry about that.  I should clarify that part of the design.

*UndoManager.replace*
The key observation is that ManagedTransaction is constrained to work only
with a "proper sequence of managed transactions".  Whenever an app inserts a
manual transaction or directly mutates the DOM under the same editing host,
the UA won't be able to unapply/reapply the existing ManagedTransaction
created by user editing actions; i.e. inserting a manual transaction breaks
the existing managed transactions.  Without this constraint, however, the UA
is required to keep track of all DOM mutations happening in the undo scope
:(

Given this constraint, the apps that do use managed transactions such as
collaborative editing apps need to replace the managed transactions inserted
by the UA by the corresponding manual transaction when user types text.

*Transaction Group*
When a user types "hello", he isn't really typing all of "hello" at once but
rather inserting character "h", "e", "l", "l", and "o", letting the UA
insert each letter as a separate managed transaction in the order.  However,
when the user undoes or redoes this typing command, the entire "hello" needs
to removed.  This is accomplished as grouping 5 managed transactions for
inserting "h", "e", "l", "l", and "o" as a transaction group.

Why expose explicit Transaction objects. What value does that provide?
>

I admit this is more of stylistic issue rather than the technical limitation
but given a transaction already has label and apply "properties", it seemed
more natural for it to be an object.  That'll allow us to add more
properties in the future.

In particular, I really wanted to provide a mutation list as discussed on
the mutation events replacement thread on public-webapps.  This allows apps
to determine which transaction did what without having to listening to each
mutation event, and makes it easier to replace managed transactions by
manual transactions as described above.

- Ryosuke


From svartman95 at gmail.com  Fri Jul 29 18:53:52 2011
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sat, 30 Jul 2011 01:53:52 +0000
Subject: [whatwg] <input type="password">... restrict reading value from
	JS?
In-Reply-To: <CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
References: <CAEZ8440X56bv9pB8JtFCe4HmvcjP39VJYiUv2feiJU1gtOMLhw@mail.gmail.com>
	<CAKA+Ax=+DsvHbneabOwHBe8jn36RT5bV5wryUnhtUhw8quUAYA@mail.gmail.com>
	<CAMogmOs+fG+2Lz6gZDRLu-1NYaeS=7=QTzc0pbCh9tvsAi4eFA@mail.gmail.com>
Message-ID: <CAOKKrgNc1KKfkdDn33shwz4Qxrx=hG1hfmkVSPxc0Gdgh89eTA@mail.gmail.com>

On 7/11/11, Sean Connelly <sean at pbwhere.com> wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the <input type="password"> field, and create my own field that reads
> characters (perhaps via onkeyup), and fakes a password field visually.
>
Fair point. I also worry about attackers removing a form and inserting
their own, or even positioning their own over the old one - if they
manage to gather enough information about the victim's UA or if the
form of a password input is consistently positioned.

> I also think it's a bad idea to change the behavior of <input
> type="password"> because it will break websites that assumed they could read
> the value.  Perhaps a website checks against a user's past 10 passwords to
> see if they are using the same one, via XHR.  Or perhaps the entire login
> process is XHR.  Who knows.
>
So there are two use cases for reading user passwords:
 * client side password strength indicators
 ** telling users if their passwords conform to site specific password
restrictions
  - arguably bad practice
  - IMO better achieved with declared regular expressions
 ** generally informing users of the computing needed to brute force
their password open, and if it's in a dictionary
  -- fetching a dictionary from each site is impractical (and thus
only implementable by UAs)
  -- can be implemented by UAs without "braking" sites that work if
laid out in the same way as the author's UA with floating overlays
that appear only while the password input is focused and has input
 * XHR submit
  - Could forms be targeted to a new browsing context and the server
return a HTTP 204 response instead?
  - Are implementors willing to display a more prominent notice of the
status of the submit (e.g. the text "Submitting" under a spin-wheel,
and then the Reason-Phrase of the request colored or on a background
colored to convey the status code)?

> I think there is definite room for improvements in security when it comes to
> <input type="password">, and I've also been trying to make it more secure by
> designing some sort of client-side hashing.  But I don't think restricting
> JavaScript from reading the value is a security benefit... in my opinion, it
> would just be a hassle for developers who need to read the value, and force
> them to use another means of password entry where they can read the value.
>
I don't think anyone but the receiving server should be able to read
my password. This is one of the reasons some people disable
JavaScript. Most don't, as they don't want to stop JavaScripts from
doing other more useful things. If we disable just stuff like this we
can bring some security to the folks that have JavaScript enabled
(such as me).

> On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor
> <Simetrical+w3c at gmail.com>wrote:
>
>> On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
>> > with a XHR I can send that password somewhere it shouldn't go... (well,
>> with
>> > cross-domain security code, maybe not, but that's not the point.)
Are XHR submits of passwords common and important enough to outweigh
the security cost of scripts having access to all passwords in their
document(s)?

>>
>> You can send it anyway by changing the action attribute on the form
>> and calling submit().  So what attack scenario are you actually
>> avoiding here?  You'd need a really strong security benefit for it to
>> be possible to even contemplate breaking so many websites.
>>
I propose disallowing changing the action attribute of forms with
password inputs. That is, if we manage to squash all the other obvious
ways a script can compromise the security of a typed password. This
seems to involve a lot of tedious allowance of this and that to be
done to forms, except if you throw in a password input. I'm not to
judge if it's worth it.


From jonas at sicking.cc  Fri Jul 29 19:08:57 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 19:08:57 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<AANLkTimJ-wof00DveCxsPNy6U6-sjBA2nxraRUb7MzeF@mail.gmail.com>
	<AANLkTinBCiGdBVAj4HzPA8Eb6+HTyV0UVNnBXF+ZUyCp@mail.gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
	<Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>

On Fri, Jul 29, 2011 at 4:24 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >> >>
>> >> >> The problem is the other way around. When wanting to show a short
>> >> >> list that should be filtered based on user input.
>> >> >
>> >> > Why would it matter if the list is filtered or not when it's short?
>> >>
>> >> Choosing something at the bottom of a 10 item list is likely about as
>> >> annoying as simply writing the whole email address manually and ignoring
>> >> the <datalist> feature completely.
>> >
>> > If 10 items is annoying, then it's not short.
>>
>> You mean "long", right?
>
> No, I mean "short". I said that it shouldn't matter if you filter or not
> when the list is short. You said that a list with ten items was annoying.
> I'm arguing that that means the list is long, and thus not short, and
> thus should be filtered.
>
> My overarching point, however, is that this is a UI issue, and not an
> authoring issue. Authors should be able to provide either a complete
> static list of autocomplete suggestions, or a shorter list of relevant
> suggestions based on the current user input. In both cases, the user agent
> should be able to prioritise and/or filter the given suggestions in
> whatever manner makes the lists most helpful to the user. Giving the
> author the ability to prevent the filtering altogether makes sense if the
> UA's filtering is not ideal, but it doesn't make sense to put in the
> standard, since it's not yet at all clear that an ideal filtering is
> simply impossible.
>
> If, in the future, we find that it is in fact impossible for a UA to be
> clever enough to have good UI whether the list is static or dynamic, short
> or long, prefiltered or not, then it would make sense to study what
> further controls we can give authors. It would make a lot of sense to look
> at this at the same time as we look at other suggested augmentations here,
> such as the ability for script to provide prefiltered suggestions directly
> rather than having to manipulate DOM nodes to do so.

I have no idea how the UA would be smart enough to figure out if
filtering makes sense or not based on the set of suggestions. As far
as I can see this requires very complex AI which is able to analyze
the set of suggestions and see if they are contextual to the entered
value or not. Granted, the recent IBM computer Watson did a pretty
good job at this on Jeopardy a few months ago, but I think that we're
decades from having that amount of computational complexity at our
disposal when filtering autocomplete suggestions. I'd be nice if
<datalist> was a viable solution before then.

>> >> Has any browsers implemented the UI you are suggesting? Is any
>> >> planning to?
>> >
>> > I've no idea. It's incredibly early days in terms of implementations
>> > of these features. We are still looking for better ways of
>> > implementing maxlength="", which is something like 15 years old now.
>> > It'd be a little premature to dismiss something so early on.
>>
>> The ability to configure UI has been one of the big problems with the
>> existing set of forms, and is one of the biggest concerns with the new
>> set of forms (in particular the complex widgets like date/time pickers),
>> so your argument that this particular aspect does not need to be
>> configurable from the page seems like something that needs some backing
>> up with more than opinions.
>
> I do not think the premise of this argument is correct.
>
> Styling form controls has certainly been something we have failed to
> provide hooks for, but that's an orthogonal issue, IMHO, and should be
> resolved using some sort of widget binding solution, not more attributes
> in the language itself.
>
> If we had a widget binding solution then authors with especially
> complicated needs could just override <input> and provide an
> implementation of the widget that did exactly what they wanted.

Are you suggesting that filter/no-filter should be selected using CSS?
That seems outside of what CSS currently does anywhere.

/ Jonas


From ian at hixie.ch  Fri Jul 29 20:32:12 2011
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 30 Jul 2011 03:32:12 +0000 (UTC)
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
	<Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
	<CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1107300327010.18680@ps20323.dreamhostps.com>

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> 
> I have no idea how the UA would be smart enough to figure out if 
> filtering makes sense or not based on the set of suggestions.

You could do something like:

 - if there are 7 or fewer suggestions, show them all.
 - if filtering reduces the list to 1 to 7 suggestions, show those.
 - if there's some way to prioritise the filtered list, show the 7 best 
   results from the filtered list.
 - otherwise, show everything.

Exactly how the filtering is done can vary, in a way similar to how 
autocomplete dropdowns in browser location bars have pretty involved 
heuristics for figuring out how to filter to a few results.


> Are you suggesting that filter/no-filter should be selected using CSS? 
> That seems outside of what CSS currently does anywhere.

No, I'm saying it should be done using XBL or its successor.

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


From jonas at sicking.cc  Fri Jul 29 20:48:32 2011
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 29 Jul 2011 20:48:32 -0700
Subject: [whatwg] input element list attribute and filtering suggestions
In-Reply-To: <Pine.LNX.4.64.1107300327010.18680@ps20323.dreamhostps.com>
References: <4C9BC88E.6090800@gmail.com>
	<Pine.LNX.4.64.1105022226420.19153@ps20323.dreamhostps.com>
	<BANLkTikD+g7nWeK6hbF0JAMR_1xkq6jZPA@mail.gmail.com>
	<BANLkTikrLLqd61ecA0kb+ge4281keFcZSg@mail.gmail.com>
	<BANLkTimGG1NL+_fodmAGJWwzvqtuPWY4aA@mail.gmail.com>
	<4DC7C90F.4080405@gmail.com>
	<Pine.LNX.4.64.1107290044590.2079@ps20323.dreamhostps.com>
	<CA+c2ei8W5ckpJz2hvEgMmPS4HjnPVkbqpGET_TL9vioNPekrmA@mail.gmail.com>
	<Pine.LNX.4.64.1107291628360.18680@ps20323.dreamhostps.com>
	<CA+c2ei-b0Q6Az45j_1Jea-=rbPwJQR+0uOLEGRy-sxg+xq0oig@mail.gmail.com>
	<Pine.LNX.4.64.1107292222250.18680@ps20323.dreamhostps.com>
	<CA+c2ei_RwubdKzF1ATNi=TPLBHdFg28E+yf3O3sVop=Y5F6JCA@mail.gmail.com>
	<Pine.LNX.4.64.1107292239200.18680@ps20323.dreamhostps.com>
	<CA+c2ei-kTOWGCWg2Vr=vBH5=8YpjT4QurHPE4gVozDvmJK3J7Q@mail.gmail.com>
	<Pine.LNX.4.64.1107292317150.18680@ps20323.dreamhostps.com>
	<CA+c2ei_NDwB+x4N+dRt8SXerK53nwm=mMXipYzhjOEN=7iKkPQ@mail.gmail.com>
	<Pine.LNX.4.64.1107300327010.18680@ps20323.dreamhostps.com>
Message-ID: <CA+c2ei-f1Om=Nr0BLXdWV8PHkqVopL+wf_daroTFR8C7mjc-9Q@mail.gmail.com>

On Fri, Jul 29, 2011 at 8:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>>
>> I have no idea how the UA would be smart enough to figure out if
>> filtering makes sense or not based on the set of suggestions.
>
> You could do something like:
>
> ?- if there are 7 or fewer suggestions, show them all.
> ?- if filtering reduces the list to 1 to 7 suggestions, show those.
> ?- if there's some way to prioritise the filtered list, show the 7 best
> ? results from the filtered list.
> ?- otherwise, show everything.

I assume it's a bug in the above suggestion that if filtering results
in more than 7 results, we'd show everything, rather than just the
filtered result?

If so, this basically comes down to "filter if it's more than 7,
otherwise don't filter". These sort of magic limits is exactly the
type of things that authors are going to end up butting up against and
are going to want to configure.

I don't see a way that HTML5 currently provides enough data to do any
useful prioritization.

> Exactly how the filtering is done can vary, in a way similar to how
> autocomplete dropdowns in browser location bars have pretty involved
> heuristics for figuring out how to filter to a few results.

Yes, but we have a *lot* more data available to do that filtering and
sorting, compared to just the plain value that we have available for
<datalist>.

/ Jonas


From cam at mcc.id.au  Sat Jul 30 00:51:15 2011
From: cam at mcc.id.au (Cameron McCormack)
Date: Sat, 30 Jul 2011 00:51:15 -0700
Subject: [whatwg] link.sizes and [PutForwards=value]
In-Reply-To: <Pine.LNX.4.64.1107290107420.2079@ps20323.dreamhostps.com>
References: <4CB709B6.5040706@helsinki.fi>
	<op.vkl8act164w2qv@anne-van-kesterens-macbook-pro.local>
	<4CB88535.9070007@helsinki.fi>
	<Pine.LNX.4.64.1101050126330.29066@ps20323.dreamhostps.com>
	<4D2444C8.8040502@gmail.com>
	<Pine.LNX.4.64.1105022326190.19153@ps20323.dreamhostps.com>
	<BANLkTi=me4SCesFWo-QM8tc2J8whmO=jmA@mail.gmail.com>
	<BANLkTin_kiRTHBZ5zHyLRQECHq5QVSoXbQ@mail.gmail.com>
	<Pine.LNX.4.64.1107290107420.2079@ps20323.dreamhostps.com>
Message-ID: <4E33B7F3.8070006@mcc.id.au>

Jumping in the middle of this thread to pick up on one aspect...

On 28/07/11 6:15 PM, Ian Hickson wrote:
> Are we really concerned about objects stringifying to "[Object Foo]"?
>
> It seems that the usefulness of such stringification is far outweighed by
> the usefulness of being able to treat the attribute as a string attribute
> like any other reflecting attribute while also being able to use methods
> on it. In fact, it is consistent with every DOMString attribute: they
> don't stringify to "[Object String]", yet you can call methods on them.
> What's the difference?

There is a disadvantage.  In JS, doing a comparison between two objects, 
regardless of whether they have custom stringification behaviour, will 
compare based on object identity and not the string.

<!DOCTYPE html>
<iframe id=x src=b.html></iframe>
<iframe id=y src=b.html></iframe>
<script>
window.onload = function() {
   var xw = document.getElementById("x").contentWindow;
   var yw = document.getElementById("y").contentWindow;
   alert([xw.location, yw.location,
           xw.location == yw.location].join("\n"));
};
</script>

The two Location objects stringify to the same thing, but are not ==.  I 
think this can be confusing.


From cam at mcc.id.au  Sat Jul 30 00:58:22 2011
From: cam at mcc.id.au (Cameron McCormack)
Date: Sat, 30 Jul 2011 00:58:22 -0700
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <4E3213EB.8020508@mit.edu>
References: <4DDFF77F.9050605@mit.edu>	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>	<4DFB8783.7070802@mit.edu>
	<4DFB8C23.7070808@mit.edu>	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>	<4DFB9F2D.3070404@mit.edu>	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
	<4E3213EB.8020508@mit.edu>
Message-ID: <4E33B99E.4080100@mcc.id.au>

On 28/07/11 6:59 PM, Boris Zbarsky wrote:
> Why, exactly? I thought for SVG the "evt" thing was only relevant for
> content attributes, not IDL attributes.

That's right.  (Maybe Anne meant the Function used internally for the 
content attribute?)


From annevk at opera.com  Sat Jul 30 05:52:02 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Sat, 30 Jul 2011 14:52:02 +0200
Subject: [whatwg] on* attributes on DOM elements
In-Reply-To: <4E33B99E.4080100@mcc.id.au>
References: <4DDFF77F.9050605@mit.edu>
	<op.vw70k91a64w2qv@anne-van-kesterens-macbook-pro.local>
	<4DFB8783.7070802@mit.edu> <4DFB8C23.7070808@mit.edu>
	<Pine.LNX.4.64.1106171809500.14203@ps20323.dreamhostps.com>
	<4DFB9F2D.3070404@mit.edu>
	<Pine.LNX.4.64.1106171851070.14203@ps20323.dreamhostps.com>
	<op.vzcnnnas64w2qv@42-2-187-074.static.netvigator.com>
	<4E3213EB.8020508@mit.edu> <4E33B99E.4080100@mcc.id.au>
Message-ID: <op.vzfnc0rw64w2qv@annevk-macbookpro.local>

On Sat, 30 Jul 2011 09:58:22 +0200, Cameron McCormack <cam at mcc.id.au>  
wrote:
> On 28/07/11 6:59 PM, Boris Zbarsky wrote:
>> Why, exactly? I thought for SVG the "evt" thing was only relevant for
>> content attributes, not IDL attributes.
>
> That's right.  (Maybe Anne meant the Function used internally for the  
> content attribute?)

I meant that this is something that needs addressing if content attributes  
apply to all elements, but it looks like we are not going to do that for  
now.


-- 
Anne van Kesteren
http://annevankesteren.nl/


From annevk at opera.com  Sat Jul 30 06:08:31 2011
From: annevk at opera.com (Anne van Kesteren)
Date: Sat, 30 Jul 2011 15:08:31 +0200
Subject: [whatwg] Reconcile document.URL and document.documentURI?
In-Reply-To: <op.vxr3nkca64w2qv@anne-van-kesterens-macbook-pro.local>
References: <op.vxr3nkca64w2qv@anne-van-kesterens-macbook-pro.local>
Message-ID: <op.vzfn4hev64w2qv@annevk-macbookpro.local>

On Tue, 28 Jun 2011 11:07:58 +0200, Anne van Kesteren <annevk at opera.com>  
wrote:
> Is there a way we can make these consistent somehow? Maybe move  
> document.documentURI to Web Applications 1.0? With createHTMLDocument()  
> I get these results:
>
>          document.URL         document.documentURI
> Gecko   "about:blank"        "about:blank"
> Chrome  ""                   null
> Opera   script document URL  null
> Safari  ""                   null
>
> Only Opera seems to conform here for document.URL which I think means  
> the specification should change. I kind of prefer what Gecko is doing  
> here. Not having the strange null-ability of attributes that take URLs  
> and simply (with apologies to hsivonen) use about:blank.
>
> I also found that both Opera and Gecko throw for setting  
> document.documentURI. Maybe we should take that opportunity and make it  
> readonly (or nuke it entirely, if that is feasible).
>
> For DOM Core this is http://www.w3.org/Bugs/Public/show_bug.cgi?id=13045

I moved document.URL to DOM Core, made document.documentURI readonly, and  
have them both return the same URL concept, which defaults to  
"about:blank".


-- 
Anne van Kesteren
http://annevankesteren.nl/


From jkorpela at cs.tut.fi  Sat Jul 30 06:58:19 2011
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Sat, 30 Jul 2011 16:58:19 +0300
Subject: [whatwg] sic element
In-Reply-To: <Pine.LNX.4.64.1107292224070.18680@ps20323.dreamhostps.com>
References: <mailman.9752.1292117925.9815.whatwg-whatwg.org@lists.whatwg.org><4D042EB1.9010105@jumis.com><Pine.LNX.4.64.1012300054000.26618@ps20323.dreamhostps.com><CE9B195B-1DB8-4CB0-B0E2-74B909E9A406@kaor.in>
	<Pine.LNX.4.64.1105022153520.19153@ps20323.dreamhostps.com>
	<51294D8114214B45AF44C1F847FA8E94@Vodka6000>
	<Pine.LNX.4.64.1107291702420.1701@ps20323.dreamhostps.com>
	<4E330282.2030404@cs.tut.fi>
	<Pine.LNX.4.64.1107292046000.18680@ps20323.dreamhostps.com>
	<4E33256A.3030609@cs.tut.fi>
	<Pine.LNX.4.64.1107292224070.18680@ps20323.dreamhostps.com>
Message-ID: <4E340DFB.8010206@cs.tut.fi>

30.07.2011 01:39, Ian Hickson wrote:

> On Sat, 30 Jul 2011, Jukka K. Korpela wrote:
>> 29.07.2011 23:56, Ian Hickson wrote:
>>>>
>>>> Anyway, aren't you saying that<u>  says "this text is annotated but
>>>> no annotation is given"? In that case, saying that<u>  draws
>>>> attention to its content might be more appropriate.
>>>
>>> The physical line is an annotation. It's just not articulated.
>>
>> I think you are using the word "annotation" to mean something different
>> from "a note added by way of comment or explanation"
>> (http://www.merriam-webster.com/dictionary/annotation). What would an
>> annotation be without a note - without a comment or explanation?
>
> I was using it in the sense used in Wikipedia:
>
>     "An annotation is a note that is made while reading any form of text.
>     This can be as simple as underlined or highlighted passages."
>      -- http://en.wikipedia.org/wiki/Annotation
>
> If you have a word that better conveys this meaning, I'd be happy to
> use that instead.

I don't think Wikipedia can be relied on as indicative of meanings of 
words. International specifications should use English words in their 
meanings as described in dictionaries (or use them as technical terms 
for which exact definitions are given).

Since <u> as such lacks any comment or explanation, I think the wording 
"draws attention to" describes the intended meaning.

>> There's nothing to be gained from adopting this new semantics for <u>.
>
> Sure there is. Device independence, for one.

I mentioned that there is no obvious, intuitively understandable way of 
rendering <u>. This includes all devices. Maybe it's device independent, 
but only in the sense that there is no natural implementation for any 
device - but of course visual browsers will keep underlining it, but 
this just means that the real meaning is "underline".

>> Presentational markup may convey useful information, for example that a
>> quotation from printed matter contains an underlined word.
>
> HTML is the wrong language for this kind of thing.

Such things have been possible in HTML since the beginning. What's the 
tangible benefit of telling authors that they must not do so?

>> Underlining also has specialized usage e.g. in some transliteration
>> systems.
>
> Could you elaborate on this?

For example, a few transliteration systems use underlining of letters or 
letter pairs, see http://transliteration.eki.ee/pdf/Arabic_2.2.pdf
(and before saying that combining underline characters be used instead, 
please try to see whether it actually works and how convenient it is).

> Inflexion changes, pauses, changes in timbre, pitch, speed, and other
> aspects of one's voice, are the ways all meaning is conveyed in aural
> conversations.

All meaning? Hardly. Sounds matter, too. But the point is that no such 
method is intuitively recognized as meaning what you want <u> to mean. 
Besides, people who use speech browsers on a daily basis (as opposite to 
developers who use them for testing) have told me that nuances are 
inevitably lost - the speech rate is high (it takes time to learn to 
listen to it, but it's more or less necessary). So even if there is some 
subtle change, different from those already in established use (for a 
user base), it hardly gets noticed at all, still less understood as 
meaning something specific.

> Well sure, just like some people will keep treating <blockquote>  as
> meaning "indent" and just like how some people will persist in failing to
> understand how scripting APIs work.

Undoubtedly, and <blockquote> is effectively a lost cause. But the <u> 
issue (as well as <i> and <b>) is about creating new problems.

> I think you are confused as to the goals here. The presentational markup
> that was <u>,<i>,<b>,<font>,<small>, etc, is gone.

It hasn't gone anywhere and won't go anywhere, and specs cannot change 
this. The reason why <font> has become less common has little to do with 
its "deprecation" - rather, authors have moved to using CSS because it's 
more powerful and more convenient to use in most cases. The simple 
elements like <u> have clumsy CSS counterparts

> However, there are
> certain use cases that did not yet have elements yet were important enough
> to warrant us supporting them.

Was this based on an analysis of needs for semantic markup, or rather on 
trying to assign meanings that would be somehow compatible with the 
default rendering implications? I think the latter. And this means that 
some semantic needs were more or less _invented_ rather than recognized.

> By reusing existing elements, we are able
> to support them without having to wait for new elements to be implemented.

Several new elements have been added without such concerns. Any new 
semantic elements can be reasonable well used by authors if they add a 
few CSS rules and use the document.createElement() trick to make even IE 
style unknown elements.

> By doing so in a way that closely matches how those elements were actually
> used in practice (at least to the same extent as other elements have been
> correctly used in practice) we can not only have older UAs support these
> new elements automatically, but we can do so in a way that does not
> introduce an undue volume of invalid pages.

Either <u> means the same as before, or it means something else. You 
seem to be saying that it means almost the same, but is the difference 
between physical markup and semantic markup really that small?

Your last statement suggests that you really want to call existing usage 
of <b> as "valid" without really caring about how it is used (as 
physical markup or something else). All this "validity" issue is rather 
artificial, since the vast majority of web pages aren't valid even under 
the fairly trivial (pure-syntax, and even just the DTD-definable part 
thereof) meaning for "valid".

One does not need to be particularly pessimistic to predict that pages 
using <!doctype> won't generally meet even the syntactic requirements, 
still less the semantic definitions. This is something we can well live 
with, and the requirements on user agents and error processing are 
supposed to keep things that way. So why worry about some pages not 
being "valid" in the simple sense of using physical markup that has been 
defined in HTML (with requirements on browsers to keep supporting it) 
but declared forbidden?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/


From jeremy at adactio.com  Sun Jul 31 11:45:14 2011
From: jeremy at adactio.com (Jeremy Keith)
Date: Sun, 31 Jul 2011 19:45:14 +0100
Subject: [whatwg] Why children of datalist elements are barred from
	constraint validation?
In-Reply-To: <CA+c2ei-5jxE+QCAWQfrcqW4_r7vQpJbcJpz80D=aHHuT2Lj_gA@mail.gmail.com>
References: <4C9C5B28.7060402@gmail.com>
	<Pine.LNX.4.64.1012310212010.28593@ps20323.dreamhostps.com>
	<4D1DAA17.2020808@gmail.com>
	<Pine.LNX.4.64.1105022233010.19153@ps20323.dreamhostps.com>
	<BANLkTinrRj83afqf9gup4UPWz9BuJCQLTA@mail.gmail.com>
	<Pine.LNX.4.64.1107290055020.2079@ps20323.dreamhostps.com>
	<CA+c2ei_z7H-R=d+ADVm+wt3GBh4tG-O_GzzUBT2KrBvb4SsK3w@mail.gmail.com>
	<Pine.LNX.4.64.1107291629350.18680@ps20323.dreamhostps.com>
	<CA+c2ei9xuynyuYUuohjtx_Eh0YmhAVgQrUgX+66VrdWhLGvKPA@mail.gmail.com>
	<CAKA+AxkQRJmNj52iiVR6k6z79JDKOzQv8eL6GVwGohnVpyZGXw@mail.gmail.com>
	<CA+c2ei-kBGEFq0AT8aT25gpmW0AMKu0HGcoMA6APVyb=+anbZA@mail.gmail.com>
	<op.vzeoeuiy64w2qv@42-2-187-074.static.netvigator.com>
	<CA+c2ei-5jxE+QCAWQfrcqW4_r7vQpJbcJpz80D=aHHuT2Lj_gA@mail.gmail.com>
Message-ID: <3656E9D6-2D07-412C-92AE-F499DCF0A7D3@adactio.com>

The way that datalist is currently designed (and implemented) is exemplary. The fact that (by design) it allows authors to nest a select element within it that shares the same option elements means that authors can safely begin to use this new feature.

I've written more about it here: http://adactio.com/journal/4272/

I'm trying (and failing) to understand why Jonas wants this feature removed.

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/




From kangax at gmail.com  Sun Jul 31 18:58:31 2011
From: kangax at gmail.com (Juriy Zaytsev)
Date: Sun, 31 Jul 2011 21:58:31 -0400
Subject: [whatwg] Canvas 2d: proposal to add path(DOMString)
In-Reply-To: <4E331B97.4010907@jumis.com>
References: <4E331B97.4010907@jumis.com>
Message-ID: <CAPdhPzmyBMUaj_Cia-PiKcMp48_NJ-czqXfLKV9GmsZTGqzWDQ@mail.gmail.com>

I'd love to see something like this as well.

In my experience this takes more than 80 lines. In Fabric.js [1], for
example, `fabric.Path#render` has ~180 LOC chunk [2] dedicated to doing
exactly this ? drawing translated-from-SVG path using a combination of
`lineTo`, `moveTo`, `bezierCurveTo`, etc. And that's not counting another
~100 lines of arc normalization [3] where arc command is translated to a
sequence of `bezierCurveTo` commands (due to SVG's a/A algorithms being so
different from canvas' `arc` one).

`HTMLRenderingContext::path` seems sufficient since it's always possible to
end it with `fill` or `stroke` (the same way you would do it with
combination of path commands followed by `fill` or `stroke`).

[1] http://kangax.github.com/fabric.js/demos/kitchensink/
[2]
https://github.com/kangax/fabric.js/blob/gh-pages/src/path.class.js#L247-433
[3]
https://github.com/kangax/fabric.js/blob/gh-pages/src/path.class.js#L17-121

-- 
kangax


On Fri, Jul 29, 2011 at 4:44 PM, Charles Pritchard <chuck at jumis.com> wrote:

> Having spoken to several developers, I think that we're clear to add a new
> method to the canvas 2d api;
> though there is some question about how it should be added.
>
> The method would take a DOMString using SVG path semantics.
>
> I'm not certain which route is better:
> ctx.path('M....z')
> or
> ctx.fillPath('M ..z'), ctx.strokePath('M...z');
>
> This usually takes ~80 lines of JavaScript to support,
> we're eager to see it added to native implementations.
>
> All browser vendors have SVG support now, and could easily re-use
> code from their SVG implementations to implement this canvas 2d
> supplemental.
>
>
> -Charles
>


From hallvord at opera.com  Sun Jul 31 23:29:27 2011
From: hallvord at opera.com (Hallvord R. M. Steen)
Date: Mon, 01 Aug 2011 08:29:27 +0200
Subject: [whatwg] [editing] HTML Editing APIs specification ready for
 implementer feedback
In-Reply-To: <CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
References: <CAKA+Ax=WjUkW7rqS3H8yU_+z3A9NDAt6114mZtHGWQk_=D24rQ@mail.gmail.com>
	<CABNRm62oGWhfZj87mppk-GzwEDg=z7MozdFEtWYgttLR+6iReA@mail.gmail.com>
Message-ID: <op.vziuzdqga3v5gv@hr-opera.oslo.opera.com>

On Thu, 28 Jul 2011 01:51:31 +0200, Ryosuke Niwa <rniwa at webkit.org> wrote:

> The return value of queryCommandEnable depends on beforecut, beforecopy,  
> and beforepaste events and selection state in WebKit;

This is actually a use case for before* events I wasn't aware of.  
Interesting. I guess you've taken this behaviour from IE? It seems a bit  
complicated though, in the sense that if the script knows some condition  
that means copy/cut/paste should not be available, listening for an event  
to cancel it is a bit of a convoluted way to make that logic available to  
other parts of the script. But then, I guess using same way to communicate  
state to the browser's UI and to other scripts is simplifying.

(I still haven't added anything about before* events to the CCnP spec,  
because I'm unsure if they are used and whether they are a nice way to  
solve the use case.)

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/