Re: [whatwg] Content model vs. Contexts in which this element may be used
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 dd: it's allowed Before dd or dt elements inside dl elements, which isn't a content model -- the content model of dl 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 dt 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] More input element feedback
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] Installed Apps
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
Re: [whatwg] Microdata and Linked Data
(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: section id=http://john.example.com#hedral; item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 /section I assume you can achieve something similar with the about property but that would require me to write: section item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section This is longer by itself, and if I want an internal identifier as well, than I have to write: section id=hedral item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section 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 img or a video 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? section id=hedral namespaces=http://www.w3c.org/registry/; item=animal:cat h1 itemprop=animal:nameHedral/h1 /section 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] Type of PropertyNodeList.contents
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 sequenceany 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] Section 3.3.3.2 Attribute value normalization and title attributes
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] Close events and workers
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] Images whose contents are not known In such cases, the alt attribute's value may be omitted...
On Fri, 24 Jul 2009, Tab Atkins Jr. wrote: On Fri, Jul 24, 2009 at 12:07 PM, dar...@chaosreigns.com 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] Microdata and Linked Data
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] the cite element
On Mon, 27 Jul 2009, Erik Vorhes wrote: On Sun, Jul 19, 2009 at 4:58 AM, Ian Hicksoni...@hixie.ch wrote: If cite is exclusively for titles, it shouldn't be called cite. 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 cite seem to use it for titles, and people who use cite= seem to use it for URLs. (The latter is rare.) See http://www.four24.com/; note near the top of the source: blockquote id=verse cite=John 4:24... 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 cite. (Looks like non-title uses are very common.) This seems to support my point that cite is used for a whole variety of purposes, like em, i, q, HTML4's cite, and HTML5's cite. 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, cite is already being used for this purpose. My preference would be for cite 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 cite 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 legend outside of fieldset 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 figure 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. i, b, cite, menu, legend, h1). What is the pressing need for an element for citations, which would require that we overload cite with two uses? A title can be a citation, but not all citations are titles. What's the pressing need for limiting cite 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 cite with two uses? I understand HTML5's attempts to provide semantic value to such elements as i, b, and small. To at the same time remove semantic value at the same time is completely asinine. If cite's original meaning has value, that is true; what is its value? I would assume that this would be obvious. cite 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 cite element in the manner you describe. Since this is supposed to be the case, why shouldn't HTML5 just ditch cite 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 cite 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 cite that does not use it to signify title of work. As I said, the most common use of cite 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.
Re: [whatwg] Accessibility for Drag and Drop
Hi Ian, firstly thanks for your comments. --- Ian Hickson i...@hixie.ch 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
[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] the cite element
On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson i...@hixie.ch wrote: See http://www.four24.com/; note near the top of the source: blockquote id=verse cite=John 4:24... 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 cite. (Looks like non-title uses are very common.) This seems to support my point that cite is used for a whole variety of purposes, like em, i, q, HTML4's cite, and HTML5's cite. 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 cite 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, cite is already being used for this purpose. My preference would be for cite 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 cite 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 cite 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 cite 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 legend outside of fieldset 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, b, cite, menu, legend, h1). 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 legend, for example, is completely broken in every extant browser. (See http://html5doctor.com/legend-not-such-a-legend-anymore/ for evidence). Besides, there's already tt, 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 cite with two uses? A title can be a citation, but not all citations are titles. What's the pressing need for limiting cite 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 cite with two uses? As I have said previously, there aren't consistent typographic conventions that apply to titles. The pressing need is that cite 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 cite element in the manner you describe. Since this is supposed to be the case, why shouldn't HTML5 just ditch cite 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 automatically
[whatwg] New HTML5 spec-editing tools released
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] HTML5: has input device: use motion detection been included?
Hi Jonathon, On Mon, 03 Aug 2009 10:27:02 -0400, ~:'' ありがとうございました j.chetw...@btinternet.com 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
Re: [whatwg] HTML5: has input device: use motion detection been included?
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, ~:'' ありがとうございました j.chetw...@btinternet.com 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] AppCache can't serve different contents for different users at the same URL
On Mon, Aug 3, 2009 at 4:20 AM, Mike Wilsonmike...@hotmail.com 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?
On Mon, 03 Aug 2009 12:25:58 -0400, Marcin Hanclik marcin.hanc...@access-company.com 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, ~:'' ありがとうございました j.chetw...@btinternet.com 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] the cite element
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 cite 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—i, b, small—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 cite 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 dl element in HTML4 where the example in the spec showed it being used for dialogue; authors (rightly) ignored the spec. The meaning of the cite element is a classic example of a language feature rather than a platform feature. canvas and video 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 cite 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 cite 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 cite 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 cite 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 form. What element do you use to contain your form field and your label? Some authors use divs. Some authors use ps. Some authors use lis. 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 p 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 table 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 cite 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] Web Workers and postMessage(): Questions
On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson i...@hixie.ch 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] Web Workers and postMessage(): Questions
On Mon, Aug 3, 2009 at 10:34 AM, Daniel Gredler daniel.gred...@gmail.comwrote:
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
On Mon, 03 Aug 2009 19:47:14 +0200, Maciej Stachowiak m...@apple.com 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
On Aug 3, 2009, at 10:34 AM, Daniel Gredler wrote: On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson i...@hixie.ch 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] Installed Apps
On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilsonmike...@hotmail.com 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] Installed Apps
Michael Nordman wrote: On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilsonmike...@hotmail.com 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] Installed Apps
On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilsonmike...@hotmail.com wrote: Michael Nordman wrote: On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilsonmike...@hotmail.com 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] Web Workers and postMessage(): Questions
On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler daniel.gred...@gmail.comwrote: 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] More input element feedback
On Mon, Aug 3, 2009 at 12:09 AM, Ian Hicksoni...@hixie.ch 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] Installed Apps
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 iframes 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 sharedContext isn't gauranteed to be a
Re: [whatwg] Canvas context.drawImage clarification
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. `._.-(,_..'--(,_..'`-.;.'
