Re: [DOM4] Mutation algorithm imposed order on document children
On 6/11/12 7:39 PM, Elliott Sprehn wrote: After discussing this with some other contributors there were questions on why we're enforcing the order of the document child nodes. Because otherwise serialization of the result would be ... very broken? Can we leave the behavior when your document is out of order unspecified? You mean allow UAs to throw or not as they wish? That seems like a pretty bad idea, honestly. We should require that the insertion be allowed (and then specify what DOM it produces) or require that it throw. -Boris
[Bug 17467] New: Established in 2003, http://www.fashionskateshoes.com, was born out of the streets desire for urban biased fashion. When SUPRA,NIKE NEW BALANCE,GUCCI were causing waves in the earl
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17467 Summary: Established in 2003, http://www.fashionskateshoes.com, was born out of the streets desire for urban biased fashion. When SUPRA,NIKE NEW BALANCE,GUCCI were causing waves in the early 2000's the fashion of hip hop and urban shoes came to the fore in a big w Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Established in 2003, http://www.fashionskateshoes.com, was born out of the streets desire for urban biased fashion. When SUPRA,NIKE NEW BALANCE,GUCCI were causing waves in the early 2000's the fashion of hip hop and urban shoes came to the fore in a big way...with no retailers around to provide for this genre [b][i][URL=http://www.fashionskateshoes.com]Cheap Supra shoes for girls[/URL][/i][/b] was born, kicking off by selling the likes of SUPRA,NIKE NEW BALANCE, and a whole host of other cool brands of the time. What your fav rap star rocked we provided! Posted from: 175.44.16.242 User agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [webcomponents] HTML Parsing and the element
* Rafael Weinstein wrote: >I think looking at this as whether we are "breaking the correspondance >between source and DOM" may not be helpful -- because it's likely to >be a matter of opinion. I'd like to suggest that we look at more >precise issues. > >There are several axes of "presence" for elements WRT to a Document: > >-serialization: do the elements appear in the serialization of the >Document, as delivered to the client and if the client re-serializes >via innerHTML, etc... >-DOM traversal: do the elements appear via traversing the document's >childNodes hierarchy >-querySelector*, get*by*, etc: are the element's returned via various >document-level query mechanisms >-CSS: are the element's considered for matching any present or future >document-level selectors And one might take the position that all of these should be defined in terms of what you call "DOM traversal", making them all the same, with- in the confines of a DOM View, a concept that has fallen out of favour. >The goal of the element is this: the page author would like >a declarative mechanism to author DOM fragments which are not in use >as of page construction, but are readily available to be used when >needed. Further, the author would like to be able to declare the >fragments inline, at the location in the document where they should be >placed, if & when they are needed. > >Thus, template require that its contents be "present" for only >serialization, and not for DOM traversal, querySelector*/etc..., or >CSS. I do not see the "thus" here. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[DOM4] Mutation algorithm imposed order on document children
I'm working on places where Webkit doesn't follow the DOM4 mutation algorithm and one of the bugs is not throwing an exception when a doctype node is inserted after an element in a document (or other permutations of the same situation). https://bugs.webkit.org/show_bug.cgi?id=88682 http://www.w3.org/TR/domcore/#mutation-algorithms After discussing this with some other contributors there were questions on why we're enforcing the order of the document child nodes. Specifically since inserting a doctype node doesn't actually change the doctype so this situation is very unlikely (possibly never happens) in the wild. Not implementing this keeps the code simpler for a case that developers likely never see. Can we leave the behavior when your document is out of order unspecified? - Elliott
Re: [Server-Sent Events] Infinite reconnection clarification
On Tue, 17 Apr 2012, Odin Hørthe Omdal wrote: > > If I understand correcly, the spec expects the implementation to keep > reconnecting indefinitely, when the network cable is yanked. No. The spec says "Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection." and "Once the user agent has failed the connection, it does not attempt to reconnect". (In particular, note that "reestablish the connection" only ever occurs if the remote resource is actually obtained with the right MIME type.) > I tried yanking the network for 10+ minutes, and when I put the cable in > again, both Firefox and Chromium used 25 seconds to reconnect. When only > yanking it for one minute, the reconnection was much faster (2-5 > seconds). This with *reconnection time* set to 500ms. As far as I can tell, none of that is conforming. If you yank the cable, they should retry once, then give up, per the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Push API draft uploaded
Greetings Bryan, First thanks for digging into it, here are some comments I have mostly stuff I feel is missing from the spec (and I guess some points may be open to discussion on wether they fall in the scope of this spec or not) : - Positioning towards the eventSource API. As far as developer is concerned both these specs seem to accomplish mostly the same thing. I feel we should add some clarification on when one or the other should be used. - Some callflows (I guess this is due to the early stage of the spec tho), from what I get the UA creates a pushservice indicating the URL of a selected push "proxy" and gets a URL where the webapp can send messages to that it then needs to communicate to the service server to actually be able to start getting messages. - Specs for the proxy, so far only the user agent side is defined and the exchanges between UA and proxy seem to remain fuzzy, same goes on the exchanges between proxy and web server. - Bearer switching, one of the points to introduce the spec was to be able to switch bearers for eventsources to allow battery saving on mobile devices. But there seems to be nothing about it in the spec. Are we letting the bearer switch to be done by the use of a different push service for lets say IP and SMS Push ? If so how is the change handled and what events can the app developer rely on to decide to switch ? - SLAs, default services, multiple services... Again from a first look every application seems to be able to select its own push service proxy, as it is defined I feel the application developer has to publish his own push proxy in order to use the API (that's why I feel we should have a must have for a default proxy somewhere (could actually just be some kind of fallback to eventsource). Also every application can have its own proxy, if those proxies are some of those proxies are "public" (ie accept notification support from other applications) it would be interesting to know that and also to know if some of those proxies offer some guarantees as far as QoS is concerned, and thus have some form of mechanism to discover registered proxys within the browser (doubt the intent mechanism is ideal for this however) and criterias to select which one my application can use. Cheers, Arnaud Braud _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Re: [webcomponents] HTML Parsing and the element
On Mon, Jun 11, 2012 at 3:13 PM, Henri Sivonen wrote: > On Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. wrote: >> Just saying that querySelector/All doesn't match elements in a >> template (unless the scope is inside the template already) would work, >> but it means that we have to make sure that all future similar APIs >> also pay attention to this. > > I think that would be preferable compared to opening the Pandora's box > of breaking the correspondence between the markup of the DOM tree. > Besides, we'd need something like this for the XML case anyway if the > position the spec takes is that it shies away from changing the > correspondence between XML source and the DOM. > > In general, I think the willingness to break the correspondence > between the source and the DOM should be the same for both HTML and > XML serializations. If you believe that it's not legitimate to break > the correspondence between XML source and the DOM, it would be logical > to treat radical changes to the correspondence between HTML source and > the DOM as equally suspect. I think looking at this as whether we are "breaking the correspondance between source and DOM" may not be helpful -- because it's likely to be a matter of opinion. I'd like to suggest that we look at more precise issues. There are several axes of "presence" for elements WRT to a Document: -serialization: do the elements appear in the serialization of the Document, as delivered to the client and if the client re-serializes via innerHTML, etc... -DOM traversal: do the elements appear via traversing the document's childNodes hierarchy -querySelector*, get*by*, etc: are the element's returned via various document-level query mechanisms -CSS: are the element's considered for matching any present or future document-level selectors The goal of the element is this: the page author would like a declarative mechanism to author DOM fragments which are not in use as of page construction, but are readily available to be used when needed. Further, the author would like to be able to declare the fragments inline, at the location in the document where they should be placed, if & when they are needed. Thus, template require that its contents be "present" for only serialization, and not for DOM traversal, querySelector*/etc..., or CSS. Also, it may be helpful to think about this in terms of classical object systems. Currently we only have instances. What we need is a classes. Native app windowing systems don't force you to create an instance of every window or dialog that your app may ever need and place it off screen until it's needed. They allow for the notion of declaring what the window or dialog will be and delay creating any UI resources (HWNDs, buttons, drag targets, etc..) until the app creates an instance. > > I worry that if we take the position here that it's okay to change > your correspondence between the source and the DOM in order to > optimize for a real or perceived need, it will open the floodgates for > all sorts of arguments that we can make the parser generate whatever > data structures regardless of what the input looks like and we'll end > up in a world of pain. It's bad enough that isindex is a parser macro. > > -- > Henri Sivonen > hsivo...@iki.fi > http://hsivonen.iki.fi/
Re: [IndexedDB] WebIDL-related spec nits
On Mon, Jun 11, 2012 at 10:09 AM, Anne van Kesteren wrote: > On Mon, Jun 11, 2012 at 6:44 PM, Joshua Bell wrote: > > On Sun, Jun 10, 2012 at 7:45 PM, Kyle Huey wrote: > >> IDBRequest.readyState should be an enum type, not a DOMString. > > > > This was an intentional change, see discussion starting at: > > > > http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0814.html > > > > Are you pointing out an inconsistency in the spec, or expressing a > > preference? > > There was a change from constants to DOMString. But DOMString is > wrong. http://dev.w3.org/2006/webapi/WebIDL/#idl-enums should be used. > Ah, sorry. In that case, I completely agree.
Re: [IndexedDB] WebIDL-related spec nits
On Mon, Jun 11, 2012 at 6:44 PM, Joshua Bell wrote: > On Sun, Jun 10, 2012 at 7:45 PM, Kyle Huey wrote: >> IDBRequest.readyState should be an enum type, not a DOMString. > > This was an intentional change, see discussion starting at: > > http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0814.html > > Are you pointing out an inconsistency in the spec, or expressing a > preference? There was a change from constants to DOMString. But DOMString is wrong. http://dev.w3.org/2006/webapi/WebIDL/#idl-enums should be used. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [IndexedDB] WebIDL-related spec nits
On Sun, Jun 10, 2012 at 7:45 PM, Kyle Huey wrote: > (Note, I did not include the various things relating to keyPath that I > mentioned last week, because I do not consider those to be trivial changes). > > Globally, the spec is inconsistent about whether the prose is in the same > order as the IDL, or whether the prose is in alphabetical order. I would > prefer the former, but consistency of some sort is desirable. > > 3.1.9 > > The return type of the static functions on IDBKeyRange is not 'static > IDBKeyRange', it is just 'IDBKeyRange'. > > 3.2.1 > > The correct type name is "object", not "Object" (note the capitalization). > > IDBRequest.readyState should be an enum type, not a DOMString. > This was an intentional change, see discussion starting at: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0814.html Are you pointing out an inconsistency in the spec, or expressing a preference? > 3.2.2 > > IDBVersionChangeEvent should probably reference whatever spec defines how > constructors work for DOM events. > > 3.2.4 > > IDBDatabase.transaction's mode argument should be an enum type, with a > default value specified in IDL instead of in prose. > See above. > 3.2.5 > > Is it intentional that IDBObjectStore.indexNames does not return the same > DOMStringList every time, unlike IDBDatabase.objectStoreNames (yes, I > realize that the circumstances under which the former can change are much > broader). > > IDBObjectStore.openCursor's direction argument should be an enum type, > with a default value specified in IDL (right now it is unspecified). > See above. > > 3.2.6 > > IDBIndex.openCursor and IDBIndex.openKeyCursor's direction argument should > be an enum type, with a default value specified in IDL. > See above. > 3.2.7 > > "Object" should be "object". > > 3.2.8 > > IDBTransaction's mode attribute should be an enum type. > See above. > Also, it would be nice if we could tighten up keys from 'any' to a union. Agreed.
Re: [webcomponents] HTML Parsing and the element
On Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. wrote: > Just saying that querySelector/All doesn't match elements in a > template (unless the scope is inside the template already) would work, > but it means that we have to make sure that all future similar APIs > also pay attention to this. I think that would be preferable compared to opening the Pandora's box of breaking the correspondence between the markup of the DOM tree. Besides, we'd need something like this for the XML case anyway if the position the spec takes is that it shies away from changing the correspondence between XML source and the DOM. In general, I think the willingness to break the correspondence between the source and the DOM should be the same for both HTML and XML serializations. If you believe that it's not legitimate to break the correspondence between XML source and the DOM, it would be logical to treat radical changes to the correspondence between HTML source and the DOM as equally suspect. I worry that if we take the position here that it's okay to change your correspondence between the source and the DOM in order to optimize for a real or perceived need, it will open the floodgates for all sorts of arguments that we can make the parser generate whatever data structures regardless of what the input looks like and we'll end up in a world of pain. It's bad enough that isindex is a parser macro. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
