On 9/28/12 7:45 AM, Anne van Kesteren wrote:
I have been looking into defining javascript URLs on top of
http://url.spec.whatwg.org/ and would like some help. You get the
JavaScript source by concatenating the path and fragment, with #
inbetween of course, and then removing the percent encoding
On 9/28/12 11:19 AM, Anne van Kesteren wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1809
Gives â in Chrome (charCodeAt - 226). I cannot get it to alert in
my Nightly (18.0a1 (2012-09-28), Mac), Opera yields one FFFD and
Safari two. So maybe this is less of a problem than
On 9/28/12 11:34 AM, Boris Zbarsky wrote:
I'm not sure why it never hits the alert. A similar testcase not inside
the live dom viewer works just fine.
Oh, I see why it's different.
In the case I was testing (just loading a file from file://), the
javascript: URI is created from the string
On 9/28/12 1:30 PM, Anne van Kesteren wrote:
Well that is interesting. So the document encoding is not solely a
query component affair?
At least not for Gecko, no.
Does this only apply to javascript URLs? I
cannot get this to work for data URLs.
Looks like there's some javascript:-specific
On 9/28/12 2:26 PM, Ian Hickson wrote:
5) What happens when this doesn't match the origin or effective script
origin or whatever of the global object the script is evaluating
against.
I think this is specced. Can you elaborate on what you mean?
As long as it's specced, great. The
On 9/28/12 12:44 AM, Cameron McCormack wrote:
What about other functions from Object.prototype, by the way?
toLocaleString, watch, hasOwnProperty, etc.? If there are a bunch of
properties (that don't correspond to IDL members) that need protecting,
maybe handling it in [DefineOwnProperty] is
On 9/25/12 2:24 AM, Adam Barth wrote:
Also valueOf.
We'd just need to add that on the interface to make it work, right?
-Boris
On 9/25/12 12:54 PM, Adam Barth wrote:
I'm not sure what needs to be done in spec-land to make valueOf work
correctly, but in implementation-land it needs the same unforgability
mitigations as toString.
Well, one thing that needs to happen is that its behavior needs to be
specced. Should it
On 9/25/12 7:58 PM, Cameron McCormack wrote:
OK. I propose then that we allow [Unforgeable] on the interface, which
means:
* attributes get own, non-configurable accessor properties (with setters
if they are not readonly attributes), and no property on the prototype
* operations get own,
On 9/25/12 6:53 PM, Glenn Maynard wrote:
(Of course, a separate method could exist to get access to the underlying
order, if and when real use cases turn up that actually need it, and it's
not unlikely that there are use cases--but so far they haven't been
raised.
The obvious use case is
On 9/25/12 9:28 PM, Cameron McCormack wrote:
Boris Zbarsky:
I can live with this, but why is this better than just allowing
[Unforgeable] on all operations and attributes and defining an object
valueOf(); /* returns self */ on Location?
If we really do want to make all Location interface
On 9/25/12 9:48 PM, Cameron McCormack wrote:
Boris Zbarsky:
I guess the question is whether we're more likely to need [Unforgeable]
on some other entire interface or whether were more likely to need
[Unforgeable] on a single member that's not a readonly attribute. Of
course we might never need
On 9/25/12 10:13 PM, Glenn Maynard wrote:
The obvious use case is constructing a URI with a given query by
hand, right?
If you already have the a=1b=2 string, you can just assign it to
.search and not use the prepared-query-parameters interface at all.
I was thinking more like you
On 9/25/12 10:36 PM, Glenn Maynard wrote:
You usually don't care about the resulting order in that case, right?
It's not uncommon for servers to depend on a particular order of
parameters in the query string and totally fail when the ordering is
different. Especially the sort of servers
On 9/25/12 11:15 PM, Glenn Maynard wrote:
What this doesn't allow is creating things like a=1b=2a=3
Ah. That should be relatively unlikely (though forms with checkboxes in
them can in fact lead to query strings like that).
-Boris
On 9/24/12 4:58 AM, Anne van Kesteren wrote:
Say you have a href=data:test/; the concern is what e.g.
a.protocol and a.pathname would return here. For invalid URLs they
would return : and respectively. If we treat this as a valid URL
you would get data: and test. In Gecko I get http: and . If I
On 9/24/12 8:42 PM, Mihai Parparita wrote:
On Mon, Sep 24, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote:
Why does GMail need to use window.open()? Surely the right way to expose a
link is to use a href=. What is forcing them to use window.open()?
I can't speak for Gmail, but Google
Turns out, some things care about at least the .href and .toString of
Location objects for security-check purposes. So they need to be
unforgeable. But of course WebIDL doesn't provide a way to make
anything other than readonly attributes unforgeable. It seems like it
needs to.
In terms
On 9/21/12 11:16 AM, Anne van Kesteren wrote:
It is based on the
various URL code paths found in WebKit and Gecko and supports the \ as
/ in various places because it seemed better for compatibility.
Or worse, depending on your use cases...
* data URLs; in Gecko these appear to be parsed as
On 9/10/12 6:39 PM, Tobie Langel wrote:
interface WebGLActiveInfo {
readonly attribute GLint size;
readonly attribute GLenum type;
readonly attribute DOMString name;
};
That just added a WebGLActiveInfo property on Window.
Unless you meant to make this [NoInterfaceObject]?
On 9/4/12 12:30 PM, James Robinson wrote:
Many applications redraw the entire canvas on every frame
This is already assuming there are frames involved.
There are lots of applications (graphing comes to mind!) where you
really want the canvas to be essentially a write-once-read-forever image.
On 9/4/12 12:43 PM, Boris Zbarsky wrote:
1) Have a way for pages to opt in to software rendering.
2) Opt canvases in to software rendering via some sort of heuristic
(e.g. software by default until there has been drawing to it for
several event loop iterations, or whatever).
3) Have
On 9/4/12 1:02 PM, David Geary wrote:
Sure, but those use cases will be in the minority
What makes you say that?
Outside of games, I think they're a majority of the canvas-using things
I've seen.
I think it makes the most sense to add a context lost handler to the
spec and leave it up to
On 9/4/12 1:07 PM, David Geary wrote:
And then the browser presumably uses the img to regenerate the canvas on
a lost context?
No, then the author just forgets about the broken-ass canvas and shows
the img to the user. Basically using a canvas as a transient buffer
to get the image data
On 9/4/12 1:20 PM, Glenn Maynard wrote:
The only reason I can think of switch renderers, instead of
snapshotting, is to deal with losing the context *mid*-render, while a
script is still drawing. (That seems like a problem so rare as to be
almost theoretical, though.)
The main reason to
On 9/4/12 3:17 PM, Jussi Kalliokoski wrote:
When all references to the context are lost (garbage collected)
That never happens while the canvas itself is alive, since if nothing
else the canvas has a reference to the context.
-Boris
On 9/4/12 3:31 PM, Jussi Kalliokoski wrote:
Hmm... Is it visible to the page outside getContext() ?
No. Why does that matter?
-Boris
On 9/3/12 2:31 AM, Jukka K. Korpela wrote:
This was the case already in HTML 4.01
Yes, I know.
Generally, attempts at defining quirks mode would mean making it an
alternate mode and will not be successful due to the wide variation
across browsers and versions. It's called quirks for a
On 9/3/12 3:25 AM, Simon Pieters wrote:
Is there a compat problem with supporting it in quirks mode?
I did cover this in my post. The last time we tried it, there was, but
that was a while ago.
-Boris
Per HTML5 spec, rowspan=0 should span to the end of the table section.
WebKit seems to not implement this at all.
Opera implements this in quirks and standards mode.
Gecko implements this in standards mode only; in quirks mode,
rowspan=0 is treated like rowspan=1. When we last tried to do
On 8/29/12 10:15 AM, Fred Andrews wrote:
Yes, but fluid layout could use some calculations and is it likely that
declarative calculations would ever be added to CSS?
You mean other than http://dev.w3.org/csswg/css3-values/#calc ?
-Boris
On 8/29/12 6:18 PM, Ian Hickson wrote:
We're talking about when a document gets aborted here. Interop really
isn't particularly critical.
It depends on _why_ it was aborted. From a user point of view, having
aborted documents work correctly (including firing onload) is really
nice in many
On 8/28/12 2:12 AM, Ian Hickson wrote:
On Tue, 28 Aug 2012, Boris Zbarsky wrote:
As far as I can tell, 0 1 2 in your testcase at
http://damowmow.com/playground/demos/document-write-and-scripts/002.html is
consistent with the following order of execution:
1) x=0
2) x1=0,x=1 (nothing else has
On 8/28/12 1:27 PM, Ian Hickson wrote:
The latter. The blocking only affects scripts that are prepare the
scripted by the top-level parser, not a reentrant parser.
OK. I see.
This requires the blocked by state to live on an individual script
instead of on the document, right?
I _think_
On 8/28/12 1:51 PM, Ian Hickson wrote:
I beg of you, let's not make it any more complicated. :-)
Amen. Just trying to catch up on what the state of things is now... ;)
-Boris
Both Gecko and WebKit support script crossorigin and allow it to
affect whether window.onerror reports are sanitized for cross-site
scripts. This allows window.onerror to apply usefully to scripts from a
CDN.
There was mention of this on this list a while ago, but the spec still
doesn't say
I just added support for link rel=stylesheet crossorigin in
Gecko.[1] Such links are subject to CORS checks if the load is
cross-site, and the sheet load will fail if the CORS check fails. If
the CORS check succeeds, script in the page will be able to script the
cross-site stylesheet.
This
On 8/28/12 2:04 PM, Boris Zbarsky wrote:
An open issue: what to do about @import? I haven't done anything magic
here yet. Inheriting the CORS mode from the importing sheet is a bit
weird
Maybe I should explain weird.
If the CORS mode is inherited from the importing sheet, then I think
On 8/28/12 12:46 AM, Ian Hickson wrote:
I've updated the spec to not block on style sheets for nested parser's
scripts.
I'm not sure I follow. What is not going to block on what with this change?
As far as I can tell, 0 1 2 in your testcase at
On 8/22/12 4:53 PM, Mark Watson wrote:
Also, we've considered heartbeat type solutions, which whilst better than
nothing are vulnerable to an attack in which the heartbeat messages are blocked.
I'd like to understand this better. Would such an attack not also work
on XHR?
(I realize there
encode() should return a Uint8Array in the IDL, in my opinion. Right
now the prose says that it does, while the IDL has ArrayBufferView,
which doesn't make much sense to me.
-Boris
On 8/5/12 12:29 PM, Glenn Maynard wrote:
My recollection is this was to allow returning Uint16Array (or, more
specifically but currently unresolved, Uint16LEArray and Uint16BEArray) for
encoding to UTF-16 and UTF-16BE.
If that ever happens the return value can be changed at that point.
It's
On 8/5/12 1:39 PM, Glenn Maynard wrote:
I didn't say it was extensibility, just a leftover from something that
was either considered and dropped or forgotten about.
Oh, I see. I thought you were talking about leaving the return value
as-is so that Uint16Array return values can be added
On 7/30/12 12:02 PM, James Graham wrote:
If desired, I can try to figure out exactly why there's only one load
event on the first iframe there. Let me know.
That would be really helpful.
OK, I looked into this. There are two things going on:
1) Gecko fires the load event on the iframe as
On 7/30/12 11:10 AM, James Graham wrote:
I don't think I have a strong opinion about what should happen here, but
the Gecko behaviour could be easier to implement, and the WebKit
behaviour slightly safer (presumably the point of this anomaly is to
prevent infinite loops in load event handers).
On 7/25/12 7:14 AM, Bronislav Klučka wrote:
Should simple
tbody {height: 200px; overflow: scroll; }
work, and this feature is missing in browsers implementations?
Per CSS2.1 it should not work.
There's an out-of-date (older than CSS2.1) draft of CSS3 that says it
should, but doesn't actually
On 7/10/12 12:27 PM, Ian Hickson wrote:
Since it doesn't for any other attributes that take a string but where
empty string and absence are different, why is it suddenly an issue
specifically with this attribute?
Because this is a new attribute we're defining and I happened to notice? ;)
I
On 7/9/12 8:39 PM, Ian Hickson wrote:
Surely that's going to set the attribute regardless of whether the
attribute is nullable or whatnot.
Well, that depends on how reflecting DOMString? attributes are
defined. Making setting null call removeAttribute would work much like
boolean attributes
On 6/29/12 5:24 PM, Ian Hickson wrote:
Let me know if it's not quite right. I wasn't sure exactly what weird
things to test. I mostly relied on WebKit's (specifically Chrome's)
behaviour here since they were apparently the ones most recently affected
by real compat reasons to implement something
On 6/29/12 6:19 PM, Boris Zbarsky wrote:
In any case, I believe the spec is wrong in one aspect: in the case that
there is a default button, what needs to happen is a click event on that
button, not just a triggering of its activation behavior. In particular,
onclick handlers need to fire
On 6/29/12 7:20 PM, Ian Hickson wrote:
The main difference was that Chrome and Firefox differ in what input types
they support, which affects which they allow to affect the implicit
submission thing.
Oh, ok. Yeah, that's a bit of a mess... ;)
Oh, wow, yeah, the spec was just bogus there,
On 6/26/12 4:41 AM, Oscar Otero wrote:
I understand the problem. Sending only the window dimmensions, screen
resolution and other useful information available in media-queries can be
enought. For example:
Viewport: width=1024px; height=768px; scale=1;
Or even connection information:
On 6/25/12 1:34 PM, Oscar Otero wrote:
For example, for an image 100% width in a div of 400px, the browser
would send a header indicating it need a 400px width image.
The problem is that the browser typically does not know the following
pieces of information when it sends the image request:
On 6/20/12 3:16 PM, Andy Davies wrote:
Looking at waterfalls for a page loading Android 2.3 and iOS 5, it
appears that iOS does defer the non-applicable stylesheets - question
is why don't more browsers?
In Gecko's case it's as I said: stylesheet loads are often kicked off
before media query
On 6/19/12 1:56 PM, Charlie Reis wrote:
That's from the [if] the user agent
determines that the two browsing contexts are related enough that it is
ok if they reach each other part, which is quite vague.
This is, imo, the part that says unrelated browsing contexts should not
be able to reach
On 6/18/12 6:10 PM, Charlie Reis wrote:
I'm going to go out on a limb and say that it's ok if named but
unrelated windows are able to discover each other.
I actually don't; I think the fact that it happens in Firefox is a
(longstanding) bug that needs to get fixed.
If we want to change
On 6/13/12 4:55 AM, Simon Pieters wrote:
If it redirects, it switches to CORS. However, there are some bugs in
the spec... I just filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now.
Can we push this whole algorithm down into the CORS spec? It looks like
at this point
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different ones, based on whatever
heuristics it uses for
On 6/12/12 4:47 AM, Simon Pieters wrote:
The potentially CORS-enabled fetch algorithm ignores the state of the
crossorigin attribute when the URL is same-origin.
Hmm. On the face of it, this seems like a bug when open redirectors are
involved... Is this what UAs implement in practice?
On 6/12/12 6:30 AM, James Graham wrote:
Based on some tests ([1]-[5]), it seems that WebKit seems to cancel the
navigation in the unload handler always, Opera seems to always carry out
the navigation in the unload handler, and Gecko seems to follow WebKit
in the cross-origin case and Opera in
On 6/10/12 11:26 PM, Scott Jehl wrote:
These are fair answers, but I can't help but think that the problem
is critical enough to warrant spec-level consideration.
Oh, yes. The question is how to spec this in a way that doesn't
overconstrain future implementations to behave suboptimally.
I
On 6/11/12 5:48 PM, Ian Hickson wrote:
Right now I haven't specced anything like this. Ideally I'd like to move
all the CSS logic out of the HTML spec, since e.g.I assume that any
caching forlink rel=styleseet would also need to happen for @import.
It does in Gecko, yeah.
-Boris
On 6/10/12 12:51 PM, Scott Jehl wrote:
I'd like to propose that the spec recommends that vendors defer the
loading of Stylesheets referenced via inapplicable media so that they
do not block page rendering.
One issue with this is that in many cases the UA may not yet know what
media queries
On 6/10/12 4:33 PM, Scott Jehl wrote:
One issue with this is that in many cases the UA may not yet know what
media queries apply to the document when starting the sheet loads. In
some cases it does, of course, but those may be rarer than you think…
That makes sense. For my own understanding,
On 6/6/12 7:47 PM, Ian Hickson wrote:
On Fri, 27 Jan 2012, Boris Zbarsky wrote:
On 1/27/12 1:30 AM, Ian Hickson wrote:
On Wed, 5 Oct 2011, Henri Sivonen wrote:
On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarskybzbar...@mit.edu wrote:
What Firefox does do is block execution ofscript tags
The list is at
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#support-the-scripting-language
or
http://dev.w3.org/html5/spec/the-script-element.html#scriptingLanguages
depending on which you prefer to read.
It seems to include several values that no UA actually
On 5/24/12 5:02 PM, Maciej Stachowiak wrote:
I agree. Even though there are still legacy features like cookies and
document.domain that use domain-based security, most of the Web platform uses
origin-based security
For security, yes.
But for, say, resource limits, one wants to use
On 5/24/12 11:00 PM, Xavier Ho wrote:
The door's already open. You simply have to iterate through all the
nodes, and call removeEventListener with all possible events.
No. removeEventListener needs the actual object that was passed to
addEventListener to remove the listener.
-Boris
On 5/21/12 10:09 AM, Mounir Lamouri wrote:
On 05/20/2012 03:04 PM, Boris Zbarsky wrote:
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is
aware
of the Network Information API [1], which provides
navigator.connection.bandwidth
It's been
On 5/21/12 10:42 AM, James Graham wrote:
Can you point me to the discussion of usecases that led to this design?
Me personally, no. I wasn't involved in either the spec or the Gecko
impl; I'm just reading the code
-Boris
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is aware
of the Network Information API [1], which provides
navigator.connection.bandwidth
It's been recently implemented (to some degree) in both Mozilla [2] and
Webkit [3].
As far as I
On 5/18/12 3:16 AM, Markus Ernst wrote:
1. Are there other cases in HTML where an attribute value contains more
than one URI?
* The archive attribute of applet (comma-separated list of URIs)
* The ping attribute of a (space-separated list of URIs)
* The style attribute (which can, e.g., set
On 5/15/12 7:33 PM, Kornel Lesiński wrote:
In fact, I'd keep @media, because it serves some cases very well (I see
dpi/bandwidth optimisation as a problem orthogonal to layout adaptation:
http://geekhood.net/MediaQuery-vs-PerfQuery.png)
@media on video source is terrible for layout adaptation:
On 5/14/12 11:55 AM, Tab Atkins Jr. wrote:
That's why I mentioned an inlinestyle at the top of thebody -
I'm not sure if browsers skip past that when building the tree or not,
They certainly skip past such things when prefetching.
Putting information that needs to affect prefetching in
On 5/13/12 7:26 AM, David Goss wrote:
but it'd be irresponsible to just serve an
img with the high res source to all users, making them wait longer
for the download even though they can't see the extra quality on their
screen.
Except when they can, e.g. by printing or moving the display to
On 5/13/12 12:21 PM, Mathew Marquis wrote:
The amount of “developers can never be trusted with this” sentiment I’ve heard
from the members of this group is incredibly depressing.
For the record, developing a web browser and in the process realizing
how much web content is fundamentally
On 5/13/12 3:20 PM, Mathew Marquis wrote:
I doubt any UAs will be forced to misinterpret common media queries because
they haven’t been accounted for.
Opera has already been forced to do this. For example, in its
projection mode it matches both the projection and screen media
queries
On 5/12/12 9:28 AM, Mathew Marquis wrote:
While that information may be available at the time the img tag is parsed, I
don’t believe it will be available at the time of prefetching
Which information?
At least in Gecko, prefetching happens when the tag is parsed.
So in fact in Gecko the
On 5/10/12 10:19 AM, Mathew Marquis wrote:
Hey guys. Don’t know if it’s too early to chime in with this, but we were told
by some members of the Chrome team that any browser that supports DNS
prefetching — including assets — wouldn’t consider “looking-ahead” on the img
tag as an option.
Why
On 5/7/12 3:53 AM, Tab Atkins Jr. wrote:
A page can set up an unloadHandler immediately on loading, and just
keep its .data property updated over time. The author is then secure
in the knowledge that, barring complete computer destruction, if the
user shuts down their browser the server will
On 5/7/12 11:53 AM, Tab Atkins Jr. wrote:
Yes, definitely (unless you set .withCredentials on it or something,
like the XHR attribute).
Hold on. If you _do_ set withCredentials, you should be required to
pass the credentials in or something. Under no circumstances would
prompting for
On 5/7/12 11:54 AM, Bronislav Klučka wrote:
I see pages doing it is that they're up to no good well that is your
opinion, sure, we have all seen bad use of that, but removing
functionality that has no replacement, can be used for useful thinks
(well for bad as well) can hardly be reasonable
On 5/7/12 12:10 PM, Bronislav Klučka wrote:
I'm not sure about whole functionality removed without replacement...
You wrote to Tab the legitimate use-case for popup windows is also
reasonable, yet browsers have popup blockers. sure, but this
functionality was not removed, etc...
There are
On 5/2/12 6:09 PM, Ian Hickson wrote:
On Fri, 19 Nov 2010, Boris Zbarsky wrote:
Given that SVG also has classes, it would make some sense to move
classList from HTMLElement to Element. That way SVG, and any other
languages that define classes (XUL comes to mind, actually) can benefit
from
On 4/30/12 10:11 AM, David Young wrote:
I guess thattextarea has worked this way for a very long time,
so changing it may not be possible. I'm curious to see examples of
which/how web content depends on it?
I don't have links offhand, but I've definitely seen scripts assuming
that getting
On 4/29/12 11:24 PM, David Young wrote:
It seems that the text contents of atextarea, at least, could be
properly in the DOM?
Not really: when you type in a textarea, that doesn't change its actual
DOM kids. Both per spec, and in UAs, and web content depends on this.
-Boris
On 4/23/12 5:57 PM, Charles Pritchard wrote:
Currently, if you want to do fast operations on a Canvas, you need to
load it into WebGL and use GLSL to do your quick vector math.
It'd be nice to see a math object for Typed Arrays with similar power.
On 4/17/12 6:32 PM, Darin Fisher wrote:
In Chrome at least, getImageData() doesn't actually block to fetch pixels.
The thread is only blocked when the first dereference of the pixel buffer
occurs.
How does that interact with paints that happen after the getImageData
call? Or is the point
On 4/12/12 3:30 PM, Ojan Vafai wrote:
We should add a crossorigin property on iframe that causes the request to
use CORS.
Which request? Just the @src load? Or navigation of the frame via its
Location object too?
If it's an allowed cross-domain request, then the page should
have access
On 4/12/12 3:49 PM, Adam Barth wrote:
The seamless part might be workable, since that leaks information only
from the document in question. It's possible that there's a better
mechanism than CORS for a child frame to opt into being seamless with
its parent.
Yes, I agree that having a way for
On 4/9/12 2:16 PM, Gavin Peters (蓋文彼德斯) wrote:
However, this is strikingly similar to two other cases: when alink
rel=stylesheet ... element is removed from the document, in WebKit, we
remove the stylesheet from the document, although this isn't explicitly
specified in 4.12.5.11,
On 4/3/12 5:14 PM, Glenn Maynard wrote:
Ten years later it's still giving me headaches, when I try to do a
trivial two-input login form without a browser submit button, and find
that every obvious way of hiding the submit button breaks implicit
submit in one browser or another. Do I really need
On 4/2/12 7:39 PM, Ian Hickson wrote:
For example, an attacker could open a window on a victim web page. The
victim web page then opens aniframe on a content URL that triggers
RPH. The attacker then navigates theiframe so that its
window.location contains a different content URL.
How can the
On 4/1/12 4:43 PM, Nils Dagsson Moskopp wrote:
Jose Fandosiaminlon...@gmail.com schrieb am Sun, 1 Apr 2012 21:15:10
+0100:
Can anyone point to any discussions about table headers and table
bodies and how to deal with having a fixed header and a scrollable
body?
Did you try “overflow:
On 3/28/12 12:49 AM, Robert O'Callahan wrote:
On Wed, Mar 28, 2012 at 5:33 PM, Charles Pritchardch...@jumis.com wrote:
It does seem like a bigger warning in the spec may benefit developers.
A warning and an example of how to check for big-endian results.
Asking developers to write extra
On 3/28/12 12:59 AM, Charles Pritchard wrote:
I've no desire to coddle low-level coders. They know what they're
getting into.
You're making the mistake of thinking that people using typed arrays are
low-level coders, whereas in reality everyone and their mother is
being told to use the
On 3/28/12 1:14 AM, Charles Pritchard wrote:
Most developers work with multiple programming languages. They read
manuals, they read blogs, they try things out, and then they often code
more in other languages than in JS.
Are you sure this is true for most developers creating web content?
But
On 3/28/12 1:22 AM, Charles Pritchard wrote:
You are making the assertion that deliberately misleading in terms of
what it takes to achieve interoperable behavior.
Yep.
And you and Robert have given reasons why you believe developers will
make many mistakes.
No, I'm just saying developers
On 3/28/12 2:04 AM, Jonas Sicking wrote:
Consider a big-endian platform where both the CPU and the GPU is
big-endian. If a webpage writes 16bit data into an ArrayBuffer and
then sends that off to the GPU using WebGL, the data had better be
sent in big-endian otherwise the GPU will interpret it
On 3/28/12 2:32 AM, Mark Callow wrote:
Then, if you are on a big-endian system an app will not be able to read
write int, float, etc. into the int32Array, float32Array, etc.
Why not?
-Boris
401 - 500 of 1308 matches
Mail list logo
