Re: [whatwg] Quirks Mode Standard

2012-02-09 Thread Simon Pieters 

On Fri, 10 Feb 2012 08:18:40 +0100, Boris Zbarsky  wrote:


On 2/9/12 9:51 AM, Simon Pieters wrote:

It is very likely that more quirks need to be added, but as I went
through the list I was surprised about how many of them were *not*
widely implemented across browsers, and so may not be needed for Web
compat and can be dropped.


It's worth keeping in mind that the IE9 mode relevant for quirks "web  
compat" is the compat view quirks mode, as far as I can tell...


OK.


It would be useful if browser implementors could review the draft,
consider dropping quirks, give feedback about quirks that can't be
dropped, and consider aligning with other implementations for quirks
that are here to stay.


1)  I'm fairly certain the "Images (img elements) without alt attributes  
sometimes display placeholder icons in quirks mode." quirk cannot be  
dropped.  The real point of that quirk is that this markup:


   

which links to some non-existent image needs to result in a box of width  
100 and height 100 in quirks mode; not doing that breaks all the various  
pages that (still) use "spacer gifs" pointing to bogus URIs.


I believe some UAs have this behavior in all modes; in Gecko the  
behavior is restricted to quirks mode.


The HTML specification specifies this quirk in the Rendering section.

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0


2)  The "fixed width specified on a table cell resets the nowrap  
attribute." quirk seems to be implemented by everyone, effectively.  I  
would be really surprised if it can be dropped.


IE9 in non-compat view doesn't have it.

OK, so then either we limit this to quirks mode like Opera/Gecko or we  
also do it in standards mode like WebKit/IE9 compat view.


3)  Likewise for the "tables with no rows/rowgroups have zero height  
even when a height is specified" quirk.


OK.


4)  The CSS parsing quirks need to define behavior for shorthands.


Other than the behavior for 'font' (assuming 'font-size' is on the list),  
what's missing? (My idea was that shorthands that reference other  
properties (or value productions from other properties) in their "Value:"  
specification would automatically support unitless lengths, e.g.  
'background' where only  gets rewritten to use   
because 'background-position' is in the list but 'background-size' is not.)


How was the list of properties for the unitless px quirk generated, by  
the way?


I went through CSS2.1's property index manually.


It's interesting that 'font-size' is not in the list


I trusted https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior  
which says "The CSS parser interprets unitless numbers as px (except for  
font-size because that was what Netscape Navigator 4 did...". :-) Now  
added, but I'm not sure right now how to spec how the 'font' shorthand is  
handled.



-Boris


Thanks!
--
Simon Pieters
Opera Software

Re: [whatwg] Quirks Mode Standard

2012-02-09 Thread Boris Zbarsky 

On 2/9/12 9:51 AM, Simon Pieters wrote:

It is very likely that more quirks need to be added, but as I went
through the list I was surprised about how many of them were *not*
widely implemented across browsers, and so may not be needed for Web
compat and can be dropped.


It's worth keeping in mind that the IE9 mode relevant for quirks "web 
compat" is the compat view quirks mode, as far as I can tell...



It would be useful if browser implementors could review the draft,
consider dropping quirks, give feedback about quirks that can't be
dropped, and consider aligning with other implementations for quirks
that are here to stay.


1)  I'm fairly certain the "Images (img elements) without alt attributes 
sometimes display placeholder icons in quirks mode." quirk cannot be 
dropped.  The real point of that quirk is that this markup:


  

which links to some non-existent image needs to result in a box of width 
100 and height 100 in quirks mode; not doing that breaks all the various 
pages that (still) use "spacer gifs" pointing to bogus URIs.


I believe some UAs have this behavior in all modes; in Gecko the 
behavior is restricted to quirks mode.


2)  The "fixed width specified on a table cell resets the nowrap 
attribute." quirk seems to be implemented by everyone, effectively.  I 
would be really surprised if it can be dropped.


3)  Likewise for the "tables with no rows/rowgroups have zero height 
even when a height is specified" quirk.


4)  The CSS parsing quirks need to define behavior for shorthands.  How 
was the list of properties for the unitless px quirk generated, by the 
way?  It's interesting that 'font-size' is not in the list


-Boris

Re: [whatwg] Quirks Mode Standard

2012-02-09 Thread Simon Pieters 
On Thu, 09 Feb 2012 19:15:43 +0100, L. David Baron   
wrote:



On Thursday 2012-02-09 15:51 +0100, Simon Pieters wrote:

Today I started working on a spec for quirks mode. I used
https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior as a
starting point. The draft is here:

http://simon.html5.org/specs/quirks-mode


I'd note that the item "All of the style rules in
layout/style/quirk.css apply." probably needs to be expanded, and
items analyzed individually.


Sure. I think however that that has partially already been done as part of  
Hixie writing HTML's Rendering section, and so is probably out of scope  
for this document.



It is very likely that more quirks need to be added, but as I went
through the list I was surprised about how many of them were *not*
widely implemented across browsers, and so may not be needed for Web
compat and can be dropped.

I'm happy for the spec to be moved somewhere, and I can volunteer to
edit it, but I can't promise to spend a lot of time on it.

It would be useful if browser implementors could review the draft,
consider dropping quirks, give feedback about quirks that can't be
dropped, and consider aligning with other implementations for quirks
that are here to stay.


I'd note that there are sometimes messy interactions between
behaviors.  For example, if my memory is correct, implementing the
HTML5 parsing algorithm required that we implement a text-decoration
quirk that we previously didn't have (but WebKit did), as described
in https://bugzilla.mozilla.org/show_bug.cgi?id=572713 .  (Speaking
of which, I'm curious why that quirk, on propagation of
text-decoration into tables, didn't make it from the
developer.mozilla.org URL you gave into your document.  That makes
me think the document isn't quite ready for review yet.)


It's in a comment in the source. I noticed that it was missing in HTML's  
Rendering section and filed a bug.


https://www.w3.org/Bugs/Public/show_bug.cgi?id=15941


There may be cases where only some browsers have a described quirk,
but other browsers have a different behavior that provides the same
compatibility.


Yeah. In such cases, we need to pick one quirk and spec that.


That said, I agree it's likely that many of the quirks can be
removed.


One form of "removing quirks" is to propagate them to also apply in  
standards mode, which is doable if standards mode Web content doesn't rely  
on the quirk being *absent*, and is something the HTML spec has done for  
many things (e.g. parsing of legacy colors).



-David



--
Simon Pieters
Opera Software

Re: [whatwg] Asynchronous history navigation and some inconsistencies

2012-02-09 Thread Boris Zbarsky 

On 2/9/12 3:20 PM, Pablo Flouret wrote:

What should be happening here ideally?


The alert call throwing?  ;)

Not entirely facetiously,
Boris

[whatwg] Asynchronous history navigation and some inconsistencies

2012-02-09 Thread Pablo Flouret 

Hey there,

I'm trying this out:



history.pushState(1, "", "#1");
history.pushState(2, "", "#2");
window.onpopstate = function (e) { alert(e.state); }
history.back();
history.pushState(3, "", "#3");


WebKit:
alerts 2 (bug, i'd say)
history is #1, #2, #3

Gecko:
alerts 1
history is #1, #3

Opera:
Doesn't fire the event (bug?)
history is #1, #2, #3

Don't have an IE to test right now, so not sure what happens there.

What should be happening here ideally?

Cheers,

--
pablo flouret

Re: [whatwg] Quirks Mode Standard

2012-02-09 Thread L. David Baron 
On Thursday 2012-02-09 15:51 +0100, Simon Pieters wrote:
> Today I started working on a spec for quirks mode. I used
> https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior as a
> starting point. The draft is here:
> 
> http://simon.html5.org/specs/quirks-mode

I'd note that the item "All of the style rules in
layout/style/quirk.css apply." probably needs to be expanded, and
items analyzed individually.

> It is very likely that more quirks need to be added, but as I went
> through the list I was surprised about how many of them were *not*
> widely implemented across browsers, and so may not be needed for Web
> compat and can be dropped.
> 
> I'm happy for the spec to be moved somewhere, and I can volunteer to
> edit it, but I can't promise to spend a lot of time on it.
> 
> It would be useful if browser implementors could review the draft,
> consider dropping quirks, give feedback about quirks that can't be
> dropped, and consider aligning with other implementations for quirks
> that are here to stay.

I'd note that there are sometimes messy interactions between
behaviors.  For example, if my memory is correct, implementing the
HTML5 parsing algorithm required that we implement a text-decoration
quirk that we previously didn't have (but WebKit did), as described
in https://bugzilla.mozilla.org/show_bug.cgi?id=572713 .  (Speaking
of which, I'm curious why that quirk, on propagation of
text-decoration into tables, didn't make it from the
developer.mozilla.org URL you gave into your document.  That makes
me think the document isn't quite ready for review yet.)

There may be cases where only some browsers have a described quirk,
but other browsers have a different behavior that provides the same
compatibility.


That said, I agree it's likely that many of the quirks can be
removed.

-David

-- 
đť„ž   L. David Baron http://dbaron.org/   đť„‚
𝄢   Mozilla   http://www.mozilla.org/   𝄂

Re: [whatwg] add html-attribute for "responsive images"

2012-02-09 Thread Mathew Marquis 
On Feb 9, 2012, at 6:36 AM, Jordan Dobson  wrote:

> Tim,
> 
> Very good suggestion. This would allow us to keep our markup clean and
> stash these extra references elsewhere in the code as we see fit.
> 
> +1
> 
> -- 
> Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com
> 
> On Thu, Feb 9, 2012 at 3:11 AM, Tim van Oostrom  wrote:
> 
>> I'm also late in this discussion but followed it globally. Maybe a
>> structure like Microdata's itemref="" is an option too.
>> 
>> You could do:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> This gives you the ability to share the sources with multiple img
>> elements. For example when you have a placeholder image for devices that
>> you do not support.
>> 

Unfortunately we were informed early on that it was very unlikely we’d ever get 
a vendor to sign off on a pattern that involves “looking ahead” on an img tag. 
Modifying the behavior of img itself doesn’t sound viable.

I worry that we’re all getting hung up on throwing ideas around—which is 
understandable for sure, and this is some great conversation. 

I think the bottom line is that we’re all in agreement on what’s needed, exact 
implementation aside: a markup-based means of delivering alternate image 
sources based on device capabilities, to prevent wasted bandwidth and optimize 
display on screen and in print. From an accessibility standpoint, it should at 
the very least equal img’s alt tag. For non-supporting browsers, fallback 
content should be displayed.

If we all agree on these key points—and that there’s a clear need and an 
obvious benefit to the users—I should think we’re ready to carry this 
conversation forward and start ironing out the technical details elsewhere, 
alongside the vendors.

[whatwg] Quirks Mode Standard

2012-02-09 Thread Simon Pieters 

Hi

Today I started working on a spec for quirks mode. I used  
https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior as a  
starting point. The draft is here:


http://simon.html5.org/specs/quirks-mode

It is very likely that more quirks need to be added, but as I went through  
the list I was surprised about how many of them were *not* widely  
implemented across browsers, and so may not be needed for Web compat and  
can be dropped.


I'm happy for the spec to be moved somewhere, and I can volunteer to edit  
it, but I can't promise to spend a lot of time on it.


It would be useful if browser implementors could review the draft,  
consider dropping quirks, give feedback about quirks that can't be  
dropped, and consider aligning with other implementations for quirks that  
are here to stay.


cheers
--
Simon Pieters
Opera Software

Re: [whatwg] RWD Heaven and responsive-images

2012-02-09 Thread Matthew Wilcox 
Nice work Victor,

I'm all for that but I am hesitant as to how effective it will be. The
thing is, we need the feedback from the people in this list to notice
stumbling blocks. The CG could spend weeks honing a solution only to
have it presented here and blown away because someone for here knows
something intricate that the CG community didn't.

That's a worry.

-Matt

On 9 February 2012 14:00, Ronjec Viktor  wrote:
> On Thu, Feb 9, 2012 at 2:19 AM, Jason Grigsby  wrote:
>>
>>
>> On Feb 8, 2012, at 8:04 AM, Ronjec Viktor wrote:
>>
>> > People, this is really getting out of hand...
>> >
>> > 1. WHATWG is a standards body, meaning it _standardizes_ solutions.
>> > Everyone who followed the discussion up until now can easily tell that
>> > currently there is no unified, or even close to common approach to this
>> > topic yet. Someone says the solution is on server-side, the other one says
>> > it's on the client-side, the third one says network protocol, the forth
>> > says headers... This is not the place for such a discussion IMHO.
>>
>> As a newcomer to the list, I’ve tried to wade in lightly because I’m not 
>> certain how these things work. So I’m pleased you wrote that.
>>
>> My question would be where should the conversation happen then? It seems 
>> that within the authoring community finding a solution to handling images 
>> has been a hot topic for months. But my experience has been that whenever I 
>> see attempts to bring the conversation to people deeply involved in the 
>> standards process, the problems are often dismissed or many objections are 
>> raised the proposed solution.
>>
>> Two weeks ago I was talking with Ernesto Jiménez about how the W3C and 
>> WhatWG efforts needed feedback and participation from authors. But it is 
>> unclear to me how that should happen.
>>
>> To wit, we have a problem that many of us have being trying to solve. I for 
>> one don’t have confidence that those of us who are commonly outside the 
>> standards-setting process have the correct answer. I’d be happy for someone 
>> smarter than me to propose solutions that move things forward.
>>
>> To make that happen, it seems necessary to convince people that an actual 
>> issue exists and to discuss potential solutions somewhere. So an honest and 
>> humble question, if that doesn’t happen here, where does it happen?
>>
>> -Jason
>
> On Thu, Feb 9, 2012 at 11:36 AM, Matthew Wilcox  
> wrote:
>> +1 to everything Jason Grigsby just said.
>>
>> If not here, where? If not with you, with who? We've been doing this
>> publicly for months and months...
>
>
> To prevent being labelled as a troll for questioning the merit of such
> ambiguous discussion on WHATWG, I have contacted people for help.
> Dominique Hazaël-Massieux, who himself has made proposals on solutions
> concerning the topic to the W3C HTML Working Group
> (http://lists.w3.org/Archives/Public/public-html/2011May/0386.html)
> has recommended to me that maybe creating a Community Group at W3C
> would be in order. Community Groups differ from Working Groups in that
> participants of the discussion are trying to find a common ground for
> consensus on what a solution should be to a given problem, before
> proposing it for standardization to a standards body.
>
> In my opinion, until everyone is proposing something else (e.g. HTTP
> headers, SPDY protocol, "device classes", new markup with new alt
> tags, etc) we create the following CG and move the discussion there:
>
> Proposed name:
> Adaptive Media Community Group
>
> Proposed group description:
> The Adaptive Media Community Group is a community of web developers
> seeking a solution so that embedded media in HTML (e.g. images and
> videos using the  and ), and their properties (e.g.
> dimension, compression ratio) are optimum to given factors, such as
> device screen resolution or available network bandwidth.
>
> Proposed shortname for CG:
> adaptmedia
>
> Of course, creating a CG would be completely meaningless if there is
> no interest and support for it from the community. I believe there is
> interest for it, but the question is, is there support for it?
>
> The above is just a my proposal in advancing this discussion, and
> until there is no feedback about this from people on the "RWD Heaven:
> if browsers reported device capabilities  in a request header" and the
> "add html-attribute for "responsive images"" threads, and other
> developers concerned in Responsive Web Design, I don't think I should
> just create the group and hope that the discussion will just move and
> concentrate there on its own. So open for feedback on this!
>
> Kind regards to all,
>  Viktor

[whatwg] RWD Heaven and responsive-images

2012-02-09 Thread Ronjec Viktor 
On Thu, Feb 9, 2012 at 2:19 AM, Jason Grigsby  wrote:
>
>
> On Feb 8, 2012, at 8:04 AM, Ronjec Viktor wrote:
>
> > People, this is really getting out of hand...
> >
> > 1. WHATWG is a standards body, meaning it _standardizes_ solutions.
> > Everyone who followed the discussion up until now can easily tell that
> > currently there is no unified, or even close to common approach to this
> > topic yet. Someone says the solution is on server-side, the other one says
> > it's on the client-side, the third one says network protocol, the forth
> > says headers... This is not the place for such a discussion IMHO.
>
> As a newcomer to the list, I’ve tried to wade in lightly because I’m not 
> certain how these things work. So I’m pleased you wrote that.
>
> My question would be where should the conversation happen then? It seems that 
> within the authoring community finding a solution to handling images has been 
> a hot topic for months. But my experience has been that whenever I see 
> attempts to bring the conversation to people deeply involved in the standards 
> process, the problems are often dismissed or many objections are raised the 
> proposed solution.
>
> Two weeks ago I was talking with Ernesto Jiménez about how the W3C and WhatWG 
> efforts needed feedback and participation from authors. But it is unclear to 
> me how that should happen.
>
> To wit, we have a problem that many of us have being trying to solve. I for 
> one don’t have confidence that those of us who are commonly outside the 
> standards-setting process have the correct answer. I’d be happy for someone 
> smarter than me to propose solutions that move things forward.
>
> To make that happen, it seems necessary to convince people that an actual 
> issue exists and to discuss potential solutions somewhere. So an honest and 
> humble question, if that doesn’t happen here, where does it happen?
>
> -Jason

On Thu, Feb 9, 2012 at 11:36 AM, Matthew Wilcox  wrote:
> +1 to everything Jason Grigsby just said.
>
> If not here, where? If not with you, with who? We've been doing this
> publicly for months and months...


To prevent being labelled as a troll for questioning the merit of such
ambiguous discussion on WHATWG, I have contacted people for help.
Dominique Hazaël-Massieux, who himself has made proposals on solutions
concerning the topic to the W3C HTML Working Group
(http://lists.w3.org/Archives/Public/public-html/2011May/0386.html)
has recommended to me that maybe creating a Community Group at W3C
would be in order. Community Groups differ from Working Groups in that
participants of the discussion are trying to find a common ground for
consensus on what a solution should be to a given problem, before
proposing it for standardization to a standards body.

In my opinion, until everyone is proposing something else (e.g. HTTP
headers, SPDY protocol, "device classes", new markup with new alt
tags, etc) we create the following CG and move the discussion there:

Proposed name:
Adaptive Media Community Group

Proposed group description:
The Adaptive Media Community Group is a community of web developers
seeking a solution so that embedded media in HTML (e.g. images and
videos using the  and ), and their properties (e.g.
dimension, compression ratio) are optimum to given factors, such as
device screen resolution or available network bandwidth.

Proposed shortname for CG:
adaptmedia

Of course, creating a CG would be completely meaningless if there is
no interest and support for it from the community. I believe there is
interest for it, but the question is, is there support for it?

The above is just a my proposal in advancing this discussion, and
until there is no feedback about this from people on the "RWD Heaven:
if browsers reported device capabilities  in a request header" and the
"add html-attribute for "responsive images"" threads, and other
developers concerned in Responsive Web Design, I don't think I should
just create the group and hope that the discussion will just move and
concentrate there on its own. So open for feedback on this!

Kind regards to all,
 Viktor

Re: [whatwg] add html-attribute for "responsive images"

2012-02-09 Thread Bjartur Thorlacius 
On Wed, 08 Feb 2012 17:16:36 -, Anselm Hannemann - Novolo  
Designagentur  wrote:
Okay, I talked with some disabled web developers and Accessibility  
experts today and talked about the proposal of markup in alt-text.
This seems not to be a good idea as screenreader would read the tags  
which would confuse many users then.
So we would get into trouble with that approach according to current  
screenreader features, etc.


This applies only to attributes. Elements can and do have element  
children, while attributes can only contain plain text. We should not  
redefine the alt attribute. A new element has been proposed in the list  
whose contents can be defined to be an alternative representation of the  
linked resource. Preferably we could just reuse elements and semantics  
where appropriate.


type="image/gif">

 Nazi Cats
 Humans have been obsoleted.


type="image/gif">
 



As has been pointed out in the thread already, using  fallbacks of  
different media types may result in strange behavior, and is hard to  
implement correctly.

Re: [whatwg] add html-attribute for "responsive images"

2012-02-09 Thread Jordan Dobson 
Tim,

Very good suggestion. This would allow us to keep our markup clean and
stash these extra references elsewhere in the code as we see fit.

+1

-- 
Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com

On Thu, Feb 9, 2012 at 3:11 AM, Tim van Oostrom  wrote:

> I'm also late in this discussion but followed it globally. Maybe a
> structure like Microdata's itemref="" is an option too.
>
> You could do:
>
> 
> 
>
> 
>
> 
> 
> 
>
> 
> 
> 
>
> This gives you the ability to share the sources with multiple img
> elements. For example when you have a placeholder image for devices that
> you do not support.
>
> Tim
>
>
>  On Feb 8, 2012, at 7:29 PM, Jason Grigsby wrote:
>>
>> On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote:
>>
>> I'm late to this discussion so pardon me if this has already been
>> discussed, by using the same logic as the  why not just
>> create  to go along with the  element?
>>
>>
>> When a bunch of us discussed this on an etherpad a while back, we
>> ruled  out because:
>>
>> * Completely redefines semantics and content model of an already new
>> element.
>> * Current use includes multiple images
>> * Current use includes non-images like code samples, video, etc.
>>
>> https://etherpad.mozilla.org/**responsive-assets
>>
>> Of course, this doesn’t mean we were right about ruling it out. :-)
>>
>> -Jason
>>
>>
>> Thanks for the clarification.
>>
>> The fact that the  element is structured to allow us to define
>> multiple images seems like a good fit for this approach, especially since
>> it's going to end up using the new tag(s) anyway if the page needs to group
>> multiple responsive images together:
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Multiple responsive images grouped in the figure
>> element
>> 
>>
>> But I agree with David that this feels very bloated, and honestly I'd
>> hate to think of the things my students would throw at me if I were to
>> present this as the approach to handle responsive images in HTML. It's bad
>> enough we have to encode and serve up at least three different video
>> formats with a possible fallback just to utilize the  tag, but to do
>> this for every image would be a nightmare.
>>
>> Sean Fousheé
>> Instructor, Graphic Communications
>> Tarrant County College, NE Campus
>> 828 Harwood Rd.
>> Hurst, TX 76054
>> (817) 515.6596
>> sean.fous...@tccd.edu> >
>>
>>
>>
>

Re: [whatwg] add html-attribute for "responsive images"

2012-02-09 Thread Tim van Oostrom 
I'm also late in this discussion but followed it globally. Maybe a 
structure like Microdata's itemref="" is an option too.


You could do:















This gives you the ability to share the sources with multiple img 
elements. For example when you have a placeholder image for devices that 
you do not support.


Tim


On Feb 8, 2012, at 7:29 PM, Jason Grigsby wrote:

On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote:

I'm late to this discussion so pardon me if this has already been discussed, by using the same 
logic as the  why not just create  to go along with 
the  element?


When a bunch of us discussed this on an etherpad a while back, we ruled 
 out because:

* Completely redefines semantics and content model of an already new element.
* Current use includes multiple images
* Current use includes non-images like code samples, video, etc.

https://etherpad.mozilla.org/responsive-assets

Of course, this doesn’t mean we were right about ruling it out. :-)

-Jason


Thanks for the clarification.

The fact that the  element is structured to allow us to define multiple 
images seems like a good fit for this approach, especially since it's going to end up 
using the new tag(s) anyway if the page needs to group multiple responsive images 
together:















Multiple responsive images grouped in the figure 
element


But I agree with David that this feels very bloated, and honestly I'd hate to think 
of the things my students would throw at me if I were to present this as the approach 
to handle responsive images in HTML. It's bad enough we have to encode and serve up 
at least three different video formats with a possible fallback just to utilize 
the  tag, but to do this for every image would be a nightmare.

Sean Fousheé
Instructor, Graphic Communications
Tarrant County College, NE Campus
828 Harwood Rd.
Hurst, TX 76054
(817) 515.6596
sean.fous...@tccd.edu

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

2012-02-09 Thread Matthew Wilcox 
+1 to everything Jason Grigsby just said.

If not here, where? If not with you, with who? We've been doing this
publicly for months and months...