Re: [whatwg] Serializing HTML fragments (9.4)

[Ian Hickson]

On Tue, 28 Jul 2009, Simon Pieters wrote:
> > On Mon, 13 Jul 2009, Simon Pieters wrote:
> > > 
> > > I think the spec currently matches what IE does.
> > 
> > On Mon, 13 Jul 2009, Boris Zbarsky wrote:
> > > 
> > > Does IE even support adding a child element to a 

Re: [whatwg] Canvas context.drawImage clarification

[Ian Hickson]

On Mon, 27 Jul 2009, Gregg Tavares wrote:
> >
> > Could you explain what other interpretations of the following you think
> > are reasonable?:
> >
> > # The source rectangle is the rectangle whose corners are the four points
> > # (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh).
> > # [...]
> > # The destination rectangle is the rectangle whose corners are the four
> > # points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh).
> > #
> > # When drawImage() is invoked, the region of the image specified by the
> > # source rectangle must be painted on the region of the canvas specified
> > # by the destination rectangle [...]
> 
> It's ambiguous because images have a direction.  An image that starts at 
> 10 with a width of -5 is not the same as an image that starts at 6 with 
> a width of +5 any more than starting in SF and driving 5 miles south is 
> not the same as starting in Brisbane and driving 5 miles north.

Huh. I've never considered images as having a direction.

I've tried to add text to the spec to make sure that it's clear that no 
direction is implied here.


On Wed, 29 Jul 2009, Gregg Tavares wrote:
> 
> If it's so clear, why do you think 2 of the 4 browsers that implemented 
> it apparently got it wrong?

The browsers only paid passing attention to the spec when implementing it; 
the spec was being written at the same time.

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

Re: [whatwg] Installed Apps

[Ian Hickson]

On Mon, 27 Jul 2009, Michael Davidson wrote:
> 
> -- Slow startup: When a user navigates to mail.google.com, multiple 
> server requests are required to render the page. The Javascript is 
> cacheable, but personal data (e.g. the list of emails to show) is not. 
> New releases of Gmail that require JS downloads are even slower to load.

The offline app cache allows you to cache the JS and have new releases be 
downloaded in the background while the user uses the old version.

Client-side databases allow data to be cached client-side.

This leaves how to get new data to the client before the client has 
loaded.


> -- Native apps like Outlook can (and do) run background processes on the 
> user's machine to make sure that data is always up-to-date.

That would be one way to update the cached data before the client runs.


> -- Notifications: Likewise, Outlook can notify users (via a background 
> process) when new mail comes in even if it's not running.

HTML5 used to have a notifications API, but it was removed due to lack of 
implementor interest.


So there seem to be two problems here:

 - how to update a client-side database in the background when the app 
   isn't loaded, such that the data is up to date when the page is opened,

 - how to pop up notifications while the page is not loaded.

It seems like a direct solution to these would be to have a way for Web 
pages to expose a service that clients could subscribe to, which could 
send up database updates and notifications. That way, no script runs on 
the client, but the server can still update the client whenever needed.

For example, we could base this on the EventSource mechanism or the 
WebSocket mechanism, and define a protocol by which the server can at any 
time send up either:

   An INSERT, UPDATE, or DELETE SQL statement
   A string and a URL to show in a notification

The client would then open a connection to this service whenever it was 
open, and the server would update the database and send notifications as 
desired. The UA could then easily show in its UI that a remote server is 
updating data or showing a notification, and make it trivial for the user 
to unsubscribe from the relevant feaure.

This seems far less problematic than background processes, which have a 
host of problems:

 - they have unfortunate implications in multiprocess UAs (see below)

 - they are extremely susceptible to being co-opted for malware, e.g. 
   using CPU resources for computation without the user's knowledge

 - the permission UI is unproven

 - it doesn't really scale when hundreds of sites want to use the feature

 - it's not a good solution for performance problems (see anecdote about 
   Netscape 6 below)


On Mon, 27 Jul 2009, David Levin wrote:
>
> It sounds like most of the concerns are about the 2nd part of this 
> proposal: allowing a background page to continue running after the 
> visible page has been closed.
> 
> However, the first part sounds like it alone would be useful to web 
> applications like GMail:
> 
> The first, which should begenerally useful, is the ability to have a 
> hidden HTML/JS page running in the background that can access the DOM of 
> visible windows. This page should be accessible from windows that the 
> user navigates to. We call this background Javascript window a "shared 
> context" or a "background page". This will enable multiple instances of 
> a web app (e.g. tearoff windows in Gmail) to cleanly access the same 
> user state no matter which windows are open.

As far as I can tell, we can't ever have a scripting context that can 
access the DOMs of all pages in the same domain, since that would force 
those pages into the same process, which is an assumption that is already 
violated by IE (and, I believe, Chrome).

Also, since anything in the same browsing context typically has to be in 
the same process for sanity (accessing the Window object hierarchy is 
synchronous), and since many sites have s to common sites (e.g. ad 
networks) you very quickly end up dragging many sites into the same 
process if you go down this road. So I don't think that's really workable.


> + restrict things to the same security origin.
> 
> It sounds similar in concept to a share worker except that it runs in 
> the main thread and is more concerned with dom manipulation/state while 
> workers have typically been thought of as allowing background 
> processing.
> 
> It seems that the lifetime of this could be scoped, so that it dies when 
> it isn't referenced (in a similar way to how shared worker lifetime is 
> scoped).

It doesn't seem that having a lifetime-limited hidden window would address 
any of the problems listed at the top of this thread:

 - how to update a client-side database in the background when the app 
   isn't loaded, such that the data is up to date when the page is opened,

 - how to pop up notifications while the page is not loaded.


On Tue, 28 Jul 2009, Michael Nordman wrote:
> 
> What if a sharedCont

Re: [whatwg] More input element feedback

[Garrett Smith]

On Mon, Aug 3, 2009 at 12:09 AM, Ian Hickson wrote:
> On Thu, 23 Jul 2009, Kartikaya Gupta wrote:
>>
>> The description for what to do on setting valueAsNumber doesn't fully
>> cover error conditions. It's not clear to me, for instance, what's
>> supposed if you have an input type="date" or type="number" and try to
>> set valueAsNumber to NaN. The description there (for date) just says
>> "... passing it a Date object whose time value is the new value ..." but
>> doesn't say what to do if the Date object can't be created.
>

In what case could a Date object not be created?

> # Unless otherwise specified, if a DOM attribute that is a floating point
> # number type (float) is assigned an Infinity or Not-a-Number value, a
> # NOT_SUPPORTED_ERR exception must be raised.
>  -- http://www.whatwg.org/specs/web-apps/current-work/#dependencies
>

Why did you want valueAsNumber in the first place? Is

Why do you need valueAsDate?

Both of these seem unnecessary, out of place and overcomplicate INPUT.
It has come up recently[1] and although it does not need to be decided
now, I think the value and design of these features deserve further
investigation of before writing implementation code. Unit tests for
valueAs*, might likely reveal complexity and superfluity and little
added value of these will become more obvious.

[nip[

Regards,

Garrett

[1]http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021607.html

Re: [whatwg] Web Workers and postMessage(): Questions

[Robert O'Callahan]

On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler wrote:

> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any
> comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out
> there with comments?


I know very little about these issues. Jonas Sicking reads this list and
would know more.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Installed Apps

[Michael Nordman]

On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote:
> Michael Nordman wrote:
>>
>> On Mon, Aug 3, 2009 at 3:05 AM, Mike
>> Wilson wrote:
>> >
>> > Assuming this shared state doesn't require a full
>> > JavaScript global context, and could do with some
>> > root object or collection, would it be possible to
>> > extend Web Storage to support this task?
>>
>> A big part of what the Gmail team is interested in sharing is quite a
>> lot of javascript (loaded, parsed, jit'd... ready to call functions).
>> Along with that, the app can maintian shared state as well, but a big
>> part of this feature request is sharing the code itself. In the
>> absence of JS languange changes (analogous to DLLs or SOs for JS), I
>> think this does call for a full JS context.
>
> Right, with your scenario, that makes use of all these new
> features in the same app, that could make sense. Still, it
> would be interesting to look at how each feature could be
> implemented on its own, to potentially lessen the overhead
> for apps that only use a single feature.
>
> These are the individual features discussed so far, I think
> (did I miss any?):
> - "preload" JavaScript code
> - share "live" data between multiple pages
> - background process with direct access to UI
> - background process that outlives browser process
> - background process that auto-starts with operating system
> - access to notification area
>
> I can easily imagine separate use of the first two items,
> and I think it would be great to address the data handling
> in a coherent way with other state handling. It would be
> nice to have finer-grained control over data handling than
> having to "pop" a new window to use its global context.
>
> Btw, another reflection is that this mail thread is about
> introducing a client/server model in the browser. Some
> mentions of complex code in the background page, f ex building
> the HTML for the visible window, make me think of traditional
> server-centric webapps, but inside the browser. I've made
> the below table to illustrate this, and I mean to point out
> similarities between traditional server-centric and the new
> background_page-centric webapps, and between client-centric
> and visible-centric webapps. Maybe this can inspire some new
> thoughts.

Yes... client/server model in the browser... good observation... and a
good way to think about the direction I would like to see things go.
Incidentally, that line of thinking is my motivation for the
introduction of  script-generated responses in this (HTML5) system
design.

>
>             Remote          Background   Visible
>             server          page         page
>             --          --   ---
>
> Current webapp designs:
>
>  server-     state
>  centric     logic
>  (bugzilla)  gen HTML ->                  render
>
>  client-     state ->                     state
>  centric                                  logic
>  (gmail)                                  gen/render HTML
>
> New "background page" client-centric designs:
>
>  background- state ->        state
>  centric                     logic
>                             gen HTML ->  render
>
>  visible-    state ->        state ->     state
>  centric                     (logic)      logic
>                                          gen/render HTML
>
> mvh Mike
>
>

Re: [whatwg] Installed Apps

[Mike Wilson]

Michael Nordman wrote:
>
> On Mon, Aug 3, 2009 at 3:05 AM, Mike 
> Wilson wrote:
> >
> > Assuming this shared state doesn't require a full
> > JavaScript global context, and could do with some
> > root object or collection, would it be possible to
> > extend Web Storage to support this task?
> 
> A big part of what the Gmail team is interested in sharing is quite a
> lot of javascript (loaded, parsed, jit'd... ready to call functions).
> Along with that, the app can maintian shared state as well, but a big
> part of this feature request is sharing the code itself. In the
> absence of JS languange changes (analogous to DLLs or SOs for JS), I
> think this does call for a full JS context.

Right, with your scenario, that makes use of all these new
features in the same app, that could make sense. Still, it
would be interesting to look at how each feature could be
implemented on its own, to potentially lessen the overhead
for apps that only use a single feature.

These are the individual features discussed so far, I think
(did I miss any?):
- "preload" JavaScript code
- share "live" data between multiple pages
- background process with direct access to UI
- background process that outlives browser process
- background process that auto-starts with operating system
- access to notification area

I can easily imagine separate use of the first two items,
and I think it would be great to address the data handling 
in a coherent way with other state handling. It would be
nice to have finer-grained control over data handling than
having to "pop" a new window to use its global context.

Btw, another reflection is that this mail thread is about
introducing a client/server model in the browser. Some
mentions of complex code in the background page, f ex building 
the HTML for the visible window, make me think of traditional
server-centric webapps, but inside the browser. I've made
the below table to illustrate this, and I mean to point out
similarities between traditional server-centric and the new
background_page-centric webapps, and between client-centric
and visible-centric webapps. Maybe this can inspire some new
thoughts.

 Remote  Background   Visible
 server  page page
 --  --   ---

Current webapp designs:

 server- state
 centric logic
 (bugzilla)  gen HTML ->  render

 client- state -> state
 centric  logic
 (gmail)  gen/render HTML

New "background page" client-centric designs:

 background- state ->state
 centric logic
 gen HTML ->  render

 visible-state ->state -> state
 centric (logic)  logic
  gen/render HTML

mvh Mike

Re: [whatwg] More input element feedback

[Kartikaya Gupta]

On Mon, 3 Aug 2009 07:09:26 + (UTC), Ian Hickson  wrote:
> On Thu, 23 Jul 2009, Kartikaya Gupta wrote:
> > 
> > The description for what to do on setting valueAsNumber doesn't fully 
> > cover error conditions. It's not clear to me, for instance, what's 
> > supposed if you have an input type="date" or type="number" and try to 
> > set valueAsNumber to NaN. The description there (for date) just says 
> > "... passing it a Date object whose time value is the new value ..." but 
> > doesn't say what to do if the Date object can't be created.
> 
> # Unless otherwise specified, if a DOM attribute that is a floating point 
> # number type (float) is assigned an Infinity or Not-a-Number value, a 
> # NOT_SUPPORTED_ERR exception must be raised.
>  -- http://www.whatwg.org/specs/web-apps/current-work/#dependencies
> 

Ah, thanks.

> 
> > Also, editorial fix: in the same two paragraphs ("On getting" and "On 
> > setting" for valueAsNumber), the link to valueAsDate is wrong; it just 
> > links back to #dom-input-valueAsNumber instead of 
> > #dom-input-valueAsDate.
> 
> It appears I already fixed that already.
> 

It's still wrong for me. Search for the string "Otherwise, if the valueAsDate" 
in the spec. There should be two occurrences; in both of them the "valueAsDate" 
links to #dom-input-valueAsNumber.

kats

Re: [whatwg] Installed Apps

[Michael Nordman]

On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilson wrote:
> Drew Wilson wrote:
>>
>> SharedWorkers are overloaded to provide a way for
>> pages under the same domain to share state, but
>> this seems like an orthogonal goal to "parallel
>> execution" and I suspect that we may have ended
>> up with a cleaner solution had we decided to
>> address the "shared state" issue via a separate
>> mechanism.
>>
>> [...]
>>
>> 3) Sharing between pages requires going through
>> the database or shared worker - you can't just
>> party on a big shared datastructure.
>
> Assuming this shared state doesn't require a full
> JavaScript global context, and could do with some
> root object or collection, would it be possible to
> extend Web Storage to support this task?

A big part of what the Gmail team is interested in sharing is quite a
lot of javascript (loaded, parsed, jit'd... ready to call functions).
Along with that, the app can maintian shared state as well, but a big
part of this feature request is sharing the code itself. In the
absence of JS languange changes (analogous to DLLs or SOs for JS), I
think this does call for a full JS context.

Re: [whatwg] Web Workers and postMessage(): Questions

[Anne van Kesteren]

On Mon, 03 Aug 2009 19:47:14 +0200, Maciej Stachowiak  wrote:
> I'd prefer to stick with JSONic object graphs for now. Correctly
> cloning more complicated object structures is a fair bit more
> complicated, so I'd like to get solid interop on the basic cases
> first. Also, the idea is that postMessage() should be sending object
> structures that are essentially pure data. JSON seems to capture
> pretty well the idea of a pure data structure in JavaScript.

Well, it doesn't cover e.g. ImageData, which postMessage() allows for, and 
which seems useful to have. (No informed opinion on allowing cycles.)


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

Re: [whatwg] Web Workers and postMessage(): Questions

[Drew Wilson]

On Mon, Aug 3, 2009 at 10:34 AM, Daniel Gredler wrote:

>
>> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any
> comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out
> there with comments?
>

I've often had the same thought (that there's no reason we shouldn't handle
cycles when implementing structured clones).

That said, I'm compelled to point out that WebKit browsers only support
string messages currently (they don't yet implement the structured clone
part of the spec). And none of the currently shipping browsers support
MessagePorts or SharedWorkers (although WebKit browsers are getting these
soon). So given that there's a workaround for the lack of support for cycles
in structured clones (applications can do their own serialization) but
there's no app-level workaround for the lack of SharedWorkers, I'd rather
see vendors concentrate on implementing the current spec before adding
greater support for cloning message parameters.


>
> I agree that once you've made the decision to not clone functions, cloning
> the prototype chain becomes (nearly?) useless. However, I'd be interested to
> know the rationale behind this decision, since Web Workers appear to follow
> the same-origin policy (e.g. "If the origin of the resulting absolute URL is
> not the same as the origin of the script that invoked the constructor, then
> throw a security exception", etc). I assume there's a security concern
> lurking somewhere?
>

It's not clear to me how you'd clone the lexical scope of a function and
carry it over to the worker in a way that doesn't cause synchronization
issues.

Case in point:

var obj = {};
var foo = "abc";
obj.bar = function() { foo = "def"; }
sharedWorker.port.postMessage(obj);

Now, from shared worker scope, you have the ability to directly access the
variable "foo" from a different thread/process, which is not really
implementable.


-atw

Re: [whatwg] Web Workers and postMessage(): Questions

[Maciej Stachowiak]

On Aug 3, 2009, at 10:34 AM, Daniel Gredler wrote:



On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson  wrote:
On Wed, 22 Jul 2009, Daniel Gredler wrote:
>
> First, why does the structured clone algorithm used by  
postMessage() [1]

> throw an exception if it encounters cycles? It seems to me that the
> memory-based logic which is used to catch cycles could easily be
> modified to resolve them instead. The only possible reason I can  
think

> of is to match JSON semantics, and the only reason I can think of to
> want to match JSON semantics is to make implementers lives easier
> (witness Firefox 3.5, which just JSONifies objects passed to
> postMessage()). However, this is a huge limitation, and I'm not sure
> that the correct trade-off is to make implementers lives easier at  
the

> expense of making web designers lives harder.

Your guess is correct. I imagine we'll lift the restriction  
eventually; if

you want to make that happen quicker, then I encourage you to speak
directly to the browser vendors implementing this, and convince them  
it'd

be worth it. :-)


I know Anne VK (Opera) and ROC (Mozilla) appear to read this list...  
any comments, guys? Should I just file bugs? Any Safari / Chrome /  
IE guys out there with comments?


I'd prefer to stick with JSONic object graphs for now. Correctly  
cloning more complicated object structures is a fair bit more  
complicated, so I'd like to get solid interop on the basic cases  
first. Also, the idea is that postMessage() should be sending object  
structures that are essentially pure data. JSON seems to capture  
pretty well the idea of a pure data structure in JavaScript.


Regards,
Maciej

Re: [whatwg] Web Workers and postMessage(): Questions

[Daniel Gredler]

On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson  wrote:

> On Wed, 22 Jul 2009, Daniel Gredler wrote:
> >
> > First, why does the structured clone algorithm used by postMessage() [1]
> > throw an exception if it encounters cycles? It seems to me that the
> > memory-based logic which is used to catch cycles could easily be
> > modified to resolve them instead. The only possible reason I can think
> > of is to match JSON semantics, and the only reason I can think of to
> > want to match JSON semantics is to make implementers lives easier
> > (witness Firefox 3.5, which just JSONifies objects passed to
> > postMessage()). However, this is a huge limitation, and I'm not sure
> > that the correct trade-off is to make implementers lives easier at the
> > expense of making web designers lives harder.
>
> Your guess is correct. I imagine we'll lift the restriction eventually; if
> you want to make that happen quicker, then I encourage you to speak
> directly to the browser vendors implementing this, and convince them it'd
> be worth it. :-)
>


I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any
comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out
there with comments?



> > Second, why not walk the prototype chain? Similar rules regarding host
> > objects and regular objects could apply to prototypes. You would want to
> > make sure that multiple references to the same prototype instance result
> > in references to a single prototype clone in the cloned object graph.
> > Again, though, it doesn't sound too hard (though I might just be
> > optimistic). Why not make web designers' lives easier?
>
> We're definitely never going to copy function code over, so it's not clear
> that the prototype chain would be that useful. Could you elaborate on your
> use case?
>


I agree that once you've made the decision to not clone functions, cloning
the prototype chain becomes (nearly?) useless. However, I'd be interested to
know the rationale behind this decision, since Web Workers appear to follow
the same-origin policy (e.g. "If the origin of the resulting absolute URL is
not the same as the origin of the script that invoked the constructor, then
throw a security exception", etc). I assume there's a security concern
lurking somewhere?

My specific use case spits out a tree, each node having a reference to its
children and its parent (hence the issue with circular references). Each
node also has a "name" attribute and a function (in the prototype) used to
retrieve the node's "path" (based on its name and its ancestors names) -- I
don't want to precalculate each node's path and keep it in memory, given
that there are tens of thousands of nodes (or more).


> Overall, it just appears that the current web worker spec ignores the
> > class of computational problems involving results which need to be
> > modeled in a complex way.
>
> That's probably a fair criticism, yes.
>


Then I'll see if I can't raise some awareness amongst implementers ;-)


-- 
Daniel Gredler
http://daniel.gredler.net/

Re: [whatwg] the cite element

[Jeremy Keith]

Hixie asked:
What is the problem solved by allowing names to be marked up in the  
same manner as  titles?


They are both entities being referenced (cited). It seems arbitrary to  
me to forbid referencing names with the  element. HTML 4 already  
allows it, authors would have to change their existing behaviour  
(something to be avoided wherever possible) and when the meanings of  
other existing elements—, , —are being *expanded*, I  
can't follow the logic in *restricting* the meaning of an element  
already being used broadly.



The problem solved by allowing titles specifically to be marked up
is that titles are usually typographically offset from the surrounding
text in a distinctive fashion. This doesn't apply to names.


That's what CSS is for.

I haven't changed the spec. I continue to hold the position that  
covering
titles of works is more useful than covering titles of works and  
names of
people, and more useful than covering only names of people or works  
that

are explicitly cited.


Okay, but it won't make any difference to authors like myself who will  
continue to use  to mark up names.


We can do this either by applying a Kenobian interpretation of the  
spec (e.g. a person is the work of their parents/peers/society and a  
person's name is therefore a "title of work") or we can do it more  
flagrantly by simply disagreeing with the spec—a precedent for this  
would be the  element in HTML4 where the example in the spec  
showed it being used for dialogue; authors (rightly) ignored the spec.


The meaning of the  element is  a classic example of a "language  
feature" rather than a "platform feature".  and  are  
examples of platform features i.e. features that require work by  
browser makers to implement. As you have correctly pointed out many  
times, if browser makers refuse to implement a platform feature,  
there's no point having it in the spec; the spec would be fiction.


When it comes to language features, the browser makers don't have to  
do much—just make sure the element shows up in the DOM. However, if  
authors refuse to implement a language feature as described in the  
spec, then the spec becomes fiction.


Platform features need buy-in from browser makers.

Language features need buy-in from authors.

Authors use the  element to mark up names. It is often the most  
semantically appropriate element for marking up a name (and then in  
itself is a good enough reason to use it—default browser styling  
doesn't come into it). I don't think it makes sense to ignore the  
existing behaviour of authors.


Authors such as myself will continue to use the  element to mark  
up names; our markup will still be conforming; validators won't flag  
up our choices as errors.


Like I said, you can keep the spec as it is if you want but know that  
that particular part of the spec (detailing usage of the   
element) will be a work of fiction.


Eric Vorhes wrote:

This isn't about including names of
people; that is just the most obvious non-title form of citation. This
is about properly understanding what a citation can be and writing the
specification for the  element to account for those
possibilities. Citations are references to works, people, etc. By
limiting it to "title of work" you are actually limiting it to a
subset of a subset, as many objects worth citing don't have
conventional titles.


I agree. I don't think the spec should be micro-managing semantic  
decisions better left to authors.


Let me explain with another example I used on IRC earlier...

Suppose you're marking up a . What element do you use to contain  
your form field and your ? Some authors use s. Some  
authors use s. Some authors use s. We could argue (we have  
argued) about which is the most appropriate but in the end, it's the  
author's choice.


Choosing an element to mark up a piece of content isn't always a  
Boolean proposition. Sometimes there is an obvious "correct" choice  
(paragraphs of text should probably be marked up with the  element)  
but more often than not, different authors will make different  
choices. And that's okay. Unless it's a flagrant disregard for the  
semantic meaning of the element (e.g. using the  element for  
non-tabular content), authors should be allowed to choose what *they*  
feel is the most semantically appropriate element.


I choose to mark up names with the  element. Other authors  
choose not to. We will all continue to exercise our personal choices  
even if the HTML5 spec tries to restrict the meaning of the element.


Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/

Re: [whatwg] HTML5: has input device: use motion detection been included?

[Charles McCathieNevile]

On Mon, 03 Aug 2009 12:25:58 -0400, Marcin Hanclik  
 wrote:



Hi Chaals, Jonathan,

Input devices are currently not in the DAP charter.
http://www.w3.org/2009/05/DeviceAPICharter.html


They are not in the list of deliverables (which is a high-priority set of  
things that people are already working on). They are, as I understand it,  
well within the scope of the group. So it would take a draft, an editor,  
and presumably use cases and interest from implementors, before the group  
might add them to the deliverables.


I am not sure whether the charter is to change soon, although it should  
be possible, I think.


Yes, I think that we agree on the way such work would happen, and that it  
is certainly possible in the scope of that group.


cheers

Chaals


Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: whatwg-boun...@lists.whatwg.org  
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Charles  
McCathieNevile

Sent: Monday, August 03, 2009 6:05 PM
To: ~:'' ありがとうございました; wha...@whatwg.org; public-weba...@w3.org
Cc: Doug Schepers; i...@hixie.ch
Subject: Re: [whatwg] HTML5: has input device: use motion detection been  
included?


Hi Jonathon,

On Mon, 03 Aug 2009 10:27:02 -0400, ~:'' ありがとうございました
 wrote:


HTML5: has input device: use motion detection been included?

many laptops, mobiles and other devices come with cameras at this time.

motion detection offers some potential accessibility benefits, and the
opportunity to appear and play in game spaces.


This is among the things that the Device API group is expected to cover
with new APIs for such capabilities.

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



Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is  
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying  
or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly  
by responding to this e-mail. Thank you.



--
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] AppCache can't serve different contents for different users at the same URL

[Aryeh Gregor]

On Mon, Aug 3, 2009 at 4:20 AM, Mike Wilson wrote:
> A problem with this is that it will treat all cookies for
> the page in one lump. In 1997 there was a proposal for
> identifying individual cookies, f ex:
>  Vary: Cookie.USERID
> or
>  Vary-Cookie: USERID
> but it seems it was dropped. Anyway, maybe it is
> interesting to reread the discussion to find correlations
> to current AppCache topics:
> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0334.html

FWIW, Wikimedia uses a non-standard X-Vary-Options header for exactly
this purpose, which they've patched Squid to recognize.  Of course,
since it's non-standard it only benefits their own reverse proxies,
not any regular proxies that might be used elsewhere (unless those
happen to be running the patched Squid for some reason).  Varying on
Accept-Encoding is very useful for cache hit rate as well.

Reference: http://www.mail-archive.com/squid-...@squid-cache.org/msg07066.html

Re: [whatwg] HTML5: has input device: use motion detection been included?

[Marcin Hanclik]

Hi Chaals, Jonathan,

Input devices are currently not in the DAP charter.
http://www.w3.org/2009/05/DeviceAPICharter.html
I am not sure whether the charter is to change soon, although it should be 
possible, I think.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Charles McCathieNevile
Sent: Monday, August 03, 2009 6:05 PM
To: ~:'' ありがとうございました; wha...@whatwg.org; public-weba...@w3.org
Cc: Doug Schepers; i...@hixie.ch
Subject: Re: [whatwg] HTML5: has input device: use motion detection been 
included?

Hi Jonathon,

On Mon, 03 Aug 2009 10:27:02 -0400, ~:'' ありがとうございました
 wrote:

> HTML5: has input device: use motion detection been included?
>
> many laptops, mobiles and other devices come with cameras at this time.
>
> motion detection offers some potential accessibility benefits, and the
> opportunity to appear and play in game spaces.

This is among the things that the Device API group is expected to cover
with new APIs for such capabilities.

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



Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is 
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or 
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by 
responding to this e-mail. Thank you.

Re: [whatwg] HTML5: has input device: use motion detection been included?

[Charles McCathieNevile]

Hi Jonathon,

On Mon, 03 Aug 2009 10:27:02 -0400, ~:'' ありがとうございました  
 wrote:



HTML5: has input device: use motion detection been included?

many laptops, mobiles and other devices come with cameras at this time.

motion detection offers some potential accessibility benefits, and the
opportunity to appear and play in game spaces.


This is among the things that the Device API group is expected to cover  
with new APIs for such capabilities.


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

[whatwg] New HTML5 spec-editing tools released

[Manu Sporny]

The newest version of the microsection spec-editing tools have been made
available:

http://wiki.github.com/html5/spec

These tools, microsplit and microjoin, are capable of:

* Taking Ian's latest HTML5 spec as an input document and splitting it
  up into microsections.
* Re-mixing, removing and adding microsections specified from another
  source (for example: RDFa, John Foliot's summary suggestions, etc.)
* Producing one or more output specifications (such as Ian's HTML5 spec,
  HTML5-rdfa, HTML5-johnfoliot-summary, etc.)

This process:

* Does not impact Ian's current editing workflow.
* Empowers additional editors to modify the HTML5 specification without
  stomping on each other's changes.
* Enables alternate HTML5 specifications to be authored while
  automatically updating the alternates with Ian's spec changes.
* Is currently used to produce the HTML5+RDFa specification.
* Provides a mechanism that can be used to generate specification
  language that is specific, and that can be used to form consensus
  around the HTML5 specification at the W3C.
* Enables thoughtful and well-mannered dissent.

There is even a pretty picture that describes the workflow:

http://wiki.github.com/html5/spec

Anyone is free to clone the repository, use the tools, generate
remixed/updated/altered specifications and propose them as alternatives.

I am seeking thoughts and suggestions about these tools - how they might
help or hinder, as well as improvements that should be considered.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Re: [whatwg] the cite element

[Erik Vorhes]

On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson  wrote:
>
> >
> > See ; note near the top of the source:
> > ...
>
> My statement stands, on the aggregate:
>
> On Mon, 27 Jul 2009, Philip Taylor wrote:
> >
> > See http://philip.html5.org/data/cite-attribute-values.txt for some
> > data. (Looks like non-URI values are quite rare.)
>

I agree that @cite is rarely used as anything other than a URI; I was
attempting to demonstrate that even very recent uses of HTML don't
necessarily "get" that it is for URIs (the site I referenced launched
last month, as I recall).

>
> While we're at it, Philip had other data:
>
> > Also maybe relevant: see http://philip.html5.org/data/cite.txt for some
> > older data about . (Looks like non-title uses are very common.)
>
> This seems to support my point that  is used for a whole variety of
> purposes, like , , , HTML4's , and HTML5's . Very
> few, actually much fewer than I had remembered from my last look at the
> data, are names of people, citations or otherwise.
>

I actually took this information the other way, that there are indeed
other uses for  out there beyond titles.

>
> On Mon, 27 Jul 2009, Erik Vorhes wrote:
> >
> > > A new element wouldn't work in legacy UAs, so it wouldn't be as
> > > compelling a solution. Also,  is already being used for this
> > > purpose.
> >
> > My preference would be for  to retain the flexibility it has in
> > pre-HTML5 specifications, which would include referencing titles.
>
> The flexibility doesn't seem as useful as limiting it to titles. What is
> the problem solved by allowing names to be marked up in the same manner as
> titles? The problem solved by allowing titles specifically to be marked up
> is that titles are usually typographically offset from the surrounding
> text in a distinctive fashion. This doesn't apply to names. Reusing the
> same element for both encourages authors to use  for both which
> makes it harder for them to get the right typographic effect, leading to a
> lower quality of typography overall. I think this is a bad thing.
>

This is not just about names. It allows other (non-title) text to be
identified as a citation. If  is identified as "title of work,"
you can't cite many major orchestral arrangements at all, nor can you
cite legal decisions. Unless by "title of work" you mean "standard
citation for an item, usually its title"; but then  really means
what it is defined as in the HTML 4.01 specification.

>
> > If backwards compatibility is that big a concern, why does HTML5 use
> >  outside of  elements?
>
> There were no existing elements that could be reused for many of the new
> semantics. When there were, we used them (e.g. , , , ,
> , ).
>

I agree that there aren't always existing elements for the new
semantics included in HTML5, but I don't believe that backwards
compatibility is as big a concern as you claim it is. HTML5's re-use
of , for example, is completely broken in every extant
browser. (See 
for evidence).

Besides, there's already , which could be used to identify "title
text" or something like that.


> > > What is the pressing need for an element for citations, which would
> > > require that we overload  with two uses?
> >
> > A title can be a citation, but not all citations are titles. What's the
> > pressing need for limiting  only to titles?
>
> As described above, the need to have an element for titles is that there
> are typographic conventions that apply to titles. What is the pressing
> need for an element for citations, which would require that we overload
>  with two uses?
>

As I have said previously, there aren't consistent typographic
conventions that apply to titles. The "pressing need" is that 
is already used to define citations. There's no reason to limit it to
a subset of citation (more below).

>
> But why does that have value? How would you use this information?
>

To collect citation information. I don't see how that as any less
value that collecting titles of works, especially since not all works
have titles or means of reference that would constitute a conventional
"title."

>
> > >> > Note that HTML5 now has a more detailed way of marking up
> > >> > citations, using the Bibtex vocabulary. I think this removes the
> > >> > need for using the  element in the manner you describe.
> > >>
> > >> Since this is supposed to be the case, why shouldn't HTML5 just ditch
> > >>  altogether? (Aside from "backward compatibility," which is
> > >> beside the point of the question.)
> > >
> > > Backwards compatibility (with legacy documents, which uses it to mean
> > > "title of work") is the main reason.
> >
> > I'd beg to differ, regarding "legacy documents." See, for example the
> > automated citation generation at Wikipedia:
> > http://en.wikipedia.org/wiki/Wikipedia:Citation_templates
>
> What specifically am I looking for here? This doesn't seem to have any
> relevance to HTML.
>

Wikipedia autom

[whatwg] HTML5: has input device: use motion detection been included?

[~ : '' ありがとうございました]

HTML5: has input device: use motion detection been included?

many laptops, mobiles and other devices come with cameras at this time.

motion detection offers some potential accessibility benefits, and the  
opportunity to appear and play in game spaces.


I raised this issue before on this list , but received no response:
http://lists.w3.org/Archives/Public/public-webapi/2007Dec/0056.html

Apple Bug ID 5653030: iSight internal: motion detection
'Thank you for the suggestion. Will explore opportunities."
email.

also raised recently with Ron Festejo, game developer, eyetoy, Sony.

more background detail on the webkit bug:
https://bugs.webkit.org/show_bug.cgi?id=16474

regards

~:"

Eric Carlson, whk prompted me to raise this once again.

Re: [whatwg] Accessibility for Drag and Drop

[Aron Spohr]

Hi Ian,

firstly thanks for your comments.

--- Ian Hickson  wrote on Tuesday, 28. July 2009: 
> Whether draggable elements can be focused or not is up to
> the user agent. 
> It's much like links -- in some browsers, whether they are
> focusable or 
> not depends on the operating system accessibility
> preferences.

I agree. It's the same case here. Just like with "'a' elements that have an 
href attribute" we should also add "elements that have a draggable attribute 
set to true" to the list of elements that "should be made focusable by the user 
agent" at the bottom of section 7.5.1 of the spec. 

Btw. there is no information on what criteria the qualification is made for the 
elements in that "should" list in the spec. Maybe that should be added as well.

> The user agent can actually find where drops can occur by
> just acting as 
> if the user had tried to drop everywhere. I'm not really
> sure how we could 
> make an attribute work for this, since the model allows any
> element to be 
> a drop target already.

Fair enough. I thought it might come in handy some day to identify both 
draggable elements as well as elements that can "receive" drops without the use 
of scripting. E.g. in a parser or for search spiders to creater indexes for 
that faster...

Aron

Re: [whatwg] the cite element

[Ian Hickson]

On Mon, 27 Jul 2009, Erik Vorhes wrote:
> On Sun, Jul 19, 2009 at 4:58 AM, Ian Hickson wrote:
> >>
> >> If  is exclusively for titles, it shouldn't be called .
> >
> > Sure, but we're about 15 years too late for that.
> 
> Well, no: the as far as I have been able to determine, every HTML 
> specification (before HTML5) did not limit this element to titles.

I meant that we're too late to rename the element.


> > In practice, people haven't been confused between these two attributes 
> > as far as we can tell. People who use  seem to use it for 
> > titles, and people who use cite="" seem to use it for URLs. (The 
> > latter is rare.)
> 
> See ; note near the top of the source: 
> ...

My statement stands, on the aggregate:

On Mon, 27 Jul 2009, Philip Taylor wrote:
> 
> See http://philip.html5.org/data/cite-attribute-values.txt for some 
> data. (Looks like non-URI values are quite rare.)

While we're at it, Philip had other data:

> Also maybe relevant: see http://philip.html5.org/data/cite.txt for some 
> older data about . (Looks like non-title uses are very common.)

This seems to support my point that  is used for a whole variety of 
purposes, like , , , HTML4's , and HTML5's . Very 
few, actually much fewer than I had remembered from my last look at the 
data, are names of people, citations or otherwise.


On Mon, 27 Jul 2009, Erik Vorhes wrote:
>
> > A new element wouldn't work in legacy UAs, so it wouldn't be as 
> > compelling a solution. Also,  is already being used for this 
> > purpose.
> 
> My preference would be for  to retain the flexibility it has in 
> pre-HTML5 specifications, which would include referencing titles.

The flexibility doesn't seem as useful as limiting it to titles. What is 
the problem solved by allowing names to be marked up in the same manner as 
titles? The problem solved by allowing titles specifically to be marked up 
is that titles are usually typographically offset from the surrounding 
text in a distinctive fashion. This doesn't apply to names. Reusing the 
same element for both encourages authors to use  for both which 
makes it harder for them to get the right typographic effect, leading to a 
lower quality of typography overall. I think this is a bad thing.


> If backwards compatibility is that big a concern, why does HTML5 use 
>  outside of  elements?

Because inventing a new element in that particular case turns out to be 
non-trivial (pretty much every synonym for "caption" is already used by 
some HTML element), and we can afford to wait to get  done.


> And if the definition of new elements is such a concern, why introduce
> *any* new elements? (Please forgive the snark.)

There were no existing elements that could be reused for many of the new 
semantics. When there were, we used them (e.g. , , , , 
, ).


> > What is the pressing need for an element for citations, which would 
> > require that we overload  with two uses?
> 
> A title can be a citation, but not all citations are titles. What's the 
> pressing need for limiting  only to titles?

As described above, the need to have an element for titles is that there 
are typographic conventions that apply to titles. What is the pressing 
need for an element for citations, which would require that we overload 
 with two uses?


> >> I understand HTML5's attempts to provide semantic value to such 
> >> elements as , , and . To at the same time remove 
> >> semantic value at the same time is completely asinine.
> >
> > If 's original meaning has value, that is true; what is its 
> > value?
> 
> I would assume that this would be obvious.  both denotes and 
> connotes "citation."

But why does that have value? How would you use this information?


> >> > Note that HTML5 now has a more detailed way of marking up 
> >> > citations, using the Bibtex vocabulary. I think this removes the 
> >> > need for using the  element in the manner you describe.
> >>
> >> Since this is supposed to be the case, why shouldn't HTML5 just ditch 
> >>  altogether? (Aside from "backward compatibility," which is 
> >> beside the point of the question.)
> >
> > Backwards compatibility (with legacy documents, which uses it to mean 
> > "title of work") is the main reason.
> 
> I'd beg to differ, regarding "legacy documents." See, for example the 
> automated citation generation at Wikipedia: 
> http://en.wikipedia.org/wiki/Wikipedia:Citation_templates

What specifically am I looking for here? This doesn't seem to have any 
relevance to HTML.


> In addition, the comments at zeldman.com use  to reference authors 
> of comments. While that specific example is younger than HTML5, this is 
> merely an example of a relatively common use-case for  that does 
> not use it to signify "title of work."

As I said, the most common use of  is to mark up italics. I agree 
entirely that it's misused.


> >> There is no reason at all why it can't be defined as "citing whom".
> >
> > The main reason would be that there doesn

Re: [whatwg] Microdata and Linked Data

[Martin McEvoy]

Hello Ian

Ian Hickson wrote:
I'm definitely against any in-page indirection mechanism, because we have 
seen with XML Namespaces (and with RDFa) that prefixes are simply a huge 
source of problems.
  
They are indeed, XML namespaces fixed one problem calling different 
things by the same name  but  they created another problem of calling 
the same thing by different names, Prefixes are not themselves bad, 
misunderstood  or any kind of indirection mechanism, they are just short 
hand urls, they are actually quite intuitive if used correctly.  RDFa Is 
currently trying to solve its problems with xmlns, is just a minor 
design flaw, xmlns is used for structure not content and they realize 
that issue.


Best wishes

--
Martin McEvoy
http://weborganics.co.uk/

Re: [whatwg] "Images whose contents are not known" "In such cases, the alt attribute's value may be omitted..."

[Ian Hickson]

On Fri, 24 Jul 2009, Tab Atkins Jr. wrote:
> On Fri, Jul 24, 2009 at 12:07 PM,  wrote:
> > I object.
> 
> For reference, Darxus is referring to
> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#unknown-images.
> 
> Now, care to clarify?  A two-word objection is essentially useless for
> anyone, and serves only to spam the mailing list.
> 
> What exactly do you have a problem with?  Examples, clarifications,
> suggestions, etc?

As Tab says, more information is going to be needed before I can 
adequately respond to this feedback.

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

Re: [whatwg] Close events and workers

[Ian Hickson]

On Fri, 24 Jul 2009, Drew Wilson wrote:
>
> I noticed that Section 4.6 of the Web Workers spec still refers to the
> "close event" which has been removed:
> 
> If the script gets aborted by the "kill a
> worker<#122aa363b1e6e893_kill-a-worker>"
> algorithm, then that same algorithm will cause there to only be a singletask 
> in
> the event loop at the next step, namely the task for the close event.
> The "terminate
> a worker <#122aa363b1e6e893_terminate-a-worker>" algorithm removes all the
> events.
> 
> Seems like we should update this language.

Good catch, thanks. I removed the paragraph.

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

Re: [whatwg] Section 3.3.3.2 Attribute value normalization and title attributes

[Ian Hickson]

On Fri, 24 Jul 2009, Elliotte Rusty Harold wrote:
>
> A technical point that may perhaps have already been considered. Section 
> 3.3.3.2 states "If the title attribute's value contains U+000A LINE FEED 
> (LF) characters, the content is split into multiple lines. Each U+000A 
> LINE FEED (LF) character represents a line break." However this is 
> incompatible with XML and the XHTML serialization. In XML as specified 
> in http://www.w3.org/TR/REC-xml/#AVNormalize

In XML, you have to use a character reference, but it's still possible (as 
far as I can tell) to include a newline.


> I'm not sure what should be done about this. This is one of the weirder 
> and more error-prone parts of XML. However, since HTML 5 is suspicious 
> of linefeeds in title attributes anyway, we could either forbid them or 
> adopt the XML interpretation.

I don't really see why the minor difficulties in the XML syntax would 
affect the semantics here. Could you elaborate on your concern? What 
problem would changing this solve?


> I first noticed this in the description of the title attribute, but the 
> issue could be deeper. In particular, in the HTML 5 requirement that "If 
> a reflecting DOM attribute is a DOMString but doesn't fall into any of 
> the above categories, then the getting and setting must be done in a 
> transparent, case-preserving manner." it's not clear what "transparent" 
> really means here, and whether it's compatible with XML's attribute 
> value normalization.

Transparent is used here in its normal computer science sense, meaning 
that no modifications are made to the value. In the case of the DOM APIs, 
this is independent of the XML representation, so I don't think there's a 
problem there.

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

Re: [whatwg] Type of PropertyNodeList.contents

[Ian Hickson]

On Fri, 24 Jul 2009, Andrew Oakley wrote:
>
> PropertyNodeList.contents seems to be defined differently in the IDL and
> the text related to it.
> 
> The IDL says:
> > typedef sequence PropertyValueArray;
> > 
> > interface PropertyNodeList : NodeList {
> >   attribute PropertyValueArray contents;
> > };
> 
> The description says:
> > The contents DOM attribute on the PropertyNodeList object, on
> > getting, must return a newly constructed DOMStringArray whose values
> > are the values obtained from the content DOM property of each of the
> > elements represented by the object, in tree order.
> 
> DOMStringArray doesn't appear to be defined anywhere, however DOM 3 Core
> has a DOMStringList which seems to have this purpose.
> 
> HTMLPropertyCollection.names returns a DOMStringList, so I think we
> should be consistent and also return a DOMStringList for
> PropertyNodeList.contents.

Fixed. It can't be a DOMStringList (nor a DOMStringArray, whatever that 
was supposed to be), because some of the values are going to themselves be 
items, and not strings.

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

Re: [whatwg] Microdata and Linked Data

[Ian Hickson]

(I trimmed public-html from the CC list to avoid cross-posting, and 
because the whatwg list has had most of the traffic on this topic so far; 
please feel free to forward this to public-html if you would rather 
discuss that there instead.)

On Fri, 24 Jul 2009, Peter Mika wrote:
> 
> The use of a URI as the value of the id attribute. It seems to me there 
> is actually nothing in the spec that would stop this:
> 
> "Identifiers are opaque strings. Particular meanings should not be derived
> from the value of the id  attribute."
> 
> This is great because in principle I could do something like:
> 
> http://john.example.com#hedral"; item="org.example.animal.cat
> com.example.feline">
> Hedral
> 
> 
> I assume you can achieve something similar with the "about" property but that
> would require me to write:
> 
> 
> Hedral
> http://john.example.com#hedral"/>
> 
> 
> This is longer by itself, and if I want an internal identifier as well, than I
> have to write:
> 
> 
> Hedral
> http://john.example.com#hedral"/>
> 

In practice, all the use cases that were brought up that needed to 
identify the item were cases where there was a URL already in the page, 
e.g. in a link or an  or a  element, such that it actually 
ends up better if we use itemprop=about rather than having a dedicated 
attribute (like id="" or about="") for identifying types.

Are there use cases where this is not the case? For example, when would 
you need to have an internal identifier?


> The other area that could be possibly improved is the connection of type 
> identifiers with ontologies on the web. I would actually like the notion 
> of reverse domain names if
> 
> -- there would be an explicit agreement that they are of the form
> xxx.yyy.zzz.classname
> -- there would be a registry for mappings from xxx.yyy.zzz to URIs.
> 
> For example, org.foaf-project.Person could be linked to
> http://xmlns.com/foaf/0.1/Person by having the mapping from org.foaf-project
> to http://xmlns.com/foaf/0.1/.
> 
> It wouldn't be perfect, the FOAF ontology as you see is not at 
> org.foaf-project but at com.xmlns. However, it would be a step in the 
> right direction.

What problem is this solving?


> I would consider adding the sameAs property as part of the standard 
> vocabulary. This is a term from the OWL vocabulary that is widely used 
> in the Linked Data world for connecting entities that are deemed to be 
> equivalent. Alternatively, we could add the entire RDFS and OWL 
> vocabulary to the spec.

Could you elaborate on this? What are the use cases that this is intended 
to address? What do you mean by "adding the sameAs property"?


> I don't expect that writing full URIs for property names will be 
> appealing to users, but of course I'm not a big fan either of defining 
> prefixes individually as done in RDFa with the CURIE mechanism. Still, 
> prefixes would be useful, e.g. foaf:Person is much shorter to write than 
> com.foaf-project.Person and also easier to remember. So would there be a 
> way to reintroduce the notion of prefixes, with possibly pointing to a 
> registry that defines the mapping from prefixes to namespaces?
> 
> http://www.w3c.org/registry/";
> item="animal:cat">
> Hedral
> 
> 
> Here the registry would define a number of prefixes. However, the 
> mechanism would be open in that other organizations or even individuals 
> could maintain registries.

I'm definitely against any in-page indirection mechanism, because we have 
seen with XML Namespaces (and with RDFa) that prefixes are simply a huge 
source of problems.

However, there actually already is a registry for registering strings that 
start with a keyword and a colon: the scheme registry. So if animals 
become important enough that they need their own scheme, I guess people 
could register them that way. Alternatively, a short domain followed by a 
keyword seems like a reasonable option: instead of "animal:cat", have 
"org.animal.cat": it's only four more characters. (Actually, with ICANN 
considering opening up TLDs, people could just register those: 
"animal.cat" is a valid reverse DNS label if "animal" is a TLD!)

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

Re: [whatwg] Installed Apps

[Mike Wilson]

Drew Wilson wrote:
>
> SharedWorkers are overloaded to provide a way for 
> pages under the same domain to share state, but 
> this seems like an orthogonal goal to "parallel 
> execution" and I suspect that we may have ended 
> up with a cleaner solution had we decided to 
> address the "shared state" issue via a separate 
> mechanism.
>
> [...] 
>
> 3) Sharing between pages requires going through 
> the database or shared worker - you can't just 
> party on a big shared datastructure.

Assuming this shared state doesn't require a full
JavaScript global context, and could do with some
root object or collection, would it be possible to 
extend Web Storage to support this task?

Best regards
Mike Wilson

[whatwg] Microdata Revisited

[Martin McEvoy]

Hello All

I have been working on a new proposal for HTML 5 Microdata, I thought 
you might all like to take a look at what I have come up with so far.


please visit http://weborganics.co.uk/test/microdata.html

Any feed back would be nice ;)

Best wishes

--
Martin McEvoy
http://weborganics.co.uk/

Re: [whatwg] AppCache can't serve different contents for different users at the same URL

[Mike Wilson]

I agree it would be interesting to have the browser being
able to distinguish between different variants of a page
based on who is "logged in", whether it be through cookies
or other mechanisms. But cookies should be included as 
they are one official way to store state.

Storing several variants of a page in a cache, using some
algorithm to select the suitable variant, draws many
parallels with HTTP caching. A good way of working with 
AppCache features might be to first get them working with
traditional caching.

For traditional caching there is the HTTP 1.1 Vary header,
that tells the browser what headers' values identify a
unique page variant. F ex
  Vary: Cookie
together with suitable Cache-Control headers would tell 
the browser to cache individual page variants for each 
value of the Cookie header.

A problem with this is that it will treat all cookies for
the page in one lump. In 1997 there was a proposal for 
identifying individual cookies, f ex:
  Vary: Cookie.USERID
or
  Vary-Cookie: USERID
but it seems it was dropped. Anyway, maybe it is 
interesting to reread the discussion to find correlations
to current AppCache topics:
http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0334.html

As Ian says, client-centric webapps are probably the most 
straight-forward solution for offline apps. But given that 
the majority of today's webapps are probably server-centric, 
it would be interesting to see what can be done to easily 
support offline for them. It would be good to hear someone 
flesh out a (non-trivial) complete server-centric example, 
as there may be need for more features than just multi-
variant pages to get it working well.

Best regards
Mike Wilson

Ian Hickson wrote:
>
[...]
> On Wed, 22 Jul 2009, Aaron Whyte wrote:
> >
> > Imagine two users of fancyapp.com, with their own logins 
> > and data and custom skins and whatnot.  The contents of 
> > the main page are uncacheable and are totally different 
> > depending on the cookies in the request, which tell the 
> > server who is logged in.  This is the way nearly every 
> > web app works today, and this is also the way a lot of 
> > people share a single computer.
> > 
> > Without any offline support, they can share one browser, 
> > if one logs out of fancyapp, and the other logs in.
> > 
> > If fancyapp supports offline use with Gears, then one of 
> > the users can install an offline client, without 
> > affecting the other user, because of requiredCookie.
> > 
> > But if fancyapp supports offline use with HTML5's app 
> > cache, then if one user installs an offline client, 
> > fancyapp will keep working for that user, but not for 
> > the other user, who will have to go get their own 
> > computer, browser, profile, or whatever they need to 
> > avoid hitting the other user's app cache.
> > 
> > The engineers at fancyapp could rewrite their mail page 
> > so it's just a little router that looks at cookies and 
> > makes subsequent requests to user-specific URLs to really 
> > load the app.  But that's an inferior user experience, 
> > because it introduces an extra round trip to get the
> > initial page properly rendered.  So they'll probably have 
> > to support both.
> >
> > If the application code (HTML, JS, CSS) is all the same 
> > for two users, then appcache works for multiple users by 
> > just having the data for the users separate from the 
> > logic.
[...]

Re: [whatwg] More input element feedback

[Ian Hickson]

On Thu, 23 Jul 2009, Kartikaya Gupta wrote:
>
> The description for what to do on setting valueAsNumber doesn't fully 
> cover error conditions. It's not clear to me, for instance, what's 
> supposed if you have an input type="date" or type="number" and try to 
> set valueAsNumber to NaN. The description there (for date) just says 
> "... passing it a Date object whose time value is the new value ..." but 
> doesn't say what to do if the Date object can't be created.

# Unless otherwise specified, if a DOM attribute that is a floating point 
# number type (float) is assigned an Infinity or Not-a-Number value, a 
# NOT_SUPPORTED_ERR exception must be raised.
 -- http://www.whatwg.org/specs/web-apps/current-work/#dependencies


> Also, editorial fix: in the same two paragraphs ("On getting" and "On 
> setting" for valueAsNumber), the link to valueAsDate is wrong; it just 
> links back to #dom-input-valueAsNumber instead of 
> #dom-input-valueAsDate.

It appears I already fixed that already.

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

Re: [whatwg] "Content model" vs. "Contexts in which this element may be used"

[Ian Hickson]

On Thu, 23 Jul 2009 dar...@chaosreigns.com wrote:
>
> These sections have very different wordings given the fact that they 
> directly correspond to each other.
> 
> Maybe change 
> 
>   "Contexts in which this element may be used" to
>   "Content models in which this element may be used".

I think that change would be wrong. For example, take : it's allowed 
"Before dd or dt elements inside dl elements", which isn't a content model 
-- the content model of  is "Zero or more groups each consisting of 
one or more dt elements followed by one or more dd elements", but saying 
that as the context in which  is allowed would be like answering the 
wrong question.

Having that that, I've added a section explaining exactly how to read 
these element definitions, and making the "contexts in which..." non- 
normative.

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