On 3/28/12 2:22 AM, Jonas Sicking wrote:
Except if the data was written in 32bit units you do a different byte
swapping than if the data was written as 16bit units.
Hmm. I just read the webgl spec more carefully and discovered that
bufferData() actually takes a byte array whose structure is
On 3/28/12 2:40 AM, Mark Callow wrote:
On 28/03/2012 18:33, Boris Zbarsky wrote:
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?
Because you said JS
On 3/28/12 3:01 AM, Mark Callow wrote:
So now you are saying that only the JS-visible state of ArrayBuffer is
little-endian.
The JS-visible state of conversions from multi-byte-sized quantities to
bytes or back is little-endian.
The JS-visible state of int32Array, etc. is in
On 3/28/12 3:14 AM, Mark Callow wrote:
vertexAttribPointer lets you specifiy to WebGL the layout and type of
the data in the buffer object.
Sure. That works for the GPU, but it doesn't allow for the sort of
on-the-fly endianness conversion that would be needed to make webgl
still work on
On 3/25/12 7:45 AM, Geoffrey Sneddon wrote:
On 21/03/12 04:31, Mark Callow wrote:
On 17/03/2012 08:19, Boris Zbarsky wrote:
I think that trying to get web developers to do this right is a lost
cause, esp. because none of them (to a good approximation) have any
big-endian systems to test
On 3/26/12 3:13 PM, Mounir Lamouri wrote:
I do not like [PutForwards=value] but I still believe
DOMSettableTokenList is useful.
I think the issue in this case is that the DOMSettableTokenList
representation of the sandbox attribute, as specced, cannot distinguish
between not sandboxed at all
On 3/26/12 3:19 PM, Ian Hickson wrote:
Changing it to a string doesn't affect that, though, does it?
Well, changing to a nullable string does affect it because doing
something like this:
myFrame.sandbox = myFrame.sandbox;
is a no-op, as by all sane rights it should be More
On 3/21/12 5:36 AM, Andrew Oakley wrote:
Are there similar caches for any other type of object or is this just
images?
Gecko has a similar (different in mechanism, but not too different in
effect) cache for stylesheets. I seem to recall that there was explicit
text about this as well, but I
On 3/20/12 3:00 PM, James Robinson wrote:
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many optimization
opportunities that are currently difficult or impossible.
You mean like not blocking the world on the readback?
That
On 3/20/12 6:36 PM, Glenn Maynard wrote:
The drawing calls that happen after would need to be buffered (or
otherwise flush the queue, akin to calling glFinish), so the operations
still happen in order.
The former seems like it could get pretty expensive and the latter would
negate the
On 3/20/12 6:50 PM, Adam Barth wrote:
I'm not suredialog addresses the same use cases as alert() and
confirm() becausedialog is significantly more complicated.
But also allows for much better UX...
dialog id=orderConfirm
Are you sure you want to order the widget?
button
On 3/20/12 7:04 PM, Glenn Maynard wrote:
If you have previous drawing commands buffered, and you want to avoid extra
copies, then putImageData has to block until the buffered drawing commands
complete.
Yes, but if you're drawing to a GPU directly you want to make the copy
up front, imo;
On 3/16/12 5:12 PM, Joshua Bell wrote:
FYI, there was some follow up IRC conversation on this. With Typed Arrays
as currently specified - that is, that Uint16Array has platform endianness
For what it's worth, it seems like this is something we should seriously
consider changing so as to make
On 3/16/12 5:44 PM, Charles Pritchard wrote:
The DataView set of methods already does this work. The raw arrays are
supposed to have platform endianness.
I haven't seen anyone actually using the DataView stuff in practice, or
presenting it to developers much...
If you see some evangelists
On 3/16/12 5:25 PM, Brandon Jones wrote:
Everyone knows that typed arrays /can/ be Big Endian, but I'm not aware
of any devices available right now that support WebGL that are.
I believe that recent Firefox on a SPARC processor would fit that
description. Of course the number of web
On 3/16/12 7:43 PM, James Robinson wrote:
You can s/web developers/users/ and the statement would still apply,
wouldn't it?
Sure, but so what?
The upshot is that people are writing code that assumes little-endian
hardware all over. We should just clearly make the spec say that that's
what
On 3/14/12 3:59 PM, Christian Schmidt wrote:
Bjartur Thorlacius skrev 2012-03-09 10:43:
I argue that putting user interface hints into a file transfer
protocol does cause problems
Would it be better if the Window-Target was somehow specified in the
head of the destination page
That's pretty
On 3/2/12 5:59 AM, Gray Zhang wrote:
div
!-- This link element only works for it's containing div --
link rel=stylesheet
href=3rd-party-theme/user-published-20120302133702.css scoped=scoped /
span class=keywordfunction/spanspan
class=identifiertest/span...
/div
div
style
On 2/29/12 1:14 PM, Erik Arvidsson wrote:
Now that we are removing usages of DOMStringList it is also tempting
to look at other list interfaces that only have item/length. Searching
through the WebKit IDL files the following are dumb:
ClientRectList
This is not live.
CSSRuleList
This is.
On 2/29/12 2:58 PM, Charles Pritchard wrote:
I'm pretty sure the live ones can't right?
If it's behind a method call, perhaps even a parent attribute, there's
opportunity to regenerate, long as there aren't too many sites out there
optimizing out the access call.
That a big as long as.
On 2/24/12 12:36 PM, Hans Muller wrote:
Good point, although this approach seems to lead to the very same dystopia
you
were just warning about. If everyone tries to schedule their image
listener last
with setTimeout()...
Sure. There's no way to fix that problem technologically. Just saying
On 2/23/12 7:38 PM, Hans Muller wrote:
Hans - It's useful if you want your listener to run after all of the
load listeners have run, and code that you haven't written adds its own
load listeners.
I strongly urge you to read
http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/426294.aspx
On 2/21/12 7:35 PM, Ian Hickson wrote:
On Sun, 25 Sep 2011, Boris Zbarsky wrote:
Not doing that last is actually a requirement for web compat, last I
looked at this.
Do you have any links to pages that break if a form with more than one
text field supports implicit submission?
Not offhand
On 2/21/12 10:47 PM, Dimitri Glazkov wrote:
I made WebKit match this behavior a couple of years ago:
https://bugs.webkit.org/show_bug.cgi?id=9756
Ah, interesting. Some of the links in that bug indicate that people are
in fact depending on this behavior
-Boris
On 2/13/12 3:00 AM, Simon Pieters wrote:
Exactly. My proposal, again, is that neither of these quirks apply
inside a shorthand.
But this is not what Gecko does.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1339
As I said earlier, I have no idea what's going on with 'font'
On 2/13/12 5:33 AM, Bjartur Thorlacius wrote:
2. On an album page where hundreds of pictures are expected to be shown,
it is often required that pictures currently in a user's screen should
appear as fast as possible. Loading of a picture outside the screen can
be
deferred to the
On 2/13/12 1:39 AM, Gray Zhang wrote:
1. the @defer attribute onimg andiframe
2. the similar @deferpolicy attribute with value a combination of visible,
network-idle and render-idle
3. a global switch as a http header or an attribute on html to switch
UAs image loading from
On 2/13/12 9:29 AM, Bjartur Thorlacius wrote:
On Mon, 13 Feb 2012 14:17:28 -, Boris Zbarsky bzbar...@mit.edu wrote:
This is a difficult optimization to make. You can only do it for
images that have a height and width specified in the markup, and worse
yet it leads to pretty bad flicker
On 2/13/12 1:52 PM, Bjartur Thorlacius wrote:
Not knowing the size makes it _impossible_ to do layout correctly.
Again, UAs would only be able to skip getting images that have
explicit height and width attributes.
On the contrary, if you've laid out two screenfuls you can guess that
anything
On 2/10/12 2:57 AM, Simon Pieters wrote:
1) I'm fairly certain the Images (img elements) without alt
attributes sometimes display placeholder icons in quirks mode. quirk
cannot be dropped.
...
The HTML specification specifies this quirk in the Rendering section.
On 2/10/12 11:23 AM, Aryeh Gregor wrote:
On Fri, Feb 10, 2012 at 10:37 AM, Boris Zbarskybzbar...@mit.edu wrote:
I agree that having the list for lengths reduces the scope of the problem
somewhat. But the color quirk means that any shorthand that includes colors
will run into ambiguity issues
On 2/9/12 3:20 PM, Pablo Flouret wrote:
What should be happening here ideally?
The alert call throwing? ;)
Not entirely facetiously,
Boris
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
On 2/8/12 3:20 PM, Ian Hickson wrote:
In any case, in my testcase the entry script is the one running in
test1.html, but the alert is being associated with test2.html. In
general, I would expect that alerts are associated with the window that
was the |this| for the alert call
I shouldn't
On 2/8/12 3:50 PM, Ian Hickson wrote:
Should events be paused on detached iframes? Or another question?
(Sorry, I've lost the context here.)
The thread is discontinuous in the archives (why?), but I think the
relevant part was:
It's possible to switch these relevant checks to walk the
On 2/7/12 9:13 AM, Matthew Wilcox wrote:
To be clear: this is a case of browser vendors deciding it's too
expensive and therefor not allowing it to be implemented
This is a case of browser vendors (or at least me with my browser
implementor had on) thinking that sending this sort of
On 2/7/12 4:28 AM, James Graham wrote:
This basically amounts to the requirements were wrong.
Given the limited information I have so far, yes.
Since the same developer made both the desktop and mobile frontends and he is
one of
the major users of the system, and the mobile frontend was
On 2/7/12 12:32 PM, Matthew Wilcox wrote:
This is a case of browser vendors (or at least me with my browser
implementor had on) thinking that sending this sort of information
will hurt their users' privacy
Can you clarify how this hurts privacy? I'm not sure how reporting back
On 2/7/12 12:34 PM, David Goss wrote:
On 7 February 2012 17:11, Boris wrote:
This is a case of browser vendors (or at least me with my browser
implementor had on) thinking that sending this sort of information will
hurt their users' privacy...
Sorry if I'm missing something obvious, but how?
On 2/7/12 2:52 PM, Matthew Wilcox wrote:
Reporting more information about the user's hardware and software to
the server allows better fingerprinting and hence tracking. See
https://www.eff.org/deeplinks/__2010/01/primer-information-__theory-and-privacy
On 2/7/12 3:59 PM, Matthew Wilcox wrote:
Fair enough. This then becomes a cost/benefit issue. But there's nothing to
stop this working if the user's default is an opt out and a prompt is given to
allow. In exactly the same way that things currently work for geo-location
data. Right?
Maybe.
On 2/7/12 5:06 PM, Matthew Wilcox wrote:
I agree about this. But realise that if we take your zoom use case to
it's logical conclusion, we'd need to supply images at an infinite
resolution. Which is patently absurd. With visual media, it is
expected, and the only practical thing, to have
On 2/7/12 7:16 PM, Ian Hickson wrote:
All of the above seem consistent with what the spec requires.
Firefox actually seems to have a slight bug, which is that the event loop
keeps pumping in the original page, but that seems like a separate issue.
Here's the test case you describe above:
On 2/6/12 5:37 AM, Henri Sivonen wrote:
FWIW, I'm completely unsympathetic to this use case and I think we
shouldn't put engineering effort into supporting this scenario.
That depends on timeframes.
As far as the user is concerned, it would be much better for the site to get
its act together
On 2/6/12 10:52 AM, Matthew Wilcox wrote:
1) client asks for spdy://website.com
2) server responds with content and adds a request bandwidth device
screen size header
Again, the screen size is not invariant during the lifetime of a page.
We should not be encouraging people to think that it
On 2/6/12 11:27 AM, Matthew Wilcox wrote:
I disagree. Screen size is at times *exactly* what is needed, as it *is*
constant throughout the experience.
No. It's just not, for at least two reasons:
1) Screen sizes are reported to the page in CSS pixels, and the number
of CSS pixels per
On 2/6/12 11:42 AM, James Graham wrote:
No, but there is a different *typical* screen size/resolution for
mobile/tablet/desktop/tv and it is common to deliver different content
in each of these scenarios. Although people could load the same site on
desktop and mobile set up to have the same
On 2/6/12 12:33 PM, Ryosuke Niwa wrote:
This might be a valid use case for a device capability API since
different devices may have completely different platform conventions for
UI and workflow such that using the same UI as the one served for
desktop computers isn't desirable.
Yes, indeed.
On 2/6/12 12:45 PM, Charles McCathieNevile wrote:
This might be a valid use case for a device capability API since
different devices may have completely different platform conventions for
UI and workflow such that using the same UI as the one served for desktop
computers isn't desirable.
Yep.
On 2/6/12 1:55 PM, Irakli Nadareishvili wrote:
Many thanks to everybody who has responded and for a lively and a productive
discussion!
Quick clarification: the proposal is to include *device* capabilities in the HTTP
headers, so when we say screen width and height we mean device screen width
On 2/6/12 1:55 PM, Bjartur Thorlacius wrote:
On Mon, 06 Feb 2012 17:44:30 -, Boris Zbarsky bzbar...@mit.edu wrote:
Yes, indeed. Supports touch input on multiple spots at once vs
supports only a mouse seems like a much more important distinction
than the nominal CSS pixel size of the screen
On 2/6/12 2:24 PM, Irakli Nadareishvili wrote:
if you don't mind me saying it, I am afraid you may be missing the point of
this request.
I certainly hope I am! What I understood the request to be doesn't make
any sense.
In Responsive Web Design, device capabilities are used in a
On 2/6/12 2:26 PM, Bjartur Thorlacius wrote:
On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky bzbar...@mit.edu wrote:
That really depends on what the application is doing. Depending on
input capabilities, you may want to have multiple pages instead of a
single page for some sort
On 2/6/12 3:00 PM, Irakli Nadareishvili wrote:
1. Adaptive images:
To optimize user-experience on smart-phones (most of which have relatively
small screens, and are on slow connections most of the time) we need to send
lower-resolution or resized versions of high-resolution images that would
On 2/6/12 3:10 PM, Matthew Wilcox wrote:
On 6 Feb 2012, at 18:58, Boris Zbarsky wrote:
On 2/6/12 1:55 PM, Irakli Nadareishvili wrote:
Many thanks to everybody who has responded and for a lively and a productive
discussion!
Quick clarification: the proposal is to include *device
On 2/6/12 3:20 PM, James Graham wrote:
1) Same URL structure as the main site
OK, makes sense.
2) Less (only citical) information on each screen
Why not do this for the desktop version as well?
Alternately, if it's nice to see the information at a glance on desktop,
why not make the UI
On 2/6/12 5:21 PM, Ashley Sheridan wrote:
I can't remember where right now, but I do recall seeing an article
which said that it was a common misconception that mobile devices were
most often on a slow connection. Personally, I tend to make most use of
my mobile for browsing when I'm on a
On 2/4/12 2:28 PM, irakli wrote:
Something as simple as if browsers passed along device's width/height
information
This information can change between page load and page unload (and in
fact, it can change between the HTTP request being sent and the HTTP
response being received).
All
On 2/4/12 5:57 PM, Bjartur Thorlacius wrote:
Do make note of the dynamic nature of many viewports* and the fact that
user agents may wish to render resources to multiple medias. The latter
is rare enough to tolerate an extra roundtrip.
Actually, printing an already-loaded page typically can't
On 2/3/12 3:07 PM, Ian Hickson wrote:
OK. I have no serious problem with a beforeprocess event that fires
before processing the response, esp. if processing is defined in a
page-visible way (so e.g. you could still compile a script in the
background before firing beforeprocess; you just
On 2/3/12 3:38 PM, Ian Hickson wrote:
I also believe that we have proposed this for standardization in the
past, though it seems to have fallen through the cracks a bit...
I couldn't find any mention of it in the WHATWG archives or Bugzilla,
though I did find an e-mail from sicking saying he'd
On 2/3/12 11:15 PM, Ian Hickson wrote:
No, I agree with you that if the author is using HTTP styles on their
HTTPS page that an attacker could screw with the page. But my point is
that fixing that is easy: just move the styles to HTTPS. In the case of
scripts it's not that easy because the
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 (but not
timeouts, callbacks, etc!) if there are pending non-altenate
parser-inserted
On 1/26/12 9:12 AM, Adam Barth wrote:
Should the speculative parser have knowledge ofmeta name=referrer?
That's not what's currently specified. Like many other browser
features, this feature lets web sites detect that the browser is
speculatively prefetching resources. If that's a big issue,
On 1/25/12 3:41 PM, David Geary wrote:
On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrincmar...@apple.com wrote:
You can apply CSS Filters to a Canvas element. Maybe it would be better to
put the items you want filtered into a separate canvas element and use CSS
Filters on that? The big advantage
On 1/18/12 10:00 PM, Elliott Sprehn wrote:
SVG taints the canvas in every browser I've tried
You should try a Firefox aurora (soon to become beta) build, then.
See https://bugzilla.mozilla.org/show_bug.cgi?id=672013
Whether other UAs can fix this bug on their end faster than they can add
On 1/17/12 7:49 AM, Henri Sivonen wrote:
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarskybzbar...@mit.edu wrote:
Preventing _all_ loads for a document based on
some declarative thing near the start of the document, on the other hand,
should not be too bad.
A page-wide disable optimizations
On 1/17/12 7:24 PM, James Robinson wrote:
Even this scheme doesn't work with a model like SPDY push or other
bundling techniques or with more aggressive preloading that initiates
loads before the main resource is loaded.
Er... you mean it initiates loads before it has any idea whether the
On 1/17/12 7:37 PM, Tab Atkins Jr. wrote:
SPDY push allows the server to send down additional resources along
with the main resource, before the client actually requests them.
(The server, ideally, should know what resources the main resource
links to.)
Ah, ok. Yeah, there's obviously no way
On 1/17/12 7:37 PM, James Robinson wrote:
The way that these sorts of schemes work is that the server knows that a
set of resources are needed in addition to the main resource and it
starts sending them down before the client has received/parsed the main
resource. The server serving foo.html
On 1/12/12 9:22 AM, Boris Zbarsky wrote:
On 1/12/12 5:16 AM, Simon Pieters wrote:
Note that it
removes the root element when the script element is executed, not at
DOMContentLoaded.
Ah, I missed that. I guess the HTML5 parsing algorithm means that now
the elements are parsed into the other
On 1/13/12 2:50 AM, Roman Rudenko wrote:
True. In its current form, beforeload is not very useful for partial processing.
What if we had 'beforedownload' event specifically for resource
fetching, and constructed stub elements to feed it as event.target
when load is readahead-induced?
That
On 1/12/12 5:16 AM, Simon Pieters wrote:
Note that it
removes the root element when the script element is executed, not at
DOMContentLoaded.
Ah, I missed that. I guess the HTML5 parsing algorithm means that now
the elements are parsed into the other document, eh? That's actually
pretty
On 1/12/12 12:46 PM, Francis Boumphrey wrote:
and as far as I can see there is no way for me as an author to
know that the video is not being played
If true, this should be simple to fix. But I would think that there was
a way to detect this via the readyState or error properties. In
On 1/12/12 1:27 PM, Ojan Vafai wrote:
This only works for the initial page load, no?
Yes, but does mobify use the beforeload handler after the initial page
load? They're generating new content and document.writing it back into
the document, and that new content needs to perform loads, so I
On 1/12/12 2:19 PM, Roman Rudenko wrote:
For example, @media-controlled mobile view of a page
originally designed for desktop will typically include all desktop
assets. beforeload can fix that, as desktop resource loads could be
cancelled or even replaced with mobile-specific ones without
On 1/12/12 9:23 PM, Roman Rudenko wrote:
Blocking is possible under some circumstances. Webkit differentiates
between normal parser and speculative parser. Speculative parser is
launched only if normal parser is blocked on execution of a script.
So, one could use beforeload to block resources in
On 1/11/12 6:59 AM, Simon Pieters wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297
Might not be cross-browser yet (e.g. Opera seems to run the image's
onload handler), but should work per spec I think. Well, the load can't
be prevented if it's speculatively loaded it
On 1/10/12 1:54 PM, Darin Adler wrote:
On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote:
So in WebKit this event is only good for preventing _processing_ of the data in the
page (e.g. preventing the script from executing when the target is ascript)
but not much use for preventing loads, even
On 1/10/12 12:48 AM, Tantek Çelik wrote:
Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4]
It's more like one person in a Mozilla bug has suggested that it be
implemented, while others, myself included, are a bit skeptical.
The devil, of course, is in the
On 1/10/12 1:02 AM, Boris Zbarsky wrote:
I'd like to understand the client-side transformation use-case better,
in particular. What is it really trying to do?
OK, I got more context on this. The goal of the client-side
transformation case is effectively do something like what one can do
On 1/2/12 1:55 AM, Simon Pieters wrote:
What about:
head
script src=foo.js/script
meta name=referrer content=never
link rel=stylesheet href=a.css
/head
...and the browser speculatively fetches the stylesheet before the
meta element is in the DOM? Should the speculative parser have
knowledge of
On 12/27/11 9:20 PM, Leif Halvard Silli wrote:
I think http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html should
follow Trident/WebKit. Specifically: utf-16 defaults to utf-16le in
absence of a BOM.
One interesting question here: Does this apply to web-facing things
only, or also to
On 12/21/11 6:36 PM, Elliott Sprehn wrote:
Yup, that's exactly what I observed, but I can't find documentation
that says that. Every page I can find about almost standards mode
talks about table cells. Even Mozilla's page says it's only for images
in table cells.
Yeah, the person who wrote
On 12/15/11 3:10 PM, Ian Hickson wrote:
Whether it'swbr ornobr that gets defined in terms that violate CSS,
the result is the same as far as I can tell.
Fair. We may need changes or extensions to CSS if nothing else works.
If we make a change here it seems better to move towards just
On 12/14/11 8:05 PM, Ian Hickson wrote:
it was with respect tonobr, which we now
define in terms of 'white-space'.
Maybe that needs to change?
-Boris
On 12/14/11 7:12 PM, Ian Hickson wrote:
One could actually argue that the pages that exist that use _main and
_content actually work _better_ in current UAs with those values being
interpreted as browsing context names than they would if they were treated
as synonyms for _self or _top, because
On 12/10/11 2:55 AM, Robert Eisele wrote:
It's certainly also more difficult to implement but asking for every frame
to continue has also the disadvantage of beeing as slow as setting up a new
timeout for every frame. That's why setInterval surpass setTimeout's
performance (okay, at least it
On 12/10/11 3:11 AM, Boris Zbarsky wrote:
On 12/10/11 2:55 AM, Robert Eisele wrote:
It's certainly also more difficult to implement but asking for every
frame
to continue has also the disadvantage of beeing as slow as setting up
a new
timeout for every frame. That's why setInterval surpass
On 12/9/11 6:06 PM, Ryosuke Niwa wrote:
Given that both IE and WebKit have been disabling implicit form submission
for years when the button has display: none, I don't think we can change
our behavior here.
Why, given that neither Gecko nor Opera have, and as far as I know have
gotten
On 12/8/11 2:39 PM, Ashley Sheridan wrote:
I've been trying to optimise my site (as a test case) for mobile usage
and one area where I found issues was with the media queries used to
link CSS files. I noticed that despite eachlink tag including the
maximum and minimum screen widths (which is
On 12/8/11 3:56 PM, Tab Atkins Jr. wrote:
Remember that widths refer to the
browser window, not the monitor
For the 'width' and 'height' media queries, yes.
For the 'device-width' and 'device-height' media queries, no.
-Boris
On 12/8/11 5:10 PM, James Graham wrote:
It's not clear that device-width and device-height should be encouraged
since they don't tell you anything about how much content area is
*actually* visible to the user.
Well, sure. I'm not saying using them is a good idea, just that people
are doing
On 12/5/11 12:42 PM, Leif Halvard Silli wrote:
Last I checked, some of those locales defaulted to UTF-8. (And HTML5
defines it the same.) So how is that possible?
Because authors authoring pages that users of those locales tend to use
use UTF-8 more than anything else?
Don't users of those
On 12/5/11 6:14 PM, Leif Halvard Silli wrote:
It is more likely that there is another reason, IMHO: They may have
tried it, and found that it worked OK
Where by it you mean open a text editor, type some text, and save.
So they get whatever encoding their OS and editor defaults to.
And yes,
On 12/5/11 9:55 PM, Leif Halvard Silli wrote:
If that is all they tested, then I'd said they did not test enough.
That's normal for the web.
(For the record, reading a particular page in a language is a much
simpler task than reading the language; I can't read German, but I can
certainly
On 12/2/11 2:27 PM, Jonas Sicking wrote:
Gecko currently follows the spec, but is the only browser that does
so. We are not aware of any sites that break because of this.
To be more precise, the only issues we know of are
On 12/1/11 2:12 PM, Aryeh Gregor wrote:
On Fri, Nov 25, 2011 at 11:06 PM, Boris Zbarskybzbar...@mit.edu wrote:
It would break existing pages that use expandos on elements or documents via
barewords in on* attributes.
Isn't that the point of look at element's named properties (if it has
any)
On 11/29/11 10:27 PM, Yehuda Katz wrote:
Got it. Can we come up with a real-worldish example of someone using
expandos with barewords?
I'll look around. I recall seeing things like that somewhat recently,
but I might be misremembering
-Boris
On 11/26/11 1:03 AM, Yehuda Katz wrote:
Honestly, before this discussion, I would have been surprised to hear
that this works at all. It also seems to me that the group of people who
know how to add an expando and the group of people who use onxxx= is
pretty small to begin with.
This isn't
501 - 600 of 1308 matches
Mail list logo
