Re: [whatwg] List of differences between whatwg and w3c spec?
And both do not display section headers in MSIE7, making it hard to guess what you are reading about. BTW, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, September 11, 2008 10:57 PM To: Aaron Swartz Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] List of differences between whatwg and w3c spec? On Thu, 11 Sep 2008, Aaron Swartz wrote: I notice there are specs for HTML5 dated today at: http://www.whatwg.org/specs/web-apps/current-work/ http://www.w3.org/html/wg/html5/ diff -u shows a lot of difference, but most are cosmetic. (I gather they're there because Hixie disagrees with some W3C pubrules but can't get them changed.) Is there any page that lists the substantive differences? Presumably the generation of the drafts is automated; is the source file for the drafts published? They're identical from the page of contents down to the bottom. (Literally, they're generated from the same file.) The only difference is in the header, the abstract, and the status of this document section. This is in fact stated in the status of this document section in both copies (they both say The two specifications are identical from the table of contents onwards). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] List of differences between whatwg and w3c spec?
On Thu, 11 Sep 2008 21:38:52 +0200, Aaron Swartz [EMAIL PROTECTED] wrote: I notice there are specs for HTML5 dated today at: http://www.whatwg.org/specs/web-apps/current-work/ http://www.w3.org/html/wg/html5/ diff -u shows a lot of difference, but most are cosmetic. (I gather they're there because Hixie disagrees with some W3C pubrules but can't get them changed.) Is there any page that lists the substantive differences? Presumably the generation of the drafts is automated; is the source file for the drafts published? The header is one of these (W3C, WHATWG): http://www.whatwg.org/specs/web-apps/current-work/header-w3c http://www.whatwg.org/specs/web-apps/current-work/header-whatwg This file is then appended to those headers: http://www.whatwg.org/specs/web-apps/current-work/source Then they are processed through a tool that is not accessible to the general public. (gsnedders is working on a tool that does the same, is completely open, and open source.) The output is then the two links you showed above. (Nobody mentioned the specifics so I thought I'd give another reply to this e-mail.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] HTML 5 will be ready in 2022
I know many web developers who get upset when they hear that HTML 5 is expected to become an official reccomendation in 2022. But as we all know, HTML 5 is already having real world effects and even being implemented in browsers. Is there some place that documents the parts of HTML 5 that are already up and running? Can I use canvas or video? In which browsers? What other tags can I use? What other fancy HTML 5 stuff can I do today in 2008? Shouldn't the whatwg wiki document that kind of stuff? Brenton Strine
Re: [whatwg] HTML 5 will be ready in 2022
On Fri, Sep 12, 2008 at 1:44 PM, Brenton Strine [EMAIL PROTECTED] wrote: Is there some place that documents the parts of HTML 5 that are already up and running? Can I use canvas or video? In which browsers? http://www.whatwg.org/specs/web-apps/current-work/#the-canvas What other tags can I use? What other fancy HTML 5 stuff can I do today in 2008? Shouldn't the whatwg wiki document that kind of stuff? There are a few tests and some implementations, Search the whatwg org site HTML 5 document. search term: Tests: Garrett Brenton Strine
Re: [whatwg] HTML 5 will be ready in 2022
On Fri, 12 Sep 2008, Brenton Strine wrote: I know many web developers who get upset when they hear that HTML 5 is expected to become an official reccomendation in 2022. Yeah, I'm always amused when people get upset over the idea that we might be able to get two completely bug-free implementations in only ten years. I mean, I know it's optimistic and unprecedented, but we have to try! ;-) Is there some place that documents the parts of HTML 5 that are already up and running? Can I use canvas or video? In which browsers? What other tags can I use? What other fancy HTML 5 stuff can I do today in 2008? Shouldn't the whatwg wiki document that kind of stuff? The spec itself has little annotation boxes on the left hand side that documents where implementations stand, sort-of. There's also this wiki page: http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers Both are somewhat out of date; if anyone wants to volunteer to maintain them, please feel free to do so. If you would like some advice on how to do so, you can either e-mail the list, or e-mail me directly, or ask on IRC (I'm Hixie on Freenode in #whatwg). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] workers
I've reviewed and digested the latest workers update
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015853.html).
I think we're converging :).
There are still a few improvements and simplifications I'd like to
see, however. With these (relatively minor) changes, I'd be really
happy with what we have.
* I think it was an interesting idea to have separate interfaces for
Dedicated and Shared workers, but in the end I don't think there's
enough difference between the two cases to justify it. I'd rather have
the total API surface be smaller, and generalize concepts as much as
possible. So...
- We should remove all the sendMessage/onmessage stuff from
DedicatedWorker, and just use the port convenience property.
- We should move onconnect() up into WorkerGlobalScope
* Similarly, I'd like to rename startConversation() to connect(). I
think this aligns nicely with the onconnect event (connect() should
also trigger a 'connect' event inside the worker).
* I think it would be a nice convenience to have an onmessage event
inside workers that receives all messages sent to any port in the
worker.
* We have discussed having onerror expose runtime script errors that
happened inside the worker. I don't think this makes sense for shared
workers, so I propose that it be spec'd to only expose load errors.
Script errors can still be exposed via a global onerror property
inside the worker, and they can still be reported to the error
console. I don't think having script errors that happened inside a
worker be exposed outside it is that useful (load errors are useful,
though).
* I think onclose makes sense on Port instead of on Worker. The other
side of a Port can close out from under you, even if it is a window.
* Ojan brought this up earlier, but I don't think there should be
anything added to the global scope of workers except a single 'self'
object, which implements all the APIs that are available there.
* I still don't buy the utility of passing around MessagePorts, so I
suggest we table that for v2. It can always be added back later.
Here is an IDL sketch of what the API would look like after these changes...
OUTSIDE
interface MessagePort {
EventListener onmessage;
EventListener onclose; // if the other side goes away
void sendMessage(in DOMString message);
}
interface Worker {
EventListener onload;
Port port; // convenience -- corresponds to the port available on
the created worker's WorkerContext object
Port connect(); // the method previously known as startConversation
}
interface DedicatedWorker : Worker {
void close();
}
INSIDE
// this is all exposed via self
interface WorkerContext {
EventListener onclose;
EventListener onmessage; // convenience -- receives all messages
sent to this worker, from any port
// fired when the worker is first created, and for each additional
new SharedWorker() or connect() call
EventListener onconnect;
readonly String name;
readonly MessagePort port; // convenience -- corresponds to the port
available on created Worker object
void close();
// + all the utils stuffs
}
CREATING WORKERS
var worker = new Worker(url);
var sharedWorker = new SharedWorker(name, url);
Let me know what you think!
- a
Re: [whatwg] HTML vs Plain Text in Notifications
Thanks guys for the comments! Language-tagging indeed would be hard. I've tried to change the portion of the spec to reflect this change, to see how it would change. Here is a copy of that part, modified: http://docs.google.com/View?docid=dhg4xn62_27c8qfqsgq I also have a small case study doc on calendar notifications to support the idea then they should be small HTML windows rather then small text ones : http://docs.google.com/Doc?id=dhg4xn62_28f8cwvzf8 Dmitry On Wed, Sep 10, 2008 at 11:48 PM, Julian Reschke [EMAIL PROTECTED]wrote: Dmitry Titov wrote: ... The text-based box has following problems: - Not enough formatting capabilities even for simple cases (calendar appointment and mail notification). - No mechanism to update content (as in upload progress indicator scenario) - No way to add interactive features (snooze on calendar appointment) ... - It doesn't allow language-tagging. BR, Julian
