Re: [whatwg] Exposing EventTarget to JavaScript

2009-04-25 Thread Anne van Kesteren

On Sat, 25 Apr 2009 04:29:09 +0200, Ojan Vafai o...@chromium.org wrote:
I think this is sufficient. Although it is a bit unfortunate that  
dispatch order is undefined. It would be great if we could just agree  
that dispatch order is the order the handlers were registered in. I  
don't know the
technical details here though. Is there a reason that they can't  
dispatch in a guaranteed order?


Note that per DOM Level 3 Events (still a draft) the dispatch order is  
defined (register order). I believe that is also required for Web compat  
at this point, though I'm not a 100% sure.



--
Anne van Kesteren
http://annevankesteren.nl/


Re: [whatwg] Exposing EventTarget to JavaScript

2009-04-25 Thread Mike Wilson
On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 Alex Russell wrote:
 
  Something missing from this (and from Erik's original mail) is the
  ability to enumerate listeners.

 This has been brought up before.

Incidentally I just posted a message over at public-webapps about 
exactly this feature (I discovered this thread afterwards):
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0345.html

I'd be happy to continue this discussion here or there, whichever
is suitable for everybody else.

Best regards
Mike Wilson



Re: [whatwg] Please review use cases relating to embedding micro-data in text/html

2009-04-25 Thread Charles McCathieNevile

On Thu, 23 Apr 2009 22:46:09 +0200, Ian Hickson i...@hixie.ch wrote:

   USE CASE: Allow users to maintain bibliographies or otherwise keep  
  track of sources of quotes or references.

  SCENARIOS:

...

 * Chaals could improve the Opera intranet if he had a mechanism for
   identifying the original source of various parts of a page. (why?)


Because the page is put together by various different people (or  
processes), so knowing who is responsible for some bit that needs work is  
important in contacting the right person faster. (This isn't specific to  
Opera's intranet, of course. That happens to be the one I use most).



  REQUIREMENTS:
* Machine-readable bibliographic information shouldn't be on a  
   separate page than human-readable bibliographic information.

* The information should be convertible into a dedicated form (RDF,
   JSON, XML, BibTex) in a consistent manner, so that tools that use  
   this information separate from the pages on which it is found

   have a standard way of conveying the information.


cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com


Re: [whatwg] Please review use cases relating to embedding micro-data in text/html

2009-04-25 Thread Charles McCathieNevile

On Thu, 23 Apr 2009 22:46:09 +0200, Ian Hickson i...@hixie.ch wrote:

 * Shouldn't require the consumer to write XSLT or server-side code  
   to process the annotated data.


Does process here mean extract from the page, or something more?

cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com


Re: [whatwg] Please review use cases relating to embedding micro-data in text/html

2009-04-25 Thread Charles McCathieNevile

On Fri, 24 Apr 2009 05:53:09 +0200, Ian Hickson i...@hixie.ch wrote:


On Thu, 23 Apr 2009, Manu Sporny wrote:


I've looked over the list a couple of times and it's a good introduction
to the problem space.


It's not really intended to be an introduction, so much as a complete  
list of use cases that people want the spec to cover.

...

Oh. Then I think it is probably doomed to be incomplete - users not only  
do concrete things, but they do lots of different concrete things. This is  
possibly (probably?) a large enough set from which to derive general  
principles and clear goals.



From the point of view of the HTML5 effort, what is needed is use cases,
scenarios, and requirements, that don't in any way imply a particular
solution, as in the list I posted, so that solutions can be evaluated.

...

So how do the solutions get proposed, or do you already have a candidate  
list you have selected? What's the process here?


cheers

chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com


Re: [whatwg] Parsing RFC3339 constructs

2009-04-25 Thread Michael(tm) Smith
Ian Hickson i...@hixie.ch, 2009-04-25 05:35 +:

 On Fri, 2 Jan 2009, Asbjørn Ulsberg wrote:
  
  Reading the spec, I have to wonder: Does HTML5 need to specify as much 
  as it does inline? Can't more of it be referenced to ISO 8601 or even 
  better; RFC 3339? I really fancy how Atom (RFC 4287) has defined date 
  constructs: http://www.atompub.org/rfc4287.html#date.constructs Does 
  not RFC 3339 defined date and time in a satisfactory manner to use 
  directly in HTML5?
 
 The problem isn't so much the syntax definitions as the parsing 
 definitions. We need very specific parsing rules; it's not clear that 
 there is anything to refer to that does the job we need here.

It seems pretty clear that there isn't anything else to refer to
for the date/time parsing rules -- but to me at least, specifying
those rules seems orthogonal to specifying the date/time syntax,
and I would think the syntax could just be defined by making
reference to the productions[1] in RFC 3339 (instead of completely
redefining them), while stating any exceptions.

[1] http://tools.ietf.org/html/rfc3339#section-5.6

I think the exceptions might just amount to:

  - the literal letters T and Z must be uppercase

  - a year must be four or more digits, and must be greater that zero

-- 
Michael(tm) Smith
http://people.w3.org/mike/


Re: [whatwg] Parsing RFC3339 constructs

2009-04-25 Thread Ian Hickson
On Sat, 25 Apr 2009, Michael(tm) Smith wrote:
 
 It seems pretty clear that there isn't anything else to refer to
 for the date/time parsing rules -- but to me at least, specifying
 those rules seems orthogonal to specifying the date/time syntax,
 and I would think the syntax could just be defined by making
 reference to the productions[1] in RFC 3339 (instead of completely
 redefining them), while stating any exceptions.
 
 [1] http://tools.ietf.org/html/rfc3339#section-5.6
 
 I think the exceptions might just amount to:
 
   - the literal letters T and Z must be uppercase
 
   - a year must be four or more digits, and must be greater that zero

I don't understand what that would gain us.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'