- From: Mike West <mkwst@google.com>
- Date: Mon, 16 Feb 2015 16:05:42 +0100
- To: Brian Smith <brian@briansmith.org>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Peter Eckersley <pde@eff.org>, yan zhu <yan@mit.edu>
- Message-ID: <CAKXHy=cwaTGHqm5E4cnp3dne4Ggii_kNY6Wsou57n4O8j-Ua3A@mail.gmail.com>
Given Brian's comments, let's extend this CfC to the 23rd, to coincide with the MIX CfC I just threw at the list: https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0295.html. Comments on both are, of course, welcome! -mike -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Thu, Feb 12, 2015 at 8:32 AM, Mike West <mkwst@google.com> wrote: > On Wed, Feb 11, 2015 at 9:04 PM, Brian Smith <brian@briansmith.org> wrote: > > I support this effort. However, this shouldn't be a separate spec from > > MIX. I understand that from a document preparation perspective, there > > are benefits to having things split up in multiple documents. However, > > from the perspective of somebody trying to read such specifications, > > having related content spread across multiple documents is confusing. > > Hrm. Ok, that's a fair point. > > That said, the current upgrade draft is nicely self-contained; it lays > out a problem, then it describes a solution. I like that. Personally, > I find it easier to deal with documents that have this kind of narrow > focus and limited scope. They're certainly easier to write, as you > noted, but I find them easier to read as well. The HTML spec is a bad > example, because it's truly large in a way that MIX isn't, but I > certainly find it hard to work with when I want to know all the things > about how a single something works. > > > In this case, in particular, having one of the coping mechanisms for > > the rest of MIX defined in a separate document is bad. > > I can see that. I'm not convinced it's the right thing to do, but if > folks generally disagree with me, then I'll see what I can do about > gluing them together. :) > > That said, my argument is significantly weakened since we introduced > strict mode to the MIX doc. Hrm. > > > Maybe there is some concern that if we add this to MIX, then the rest > > of MIX will be delayed. I am not sure that matters, practically. > > I'd like to get MIX out the door to lock in a baseline of expected > behavior that browsers, with the notable exception of Safari, have > more or less already agreed upon. Given that there's apparently > disagreement with the approach from folks like Tim Berners-Lee, I > think there's value in getting that baseline settled and shipped. > > > if people feel like that is a concern, then we should just start a MIX > > 2 draft that is MIX + this feature. > > Another approach (which is much more work) would be to continue moving > towards small documents, while at the same time curating a WebAppSec > summary document that could serve as an introduction to the features > described in each. I can imagine that being useful and approachable > for developers. > > -mike > > -- > Mike West <mkwst@google.com>, @mikewest > > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der > Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine > Elizabeth Flores > (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) >
Received on Monday, 16 February 2015 15:06:30 UTC