What should XMLHttpRequest.status return on connection timeout? Ian and I were
talking about this, and it seems like 502 is a good response code here...
See https://bugzilla.mozilla.org/show_bug.cgi?id=304980
-Boris
Note: I'm not on the whatwg mailing list, so please cc me on replies.
Shadow2531 wrote:
If text/plain is sent, I expect it to fail unless you have a
text/plain plug-in installed.
Does that match current UA behavior?
I think the type attribute should be required though
Again, does that
Shadow2531 wrote:
If Firefox does use codebase to resolve data for WMP before mapping to
src
It does.
Right-clicking on the wmp window and choosing error details - more
information, will show C00D1197: Cannot play the file. That's
because WMP most likely only got
Andrew Fedoniouk wrote:
Boris, what about this then:
p .myclass ... /p
p #myid ... /p
It's better, but nevertheless seems pretty pointless. And would cause HTML5 UAs
to behave differently from HTML4 UAs on HTML4 content, which is also undesirable.
-Boris
There has recently been an interesting Mozilla bug report about onchange for
radio inputs. It seems that UAs interoperably implement something non-obvious;
it may be a good idea to specify it:
https://bugzilla.mozilla.org/show_bug.cgi?id=363693
-Boris
Laurens Holst wrote:
As said, I tried a few things with embedding an image, video and SVG
with the object tag:
...
First of all, one annoying thing is that you have to provide sizes,
otherwise the object will not be visible.
At least in Mozilla, this is false for images. It should become
Laurens Holst wrote:
One of the main reasons that object is still broken on the web and why
embed needs to be used is Mozilla; their plugin finder doesn’t work
with object.
I'm sorry, but that's false. See my other post (under Re: video element
feedback) and
Henri Sivonen wrote:
I've asked about this before but I still don't understand it: Why
doesn't Gecko completely ignore the classid?
Apart from the fact that this would technically be a spec violation, it actually
breaks some pages (because the ActiveX and NPAPI versions of some plug-ins
Ian Hickson wrote:
I agree that ping= should be made visible to users. Indeed, the spec
explicitly makes that a SHOULD, going far outside its usual boundary of
not specifying user interface requirements.
For what it's worth, this thread sparked some discussion at
Geoffrey Sneddon wrote:
Content-Type: XML
Content-Type: text/XML
Using the first would break badly. I guess it seems to work because of
content-type sniffing on an unknown (and invalid) header
Or because the header parser uses the first header that actually looks like a
valid content-type
William F Hammond wrote:
The experiment begun around 2001 of punishing bad
documents in application/xhtml+xml seems to have led to that mime type
not being much used.
That has more to do with the fact that it wasn't supported in browsers
used by 90+% of users for a number of years.
So user
William F Hammond wrote:
Perhaps you should clearly state your definitions of bad and good
in this case? I'd also like to know, given those definitions, why
it's bad for the bad documents to drive out the good, and how you
think your proposal will prevent that from happening.
Good and bad
William F Hammond wrote:
1. Many search engines appear not to look at application/xhtml+xml.
That seems like a much simpler thing to fix in search engines than in
the specification and UAs, to be honest. I don't see this as a
compelling reason to add complexity to the parsing model.
2.
Křištof Želechovski wrote:
If the server infers the MIME type from content and sends it over HTTP as it
should, you can have both.
Changing servers (including getting existing installs updated) is even more
painful than changing browsers, though.
It would be very nice if servers had better
Samuel Santos wrote:
I don't think this is a valid argument since you can change it anyway [1].
[1] http://www.quirksmode.org/dom/inputfile.html
I should note that some consider this a (low priority, low severity) security
bug that should just be fixed (e.g. by disallowing opacity styling on
Ian Hickson wrote:
- by default, content in sandboxed browsing contexts, and any
browsing contexts nested in them
How do those nested browsing contexts come about, given that later you say:
- content in those browsing contexts cannot create new browsing
contexts or
Kristof Zelechovski wrote:
1. Nested browsing contexts in a sandboxed frame cannot be created
dynamically but they can be defined by the inner markup.
There was no mention of dynamically in Ian's proposal. My assumption
was that cannot create browsing contexts meant just that. If it
Ian Hickson wrote:
Apparently, the Gecko plug-in folks *still* insist on ignoring objects
with MS-style classids instead of special-casing the common ones and
mapping them to Netscape-style plug-ins or even using the data attribute
if present. Opera at least uses the data attribute.
Ian Hickson wrote:
It just means do nothing (including not automatically retrying). If the
event source is reregistered, then it should go through the same process
again; the error response doesn't block that URL for all time.
So in practice until page reload, right?
Why are DNS errors
Ian Hickson wrote:
So in practice until page reload, right?
Or until the URL is added in another eventsource element, or
addEventSource(), with the same URL, sure.
OK.
Why are DNS errors different from under underlying network layer errors
here?
The intent is for DNS and HTTP 4xx
Ian Hickson wrote:
On Thu, 18 Jan 2007, Boris Zbarsky wrote:
There has recently been an interesting Mozilla bug report about onchange
for radio inputs. It seems that UAs interoperably implement something
non-obvious; it may be a good idea to specify it:
https://bugzilla.mozilla.org
Ian Hickson wrote:
The relevant spec text is in several places.
For radio buttons in particular:
http://www.whatwg.org/specs/web-apps/current-work/#radio-button-state
Most of the terms in that paragraph are to do with (and are hyperlinked
to) the algorithms defined in:
Jonas Sicking wrote:
I don't know of any websites unfortunately. I've cc'ed Boris who might know.
In general, if IE doesn't do it it seems unlikely that many sites depend on it.
Agreed on the latter.
On the former, it wouldn't be a problem for websites per se, but the
aliasing needs to
I've recently come across another issue with the origin definition.
Right now, this says:
1) If url does not use a server-based naming authority, or if parsing
url failed, or if url is not an absolute URL, then return a new
globally unique identifier.
2) Return the tuple (scheme, host,
Adam Barth wrote:
On Fri, Jan 9, 2009 at 10:42 AM, Boris Zbarsky bzbar...@mit.edu wrote:
3) Those for which the URI is same-origin with itself but no other URI
(not to be confused with the globally unique identifier case).
Can you give an example of this kind of URI?
Yes, of course. IMAP
I just noticed that section 2.7.1 of HTML5 says:
Extensions must not be used for determining resource types
for resources fetched over HTTP.
While I understand the reasons for this, there are certainly cases where
this will break sites (basically those using HTTP 0.9, or later HTTP
Adam Barth wrote:
Extensions are bad news for content sniffing because they can often be
chosen by the attacker. For example, suppose user-uploaded content is
can be downloaded at:
http://example.com/download.php
In most PHP configurations, the attacker can choose whatever file
extension he
Kartikaya Gupta wrote:
sn = document.createElement( 'script' );
sn.setAttribute( 'type', 'text/javascript' );
document.body.appendChild( sn );// this *should* run an empty script
block and do nothing
That looks like a bug in the spec to me. Empty scripts with no @src are
not
Boris Zbarsky wrote:
Note that since this isn't a core DOM behavior, but rather an artifact
of the JS-to-DOM glue, in this case the behavior will depend on whether
you've accessed the control by name on the form in the past; if the
first such access is after the name change in Gecko
Mike Wilson wrote:
Ian Hickson wrote:
On Thu, 15 Jan 2009, Garrett Smith wrote:
If I understand this correctly, given a FORM with an INPUT
named 'b', if I change the name of that INPUT to 'a', then
form.b should return the element with name=a.
snip
What is the reason for introducing the
Jim Jewett wrote:
(But existing W3C standard probably isn't strong enough.)
s/probably/certainly/
-Boris
P.S. For anyone who cares, I suggest reading
http://dbaron.org/log/2006-08#e20060818a for my reasons for saying the
above.
Ian Hickson wrote:
I haven't mentioned the 'this' behavior, so right now |this !=== window|,
which breaks the invariant that there is no way to actually get hold of a
reference to the Window object itself (as opposed to the outer WindowProxy
object that forwards to the inner Window object).
Ian Hickson wrote:
On Sun, 28 Dec 2008, Geoffrey Sneddon wrote:
Step 12 replaces \ with /. IIRC WebKit does this for all URLs, not just
those with a server-based naming authority (what's that anyway?).
RFC 2396 section 3.2 (Authority Component) says:
Many URI schemes include a top
Garrett Smith wrote:
Firefox 3 adds a border around the list as a result of the legend
element. It looks as if Firefox added an anonymous fieldset
It's not anonymous. The HTML parser in Firefox actually creates a
fieldset element when it encounters a legend that's not inside a
fieldset.
Giovanni Campagna wrote:
Could you propose an example of this UA, that still preserves the
semantics of the elements, as required by HTML5?
A UA that differentiates, in its default styling, between same-site
links and links to a different site.
-Boris
Ian Hickson wrote:
I'm not convinced either of these are really great solutions. I think it'd
be better just to have the script itself only block when it hits
CSS-dependent APIs (though I recognise that that is a much harder problem
in most rendering engines today).
I'm not sure how you
Jonas Sicking wrote:
Well, Garrett is somewhat correct. For example in the following scenario:
link rel=stylesheet href=external.css
script
doStuff();
/script
In gecko, when we parse the script tag, we'll block until all
external stylesheets have finished loading before we start executing
Garrett Smith wrote:
The script's defer attribute does not work in a majority of
implementations. For such browsers, it makes sense to put the script
lower on the page for performance reasons, not before the linked
stylesheets. Moving the deferred script from the bottom of the page to
the head,
Garrett Smith wrote:
There are two/three issues.
1) want to load stylesheets without having scripts block
Already doable for alternate stylesheets, right?
I assume the use case is a script that wants to modify the DOM
immediately but doesn't depend on any styling information? That's a
Garrett Smith wrote:
In general, I want better declarative control over loading external
resources. The solution(s) should not cause compatibility problems
with existing browsers (because I have to support IE6 and Firefox 2).
Honestly, by the time anything we're discussing now will be shipping
Smylers wrote:
That is precisely an instance of an author setting a background colour
without a foreground colour -- specifically the author set the
background colour used on links without setting the foreground colour
for links.
If an author sets a background colour then she needs to set the
Kartikaya Gupta wrote:
For Java, DOMTimeStamp is bound to the long type. For ECMAScript,
DOMTimeStamp is bound to the Date type because the range of the
integer type is too small.
I get number in Opera and Firefox, and object in Webkit. Is there
a reason Opera and Firefox bind the timestamps
Garrett Smith wrote:
I would be fine with a way to flag scripts with that information, though
there is a catch-22: if you flag such a script and it DOES depend on style
information, then existing UAs will get it right and any UA implementing
the new spec will get it wrong.
If the page does
style sheets don't block script execution.
Let me know if you want more details about any part of this.
On Thu, 12 Feb 2009, Boris Zbarsky wrote:
I'm proposing flagging scripts that don't depend on stylesheets
It seems like it is likely that such a feature would end up used before it
works
Garrett Smith wrote:
Because you have scripts after your stylesheets, not just stylesheets.
Really, controlled experiments are hard. You have to hold all but one
variable constant.
OK, I modified the example:
http://localhost/jstest/block/link-img-noscript.html
The bottom script will not
Ian Hickson wrote:
On Fri, 13 Feb 2009, Boris Zbarsky wrote:
The current Gecko behavior is that any stylesheet load started by parsing a
style or link tag will increment a counter on the document (well, on a
per-document script loader object, to be more precise). Completion of the load
Garrett Smith wrote:
I can see why rule matching would happen for all nodes in the document.
On what occasion(s) do(es) that algorithm run?
Depends on the UA, probably.
For Gecko in particular, any time a stylesheet is added to or removed
from the document, any time a rule is added to or
On Thu, 25 Sep 2008, Michal Zalewski wrote:
1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of
X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web
page to inhibit frame rendering in potentially dangerous situations.
Pros:
- Super-simple
Cons:
Ian Hickson wrote:
I added Author requirements: and User agent requirements: labels. Did
they not show up?
Interesting. They do in the single-page version, but not in multipage.
Not sure why I was ending up with the latter, by the way... But in
any case.
-Boris
Drew Wilson wrote:
(workers that continue running even after all entangled windows are closed).
On a side note, why would a UA allow these? Once a user leaves a site,
the site shouldn't be using any more CPU on the user's computer, no?
-Boris
Oliver Hunt wrote:
If by compilation you mean you're (effectively) just doing a syntax
check then webkit is able to this, although it has a reasonable cost
associated with it
Compilation in this case is parsing and compilation to SpiderMonkey
bytecode. This does include syntax checks, of
Oliver Hunt wrote:
Yes, i realise it does more than _just_ a syntax check, but the user
observable effect is just the success or failure of syntax check :D
Ah, yes. Quite so.
-Boris
Sean Hogan wrote:
This is a request for the link element to be given an onload attribute.
And presumably a readyState property.
At least in Gecko, you can already detect whether the sheet is done
loading: if you try to get its cssRules and that throws
INVALID_ACCESS_ERR, then it's still
Jonas Sicking wrote:
This sounds like a good idea to me. Seems useful for dynamically added
stylesheets too, and possibly for stylesheets where the href attribute
is dynamically changed.
Same thing goes for the style element since an inline stylesheet can
have @import rules.
Indeed, and there
Garrett Smith wrote:
On Sun, Mar 15, 2009 at 12:07 AM, Jonas Sicking jo...@sicking.cc wrote:
link.onload = function() {
displayDialog(Dialog Title, someObject);
}
Why not implement EventTarget on link? For example:
link.addEventListener('load', displayDialog, true);
It's the same thing.
Ian Hickson wrote:
The original plan was to just have the filename. Unfortunately, it turns
out that if you do that, there are certain sites that break, because they
expect the path (and they expect a Windows path, no less).
I don't believe I've seen many bugs along these lines for Firefox...
Lachlan Hunt wrote:
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return
Ian Hickson wrote:
So testing this:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/44
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/45
(44 uses currentStyle, for IE/Opera, 45 uses getComputedStyle, for Opera/
Firefox/Safari)
It seems Gecko is the only engine
Boris Zbarsky wrote:
No. What's paused is execution of new scripts, not of existing ones.
So in
this case, b() executes immediately, while a() executes after the
stylesheet
loads.
Woah, so this can affect the order of script execution?
Yes, just like document.write(script src=...) would
João Eiras wrote:
Browsers also support partially setting each of the url fields separately,
although error handling between all of them is very inconsistent.
Note: if you specify this behavior, then you need to specify what happens for
http:, https:, data:, mailto: and unknown:
If you
Kartikaya Gupta wrote:
I was trying different things to see what happens and came across some
particularly weird behavior in Gecko/2009021910 Firefox/3.0.7:
var a = document.createElement('a');
a.setAttribute('href', 'http://example.org:123/foo?bar#baz');
a.hostname = null;
Kartikaya Gupta wrote:
For unknown schemes, if the authority starts with //, doesn't it make sense to assume that the
scheme allows an authority? I would assume that for an unknown scheme, the generic URI syntax in RFC3986
should be followed, which would interpret the stuff between // and the
Anne van Kesteren wrote:
On Fri, 27 Mar 2009 22:40:08 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
This is an option, but it's not obviously correct, just as it's not
obviously correct (and in fact would break pages) to parse
http:foo.com/ without an authority.
Which pages would break
Charles Pritchard wrote:
The draw back of this scheme is that Canvas can now write to a users
hard drive.
A Denial of Service exploit could run toTempURL in an infinite loop,
filling up
the users temporary files directory until the browser puts a stop to the
sillyness.
Even worse, doesn't
Charles Pritchard wrote:
Having thought a little more about it (thank you for the feedback),
returning a reference to a custom URL handler (up to the implementation)
would resolve the security issues.
toTempURL returning... customHandler://randomData.png [any kind of
reference],
would work in
Kartikaya Gupta wrote:
Do you agree that null and empty string should behave differently for search and
hash?
No, not really. Are they treated differently in current UAs (past null
being treated as null, possibly)?
To me, it doesn't make sense to treat null and the empty string
Antti Koivisto wrote:
I'd like to propose a new input type attribute value for phone
numbers (input type=phonenumber perhaps). The primary benefit would
be to enable use of phone number specific input methods (for example a
virtual keyboard) and pickers (for example a system address book). A
Maciej Stachowiak wrote:
While I sympathize with the desire to see current HTML5 form controls
implemented first, frankly, we would be more interested in implementing
input type=tel than the six different date/time controls currently
in HTML5. It seems to me that entering a phone number is
Ian Hickson wrote:
The term browsing context in the spec basically corresponds to the
session history exposed by window.history, and the outer Window object
that the history is on.
How should this behave in a situation like Firefox's undo close tab,
where the resulting tab has a brand-new
Ian Hickson wrote:
However, the Web Storage spec allows for this case:
| When a new top-level browsing context is created by cloning an existing
| browsing context, the new browsing context must start with the same
| session storage areas as the original, but the two sets must from that
|
Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is delivered
Since the part starting with '#' isn't sent as part of the HTTP GET
request, I'm not sure how this
Jon Barnett wrote:
Was it advertized?
Not particularly.
I follow Firefox closely enough, but I don't remember when XPointer was
supported.
If you only follow Firefox, then you might not have have noticed it
anyway. XPointer support for anchor scrolling was added to Gecko in
March 2003.
Robert O'Callahan wrote:
A related surprise is that although a media element delays the document
load event until the readyState reaches HAVE_CURRENT_DATA, it is
possible for a loadeddata event handler to actually run after the
document load event handler.
For what it's worth, there are
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
The next and more important step is
Alex Russell wrote:
Something missing from this (and from Erik's original mail) is the
ability to enumerate listeners.
This has been brought up before.
1) There are some serious security concerns here.
2) It's not clear what the enumeration should actually return.
EventListener objects?
Erik Arvidsson wrote:
On Fri, Apr 24, 2009 at 11:46, Boris Zbarsky bzbar...@mit.edu wrote:
It's not really clear to me what the benefits of using the (rather
suboptimal, from the JS point of view) DOM EventTarget API for generic JS
callback dispatch are.
One of the benefits is a consistent
Alex Russell wrote:
Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
Alex Russell wrote:
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects.
What about event listeners that
Ojan Vafai wrote:
What would be a better approach?
I believe Alex proposed some in this thread as aliases for
addEventListener. Those looked a lot better to me, for what it's worth.
If a linear list of things the event is targeting is sufficient, of
course, and we're ok with the random
Ojan Vafai wrote:
If a linear list of things the event is targeting is sufficient, of
course, and we're ok with the random third argument of
addEventListener being carted around, then we might be ok using it...
I think this is sufficient. Although it is a bit unfortunate that
Ian Hickson wrote:
The spec requires the page 'load' event to be fired asynchronously.
(There's no black-box way to distinguish this from the case of waiting for
the other 'load' events to have fired, as far as I can tell.)
Phrased that way, yes. But maybe I wasn't clear on the exact
Boris Zbarsky wrote:
Ian Hickson wrote:
The spec requires the page 'load' event to be fired asynchronously.
(There's no black-box way to distinguish this from the case of waiting
for the other 'load' events to have fired, as far as I can tell.)
Phrased that way, yes.
Or did I misunderstand
Ian Hickson wrote:
As far as I can tell, as specced, there isn't a race condition (other
than the inherent network race condition).
http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event
In this case:
body onload=2
img onload=1; image = new Image(); image.src =
Ian Hickson wrote:
Ah, yes. good point. I can require that relatively simply (just have the
tasks that are queued for 'load' events themselves delay the page's load
event)
That's exactly what Gecko does.
should I?
I'd prefer that, but I'd be interested in feedback from other implementors.
Alex Russell wrote:
Listeners in other languages can/should just be wrapped for purposes
of sanity.
With the wrappers enforcing whatever event type constraints the
listeners are assuming, presumably?
I can totally get behind a handleEvent protocol
I'm not sure what there is to get
Stewart Brodie wrote:
Actually, it is defined. They are called in registration order, from oldest
to newest. This is stated in both the latest D3E working draft, and the
older versions dating back to 2003 (at least - I didn't go back any further)
Perhaps I should have been clearer. It's not
Anne van Kesteren wrote:
or is there something that DOMParser / XMLSerializer can do that
document.innerHTML cannot?
Ignoring the non-web-facing functionality (like parsing from and
serializing to streams), and speaking only of Gecko's implementations,
basically the following:
1)
Anne van Kesteren wrote:
2) DOMParser can parse from a byte array instead of a string; this
makes it a little easier to work with XML in encodings other than
UTF-8 or UTF-16.
ECMASCript doesn't have byte arrays though. (Though it would be nice if it did.)
Sure, but it has arrays
I was just looking at the spec text on getImageData/putImageData, and I
had a few comments. Of the three, #3 is the most important one:
1) It may be worth noting that if the canvas backing store is stored
as premultiplied rgba, then getImageData right after a putImageData
may well not
Oliver Hunt wrote:
Worse yet, the current setup means that a script that tries
createImageData, fill in the pixels, and then paint it to the
canvas, needs to fill different numbers of pixels depending on the
output device. I fully expect script authors to get this very very
Maciej Stachowiak wrote:
In some environments, a CSS pixel may be more than one device pixel.
Yes, I'm well aware.
In this case, getImageData followed by putImageData will lose resolution.
Right. I did mention that in my reply to Oliver.
It seems that there are two significantly
Boris Zbarsky wrote:
The other use case is doing createImageData, followed by filling in the
pixels, followed by putImageData.
I just saw the example in the spec that does just this, but bases the
values it puts in on numbers it gets out of getImageData. For that case
you would of course
Alex Russell wrote:
Think bigger. I want to create a concrete Element class (that's what a
span is, for all intents and purposes)
As a minor nit, a span is basically an HTMLElement, not an Element.
and make it subclassable (or treat it as a Trait for purposes of composition) so
that we can
João Eiras wrote:
I think the major advantage of document.contentType is to know the value
of the Content-Type header (without charset) sent by the server.
That's not what document.contentType returns in Gecko, though...
(especially if the server-sent value was empty, or didn't parse as a
Ian Hickson wrote:
2) The description of putImageData says it Paints the data from the
given ImageData object onto the canvas. It may be worth
specifying that this uses the SOURCE operator, though this is
clear later on when defining what the method _really_ does.
That's the
Ian Hickson wrote:
On Mon, 1 Jun 2009, Boris Zbarsky wrote:
I still think that we need a better I have some externally-derived
pixel data I'd like to just stick in this canvas API here. fillRect()
has terrible performance characteristics (as has been brought up many
times before
Boris Zbarsky wrote:
It's not that hard, it's an extra four or five lines of code to fill
in multiple pixels in a square (two nested for-loops and an expression
or two to work out what the limit is). Compared to the maths such code
would be doing anyway, this is trivial stuff.
The hard part
Anne van Kesteren wrote:
On Mon, 15 Jun 2009 18:25:03 +0200, Adam Roben aro...@apple.com wrote:
DOM 3 Core defines the DOMStringList interface [1], [...]
I don't think anybody actually implements this interface though or is
planning to.
Gecko does. It's used for the styleSheetSets
Smylers wrote:
ol start=H2SO4
liAcid test
/ol
That should cause parsing an integer to abort and so the default of
start=1 to be used. Opera, Links, and W3M get that right. Konqueror,
Dillo, and Lynx all also seem to manage the aborting, but use a default
of zero instead. Firefox
Michael A. Puls II wrote:
And Mozilla ?
https://developer.mozilla.org/En/DOM_Events#textInput
I tested it on a textarea in Firefox latest trunk before posting. It
didn't fire.
Yeah, that documentation was apparently authored by copy/paste from the
spec...
Fixed it to make it clear that
1 - 100 of 1308 matches
Mail list logo
