On 5/5/14, 11:26 AM, Adam Barth wrote:
On getting, the cores property should return the number of logical
processors available to the user agent. For example on OS X this should be
equivalent to running sysctl -n hw.ncpu.
This doesn't really answer my question. What if there are six logical
On 5/5/14, 7:29 PM, Kenneth Russell wrote:
There's no provision in the web worker
specification for allocation of a web worker to fail gracefully, or
for a worker to be suspended indefinitely.
This is not actually true. Nothing in the spec requires a UA to expose
the full parallelism of the
On 4/25/14, 12:06 AM, Dan Beam wrote:
interface AutocompleteError : DOMException {
DOMException isn't an interface as currently proposed.
In general, please check with public-script-coord before minting new
exception types; there's been a lot of discussion on that issue recently.
-Boris
On 4/16/14 10:22 AM, Justin Novosad wrote:
But why a new version of drawImage? Couldn't we just modify the existing
drawImage definition to state that it takes into account the
image-orientation property on the source image?
We could do that, though it introduces a dependency of drawImage on
On 4/16/14 11:09 AM, Anne van Kesteren wrote:
I don't really follow the reasoning. But I guess if this has been
shipping in Firefox for a while we might be out of luck changing this.
I doubt image-orientation is widely used, esp. in combination with
drawImage.
But if we want to use it here,
Right now canvas drawImage ignores EXIF orientation metadata.
Could we add a version that doesn't do that? Especially with CSS
growing things like the image-orientation property, it would be good to
support drawing the image in its correct orientation.
-Boris
On 3/15/14 11:36 AM, Kyle Simpson wrote:
The `async=false` stuff in the spec talks about dynamically loaded (not parser
loaded) scripts going into a queue so they are downloaded in parallel, but
executed in request-order from the queue.
Then those are guaranteed to be serialized.
The
On 3/14/14 5:03 PM, Jake Archibald wrote:
Do you know what browsers do with a fully cached script?
script src=url is always executed async when inserted into the DOM,
cached or not.
scripttext/script is executed sync.
-Boris
On 3/14/14 6:04 PM, Jake Archibald wrote:
Any guarantees of ordering if fully cached?
I believe no.
-Boris
On 3/14/14 8:31 PM, Kyle Simpson wrote:
As I noted above, what we need to know (and I guess we need to know this from all
browsers) if there's a *guarantee* of a-b-c execution order (even if all 3
are executing async)
I don't believe there is such a guarantee, unless the spec spells it out
On 3/12/14 7:23 AM, Jake Archibald wrote:
== img/link/script/document/iframe .loaded() ==
If the element hasn't loaded or is loading, vend a promise that
resolves/rejects on its load/error event.
If the element has fired load/error and isn't loading due to a source
change, vend a
On 3/12/14 9:32 AM, Jake Archibald wrote:
You're right, I was short on detail for that case.
img.src = foo;
var promise1 = img.loaded();
img.src = bar;
I expect promise1 to reject with an AbortError.
No, the case I'm worried about is when the first load has already
finished, you call
On 3/12/14 10:17 AM, Domenic Denicola wrote:
With promises you should only ask for the loaded promise *after* setting `src`
Ah, fair.
I'd been hoping we could get away without having to very carefully order
the code, but I'm just not seeing a way to do that.
Except, I suppose, for the
On 3/5/14 11:42 PM, Rik Cabanier wrote:
Since this is such a small edge case, it seems reasonable to disallow the
creation of a 2d context and throw an exception. Going through all the APIs
and flagging them as suitable for a context-less environment is not really
worth the effort.
What
On 2/20/14 11:18 AM, Tab Atkins Jr. wrote:
(If people used rAF for what it was *intended* for, we could probably
have stopped firing it *entirely* when the window isn't visible.
We do. At least Chrome and Firefox do.
Instead, we had to compromise with the 1s refresh rate instead.)
That's
On 2/3/14 5:29 AM, Anne van Kesteren wrote:
So how does that work for text/xml? Do you dispatch on namespace of
the root element?
What Gecko does is that if the document is an HTMLDocument (so is
text/html or application/xhtml+xml) and hence has a .body property we
use that. Otherwise we
On 1/23/14 6:16 AM, Stewart Brodie wrote:
I get different results on your test case for the bottom two tests. In
Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26
there isn't.
Indeed.
What Gecko does with br is basically to treat it like a special box
type that has
On 1/17/14 12:34 AM, Gordon P. Hemsley wrote:
I have finally made this change. Please confirm that this is what you
had in mind:
https://github.com/whatwg/mimesniff/commit/d7bafc16ee480a5dea4c27d60dd5272388e022ce
http://mimesniff.spec.whatwg.org/#rules-for-text-or-binary
Yes, thank you.
On 1/23/14 1:54 PM, Daniel Holbert wrote:
So, the position float properties do represent a little bit of
style that Gecko honors on br (but not Blink/Presto; not sure about IE).
IE11 shows linebreaks on your last two testcases there.
-Boris
On 1/23/14 9:13 PM, Bruno Racineux wrote:
Then how come it is the case right now for both:
object style=display:none data=image.png
Gecko's preloader never preloads objects. There are various reasons
for this, but the most important one is that in practice it doesn't
matter for actual web
On 1/22/14 9:06 AM, Erik Dahlström wrote:
In SVG2 most of the events with SVG event name prefixes have been
removed[4], e.g SVGLoad is now a plain load, which means they follow
the pattern for event handler content attributes.
SVGResize, SVGScroll and SVGZoom still remain to be fixed in the
On 1/18/14 11:34 PM, Ryosuke Niwa wrote:
Am I correct in assuming that load event never fires for this about:blank page since
it’s “both ready for post-load tasks and completely loaded immediately?
I would think not, since it's a web compat requirement to fire onload
for about:blank iframes
On 1/7/14 12:01 PM, Yoav Weiss wrote:
I'd love to get some more details regarding that. I'll start a
mozilla.dev.platform thread on the subject, since it's Gecko specific.
It's actually not entirely Gecko-specific.
Consider a display:none iframe. How should viewport-size-related media
On 1/7/14 2:24 PM, Ian Hickson wrote:
It's probably just a matter of saying, in the rendering section, that nested
browsing contexts that
aren't _being_rendered_ (or that are frames outside framesets) get a
0x0 viewport.
That doesn't seem unreasonable.
(Viewports that are being rendered
On 1/7/14 3:06 PM, Boris Zbarsky wrote:
4) IE11 seems to do what Blink/WebKit do.
To test this, you'll need a testcase more like:
style
div { color: purple; }
@media (min-width: 300px) { #one { color: yellow; } }
@media (max-width: 300px) { #two { color: yellow; } }
/style
-Boris
On 1/7/14 4:28 PM, Yoav Weiss wrote:
Since this case is not the majority case, we could bail out of it by
delaying the iframe's subresource loading that rely on viewport
dimensions until the parent's layout is considered done
That seems fairly undesirable, actually, though limiting it only to
On 1/6/14 12:42 PM, Yoav Weiss wrote:
I don't know much about Gecko's implementation of the preloader, so I
could be wrong, but from looking at nsHtml5TreeOpExecutor, it seems like
in Gecko (similarly to current Blink) the preloader's products are sent
to the main thread before the actual
On 1/4/14 1:17 PM, David Bruant wrote:
I imagine the only thing they need is the engineering time both to
implement it
It's a one-line change in Firefox.
and keep an eye open on their bug tracker to see if a
website breaks because of this change
This is the problem. Just watching for bug
On 12/31/13 1:44 AM, Tingan Ho wrote:
Right now, Chrome, Firefox, Opera uses emtpy strings **. Safari and IE
uses null string *null.*
May I ask which Firefox version you tested? I would think that Firefox
20 and newer would be sending null here, and testing on
http://jsfiddle.net/fbgLg/
On 12/12/13 7:56 PM, Jungshik Shin (신정식, 申政湜) wrote:
Well, the vast majority of users would never touch A-L list. So, the top
entry in the A-L list would remain the default value, which is usually
the UI language. So, I don't know how much your change helps privacy if
revealing the UI language
On 12/10/13 11:11 AM, Peter Cashin wrote:
The HTML5 spec says that an ambiguous ampersand (e.g. something; undefined) is
not allowed in element content
Right, that's an authoring requirement.
and in section on HTML parsing, that this should throw a parse error.
There is no throwing of
On 12/10/13 2:33 PM, Jukka K. Korpela wrote:
Authoring requirements as such are just policy statements, therefore
regularly ignored.
In this case, it's an eminently validator-enforceable authoring requirement.
Allowing user agents to stop parsing after a parse error (BTW, where
exactly does
On 12/10/13 4:41 PM, Jukka K. Korpela wrote:
Allowing user agents to stop parsing after a parse error (BTW, where
exactly does the WHATWG HTML Living Standard allow that?)
Did you try following the links in my mail? Let me try again, but this
time do actually follow the link:
On 11/27/13 9:08 AM, Anne van Kesteren wrote:
It seems weird to say Gecko has serious security concerns. Either
there's a factual security issue or not, right?
In theory, yes.
In practice, opinions seem to differ, not least because one person's
security/privacy issue is another's business
On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote:
That is, I suggest that 'navigator.language' always be the UI language of a
web browser.
That's an unacceptable privacy leak from Mozilla's point of view. See
https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly
switched
On 11/26/13 5:50 PM, Ian Hickson wrote:
But the image inside this image would also be loaded as basic fetch
tainted cross origin. Right?
That's up to SVG.
Note that Gecko has serious security concerns with allowing subresource
loads like this in SVG loaded via img; we currently disallow
On 11/25/13 12:59 AM, Ian Hickson wrote:
It's more like svg:g. The CSS model just doesn't apply. Even in Firefox,
it's not really CSS that's working there. It's some weird proprietary
variant.
It's really not, once you have a DOM and are inside option.
I mean, as you've pointed out, child
On 11/24/13 8:12 PM, Ian Hickson wrote:
On Fri, 22 Nov 2013, Boris Zbarsky wrote:
On 11/22/13 9:41 PM, Ian Hickson wrote:
Sure, options are replaced elements either.
You mean aren't?
Right. They have nothing to do with CSS.
In Gecko they do: they're just blocks.
They aren't replaced
On 11/24/13 10:27 PM, Ian Hickson wrote:
(That's non-conforming, as far as I can tell, for what it's worth. The
HTML spec says you're supposed to render elements according to what they
represent, and option elements represent an option in a select, with a
label, value, etc; children elements
On 11/22/13 6:00 PM, Ian Hickson wrote:
Hm, it's true that buttons do seem exceedingly eager to remain
inline-block-esque even when set to more block-like display types.
Or when set to display:inline, for that matter.
The definition above talks only about the contents of the element, not
the
On 11/22/13 8:44 PM, Ian Hickson wrote:
selects aren't rendered according to the CSS in the way that button
contents are. Consider:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2654
OK, but consider
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2655
On 11/22/13 9:57 PM, Boris Zbarsky wrote:
For what it's worth, select didn't use to be in Gecko either, in this
sense, until we made it so in
https://bugzilla.mozilla.org/show_bug.cgi?id=591619
And to be clear, all that this did is add the equivalent of:
select :not(:any(option, optgroup
On 11/18/13 1:37 PM, Philip Jägenstedt wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2643
In my testing, getSVGDocument is supported on embed, frame,
iframe and object in Firefox Nightly, IE11 Preview, Safari 7.0 and
Opera 12.16, the only exception being
On 11/4/13 6:25 AM, Anne van Kesteren wrote:
We should add it to DocumentFragment I think. That will be useful for
ShadowRoot too.
OK, agreed. Landed this for DocumentFragment in Gecko.
-Boris
On 11/2/13 11:42 PM, Rik Cabanier wrote:
Maybe we should revisit this design principle or be less strict. It feels
unnatural to give access to internal objects.
Who said anything about giving access to internal objects?
The normal way to have such an API is to have a method call, not a
On 10/31/13 7:42 AM, Anne van Kesteren wrote:
On Wed, Oct 23, 2013 at 4:47 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/22/13 7:00 AM, Anne van Kesteren wrote:
So do you think we should add getElementById() to ParentNode in DOM?
I actually do, yes.
http://dom.spec.whatwg.org/#parentnode
On 11/1/13 9:59 PM, Boris Zbarsky wrote:
We can't have nice things. :(
Though nothing I know of so far is stopping us from adding
getElementById on DocumentFragment... for what that's worth.
-Boris
On 10/31/13 4:07 AM, Simon Pieters wrote:
I meant for element.getElementsByTagName, but not for
document.getElementsByTagName.
Yes, I assumed that. That's why I wondered what the compat situation is
instead of just claiming it's not compatible...
-Boris
On 10/31/13 10:14 AM, Bjoern Hoehrmann wrote:
What we should have is proper automated test suites that let us know
what web browsers do and do not implement.
We should have that too, sure.
Creating rudimentary tests
for the relevant cases here probably takes less effort in addition to
being
On 10/31/13 7:42 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/#parentnode
Thank you.
By the way, I noticed another behavior difference between getElementById
and querySelector while implementing this. Consider this testcase:
data:text/html,script
On 10/23/13 4:39 AM, Simon Pieters wrote:
Or maybe we could remove the name lookup thing altogether for
Element.getElementsByTagName et al?
Hmm. There are some compat worries here; do we have any indications
that this name lookup is unused in the wild?
-Boris
On 10/25/13 2:42 PM, Ian Hickson wrote:
Step 17 (after going async) can jump back to step 8.
Ah, I see. That's pretty non-obvious. Can we restructure this somehow
to not have this random goto? That might help the understandability of
the spec here...
The main hard design constraint I
On 10/25/13 6:47 PM, Ian Hickson wrote:
Dunno about restructuring it exactly, but I've done the next best thing,
which is to add ample non-normative text explaining it.
Yep. The new text helps a lot, thanks!
Well, at the end of the day it's just a string comparison.
Sort of. _Changing_
On 10/22/13 2:42 PM, Ryosuke Niwa wrote:
Because of HTMLCollection's name getter, all major browsers must be capable of
a id+name lookup at every element (since Element has getElementsByTagName that
returns a HTMLCollection).
While true, in practice pretty much no one uses the name getter on
On 10/22/13 7:00 AM, Anne van Kesteren wrote:
So do you think we should add getElementById() to ParentNode in DOM?
I actually do, yes.
It seems the advantages are that we can optimize it better than
querySelector() because there is no selector parsing.
This, in my mind, is a somewhat minor
On 10/18/13 5:56 PM, Boris Zbarsky wrote:
I used a fairly large subtree that needs walking (1000
elements)
Er, I _meant_ to, but the testcase clearly only has 100 elements.
The numbers with 1000 elements are:
Chrome:
document.getElementById: 50
In-tree querySelector: 210
In-tree
On 10/18/13 3:11 PM, Tab Atkins Jr. wrote:
There's no perf boost available for searching by id on an arbitrary
element. The reason you may get a better perf for the normal
functions is that documents cache a map from id-element on
themselves, so you just have to do a fast hash-lookup.
On 10/17/13 4:04 AM, Ryosuke Niwa wrote:
I’ll add that Firefox and Internet Explorer both load about:blank
asynchronously.
Yes, but in the case of Firefox we consider that a bug.
In particular, we believe that the behavior web authors expect is for
the document to be created synchronously.
On 10/17/13 6:14 PM, Elliott Sprehn wrote:
frame = document.createElement('iframe');
document.body.appendChild(frame);
frame.contentDocument; // synchronously available
Yes, but at least in Gecko the frame.contentDocument you observe there
is not the same as what you'd observer after at
On 10/18/13 12:39 AM, Ryosuke Niwa wrote:
As far as I read the spec, the navigation happens synchronously.
It's worth defining the navigation in this context. I assume you mean
the invocation of
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
? If so, I
On 10/10/13 10:15 AM, Glenn Maynard wrote:
When I'm doing this I just make sure that the strings don't need
escaping in the first place. Many of these look like they do that
(probably most ID cases are things like random numbers or alphanumerics).
Let's take a look at Simon's examples from
On 10/10/13 11:43 AM, David Barrett-Kahn wrote:
Why is revealing when garbage collection happens such a terrible thing
anyway?
Because web pages can then start depending on GC timing, limiting the
kinds of GC optimizations browsers can do.
-Boris
On 10/10/13 2:41 PM, Ian Hickson wrote:
I feel this is a case where we're not putting authors first, but are
instead putting spec purity first.
Ah, that sums up my vague feelings of discontent here perfectly. +1000. ;)
-Boris
On 6/28/13 10:01 PM, Boris Zbarsky wrote:
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById(foo) is just querySelector(#foo)
This is actually false. For example, getElementById(foo:bar) is just
querySelector(#foo\\:bar), which is ... nonobvious.
And today someone asked me how to do
On 10/9/13 8:40 PM, Glenn Maynard wrote:
But it's already been suggested--by you--that we need a function to
CSS-escape a string
Sure. This was just an additional data point as to why: CSS escaping a
newline is not very obvious.
which seems to solve the that problem trivially (for users).
On 10/8/13 11:26 AM, Anne van Kesteren wrote:
Have we had success yet making id= and class= super-global? Not
sure we should extend the experiment prematurely.
In terms of DOM behavior, in Gecko we have been shipping an id
attribute on Element.prototype for a good long while now. We haven't
On 10/8/13 9:49 AM, Philip Jägenstedt wrote:
Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1]
but somewhat surprisingly also SVGElement implements
GlobalEventHandlers.[2]
Note that in Gecko SVG elements also have event handler content
attributes and whatnot.
What's your
On 10/1/13 12:58 PM, Ian Hickson wrote:
If the browser crashes, it's not going to be able to send messages anyway
This concept of the browser...
The situation being considered here is that you have two web pages in
two different OS-level processes that have a MessageChannel between
them.
On 10/1/13 1:45 PM, Ian Hickson wrote:
Crashing is non-conforming.
That's not useful. Crashing (or rather being killed by the OS) happens
all the time on tablets and phones. You get killed for using too much
memory, for not being active while other stuff is using too much memory,
for just
On 10/1/13 2:11 PM, Ian Hickson wrote:
How often do we expect two tabs to be talking to each other though?
Or a page to an out-of-process subframe?
How often do we expect MessageChannel to be used at all?
Is that even possible on phone browsers?
Sure is in Firefox and FirefoxOS.
Anyway,
On 9/23/13 4:25 PM, Ian Hickson wrote:
Isn't the answer to this question basically the answer to this thread?
I've lost track of what the question in this thread is...
This new ES5/ES6 stuff all goes over my head, to be honest. I can't wrap
my head around the implications, especially in a
On 9/12/13 5:24 AM, Anne van Kesteren wrote:
On Wed, Sep 11, 2013 at 7:22 PM, Ian Hickson i...@hixie.ch wrote:
Well presumably we wouldn't want to only do it for a, since then links
would work but SVG wouldn't (the exact opposite of the situation in Chrome
now, for what it's worth).
Yeah, we
On 9/12/13 11:55 AM, Anne van Kesteren wrote:
Last I checked, WebKit doesn't do it for hyperlinks, but does do it ad-hoc
for CSS url() stuff and a few other things, depending on how it's used.
Is this for SVG thingies referenced from CSS?
Or from SVG presentation attributes. Fill, filters,
On 9/12/13 2:36 PM, Gavin Barraclough wrote:
Hmmm, interesting. I was thinking that in the case that a shadowing
property was put to the named property object itself
Can't be done. Looking at the ES5 [[Put]], ownDesc is a data descriptor
here, so we land in step 3b, which calls
On 9/12/13 4:50 PM, Gavin Barraclough wrote:
Ah, good point. Firefox, Safari, Chrome all currently all allow this,
but seems reasonable to prohibit.
For what it's worth, Firefox nightlies prohibit it, ever since
https://bugzilla.mozilla.org/show_bug.cgi?id=895758 allowed us to
actually do
On 9/11/13 6:05 PM, Gavin Barraclough wrote:
Interesting, I had just assumed this was okay – is it not spec-compliant for
Window.prototype to be a named properties object?
No, it's not. The spec defines exactly what the prototype chain looks
like here. See the definitions of [[Prototype]]
On 9/10/13 2:55 PM, Dean Jackson wrote:
Ouch. Who is doing this and why?
Any browser in which zoom changes the size of a CSS pixel, and because
that's the definition of devicePixelRatio?
-Boris
On 9/10/13 3:54 PM, Ian Hickson wrote:
These seem like the logical places for it to be set. Am I missing
something?
No, you're not. I was.
Well, then they'll be broken, I guess. (They'll break safe, though.)
Well, the outcome is user can't use site. (Which they care more about
than
On 9/10/13 4:13 PM, Ian Hickson wrote:
I guess we'll just have to treat devicePixelRatio as legacy and introduce
a new value that's the real device:pixel ratio, then.
I would be interested in some data on what different UAs do with
devicePixelRatio...
-Boris
On 9/10/13 4:22 PM, Dean Jackson wrote:
I think there are two separate things a developer might want:
- the number of actual pixels that correspond to 1 CSS px without zoom
What are the use cases for this, as opposed to number of actual pixels
that correspond to 1 CSS px?
And are you
On 9/6/13 8:20 AM, Simon Pieters wrote:
So the use case is getting an element by id with an untrusted id as
input, in an element or document fragment as opposed to the document?
Or getting elements by tag name in a document fragment, for that matter
(though weird chars in tag names are harder
On 9/5/13 6:02 AM, Anne van Kesteren wrote:
Having said that, our current plan is to rely on the Selectors API (2)
In that case I think we need to add a function to the platform that
CSS-escapes a string. Because right now, writing
querySelector(# + id)
is a total footgun unless you
On 9/5/13 4:47 PM, Ian Hickson wrote:
In what sense?
In the sense that if its computed display is block but its layout
behavior is not that of a non-replaced block (CSS 2.1 section 10.3.3 and
so forth), then it's clearly a replaced element with layout behavior
defined by something other
Ccing public-script-coord, since that's the right place for this
discussion (because WebIDL is the relevant specification).
On 9/5/13 6:45 PM, Gavin Barraclough wrote:
Firefox and Chrome both return descriptors from an object on the prototype
chain per the spec
Chrome doesn't quite follow
On 9/4/13 8:07 PM, Ian Hickson wrote:
As far as I can tell, browsers keep treating it as an inline-block box in
those cases.
OK, that works, I guess. That does mean that buttons are a replaced
element, clearly, though... Something needs to spell that out.
-Boris
On 9/3/13 2:27 PM, Ryosuke Niwa wrote:
From the fact selector matching is slow.
Hold on. Back up.
Selector matching can't be all that slow per se: browsers do it a
_lot_. Do you mean doing the equivalent of document.querySelectorAll
can be slow?
-Boris
On 9/3/13 7:13 PM, Ian Hickson wrote:
Wouldn't checking for window.WebGLRenderingContext be just as unreliable
then? I don't understand why it's ok to be able to test that, but why
probablySupportsContext() wouldn't be ok.
I'm a lot more OK with the probablySupportsContext naming than
On 8/29/13 8:19 AM, Jake Archibald wrote:
Is this syntax compatible with datauris?
data:text/html,%!foo is handled identically in Presto, Blink, WebKit,
and Gecko (no Trident to test in right this second, sorry), and shows
the text. So if the proposed syntax were applied here it would
On 8/29/13 9:02 AM, Anne van Kesteren wrote:
Using the file extension and no sniffing of any sorts
Why?
-Boris
On 8/29/13 9:32 AM, Anne van Kesteren wrote:
Doing a mixture of sniffing and labeling has not served us very well.
We cannot rely solely on sniffing because of CSS and SVG. We can rely
solely on a standardized mapping table of extension to Content-Type.
Ah, ok, the extension table is
On 8/28/13 9:32 AM, Anne van Kesteren wrote:
I'm not sure we need to consider sub-scheme if zip-path can work as
it's more complex and not very well thought out. E.g. imagine
view-source:zip:http://www.example.org/zip!test.html.
What's the issue with that? Gecko supports that (with jar:, not
On 8/28/13 11:40 AM, Anne van Kesteren wrote:
On Wed, Aug 28, 2013 at 4:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
What's the issue with that? Gecko supports that (with jar:, not zip:),
fwiw.
As far as the web platform is considered today, URL objects are just
that. In Gecko you either
On 8/28/13 12:20 PM, Jonas Sicking wrote:
* It makes it impossible to have create a relative URL from inside the
zip file to refer to something on the same server but outside of the
zip file.
I think this comes back to use cases.
If the idea of having the zip is here is stuff that should live
The current mimesniff spec says that when the Apache workaround is
applied sniffing should still be able to detect the content as
PostScript, images, videos, archives, audio formats, etc.
I feel that this poses an unacceptable security risk due to allowing
content through firewalls that is
On 8/26/13 5:45 PM, Ryosuke Niwa wrote:
I propose to change the specification to remove any elements that are no longer
associated with the form from the past names map:
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map
Are you sure this doesn't break web
On 8/26/13 7:13 PM, Ryosuke Niwa wrote:
https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688
IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th
test cases.
You must be testing Firefox 23 or earlier? Firefox 24 or later passes
all these tests.
In any
On 8/26/13 9:51 PM, Ryosuke Niwa wrote:
That's good to hear. So we're definitely in agreement with respect to this new
behavior.
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23073
-Boris
On 8/23/13 12:33 PM, Tab Atkins Jr. wrote:
If a function currently takes a callback argument and returns void,
it's trivial to upgrade it to instead make the callback optional and
return a promise when it's not passed.
And null if a callback is passed?
If we want to continue returning void
On 8/23/13 1:23 PM, Tab Atkins Jr. wrote:
On Fri, Aug 23, 2013 at 10:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Aug 23, 2013 at 6:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If we want to continue returning void when a callback is passed, we need to
add some webidl magic
On 8/22/13 9:01 AM, Charles McCathie Nevile wrote:
The basic question is whether a validator should flag input
maxlength=2 value=abc as a conformance error or not. It seems to
me like it should.
Why? It seems that it generally works in browsers, and has for a long time.
Sort of. It gets
101 - 200 of 1308 matches
Mail list logo
