Re: [whatwg] Validation
W liście Eduard Pascual z dnia poniedziałek 20 lipca 2009: Browsers are built incrementally. For example, IE10 is very likely to render properly any page that IE9 had rendered properly (plus some that IE9 couldn't handle). And IE9 will handle any page that IE8 handles (plus some that are too much for IE8), just like IE8 handles any page that IE7 (in addition to those that use CSS2 features not supported by IE7), and IE7 renders all the stuff that IE6 renders, and so on... That would be nice if it was true. Have you seen the list of pages compatible with IE6 but not IE8 (eg here: http://blogs.zdnet.com/microsoft/?p=2072tag=nl.e539)? -- Paweł Stradomski
Re: [whatwg] Asynchronous file upload
W liście Samuel Santos z dnia poniedziałek 11 maja 2009: I was asked by a client if it was possible to implement something similar to the asynchronous file upload used on gmail using only standard web technologies. Looking at the gmail source code I can see that they use some flash magic. And by reading the HTML5 spec I could not find a way to implement this feature. Submitting the form that contains file upload to a iframe. The question does not seem to belong to this list, does it? -- Paweł Stradomski
Re: [whatwg] WebWorkers vs. Threads
W liście Shannon z dnia środa 13 sierpnia 2008:
He wasn't against WebWorkers, he was, as you say, against full
threading (with all the mutexes and locks etc... exposed to the JS
author). I can't find the reference site but it doesn't really matter
except from the point of view that many people (including myself) aren't
convinced a full pthread -like API is the way to go either. I just don't
see why locking can't be transparently handled by the interpreter given
that the language only interacts with true memory registers indirectly.
Such implicit/transparent/automatic locking is in fact impossible. There are
always cases where the developer must manually control locking. The only
thread-safe way to lock implicitly would be to obtain a lock when handle to
shared object is retrieved and released when the reference is dropped/garbage
collected - locking on single read/write operation is not sufficient. In
order to avoid deadlocks it would be neccessary to lock access globally, for
all possible shared variables, which is not feasible. This is also the reason
setTimeout/setInterval callbacks are run in the main thread - and switching
to coroutines would not help here.
So, if we want the threads to be able to share variables directly, we need at
least some basic synchronization prymitives (critical sections, akin to
Java 'synchronized' blocks would be probably easiest).
In other news...
Despite the feedback I've been given I find the examples of potential
applications pretty unconvincing. Most involve creating workers to wait
on or manage events like downloads or DB access.
So an example from me. Suppose i need to download a few (20-30) JSON data sets
from some URL and then do some processing before displaying them.
Naïve pseudocode:
button.onclick = function() {
for (var i = 0; i 20; i++) {
synchronousRequest(i);
}
processData();
updateDOM();
return;
}
The problem is that with such a construct I'd block the only thread in JS, so
all other events will not be handled until the return statement.
So, with current code, I need to do:
button.onclick = function() {
var i = 0;
var handler = function(data) {
i = i+1;
if (i == 20) {
processData();
updateDom();
} else {
asyncRequest(i, handler);
}
}
asyncRequest(i, handler);
}
This way I do not block on network I/O, but still block on processData. With
real threads I would be able to perform the data processing and then notify
the main thread that data is processed and ready - so the main thread would
only updateDOM().
--
Paweł Stradomski
Re: [whatwg] Thoughts on HTML 5
W liście Ian Hickson z dnia wtorek 13 maja 2008: * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. Perhaps talk ? Short and simple, although not exactly equal in meaning to dialog. -- Paweł Stradomski
Re: [whatwg] Proposal for a link attribute to replace a href
W liście Shannon z dnia czwartek 28 lutego 2008: FAQ: * It adds no new functionality that can't already be achieved using the a element. Absolutely not true. A global attribute offers several features that a does not - most importantly nested links and the ability to hyperlink block and interactive elements without breaking validation. In my opinion this would be an important problem. How should nested links work? Suppose I put href=http://a; on p element and href=http://b; on a span inside that p. What should happen when the user clicks on that span? That's the reason why nested a's are forbidden by HTML 4 and XHTML 1. I'm not against href on every element, but then nesting elements with href attribute should be forbidden. Similarly href should be forbidden on interactive elements (buttons etc.), so making it global would be a problem. -- Paweł Stradomski
Re: [whatwg] Proposal for a link attribute to replace a href
W liście Robert O'Rourke z dnia czwartek 28 lutego 2008: Paweł Stradomski wrote: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. You're breaking element semantics here. inputs are for form input elements - text fields, checboxes etc. The above would make those inputs text fields, as you didn't spcify the type. Now how can an input be a link? It's supposed to accept user text, not to point to some other resource. Activating an input (by clicking on it etc.) should just make it start accepting typed text, not make the browser jump somewhere else. Presentation/style should follow the semantics, not the other way round. After more thinking I lean towards Krzysztof's point of view, href as global attribute is a bad idea. I guess it's in the FAQ for a purpose, so EOT for me (of course I'll accept and respond to off-list e-mails). -- Paweł Stradomski
