Re: Custom-elements: document.registerPolyfillElement ?
Thanks, this is helpful to know, though I'd still prefer a solution at
some point which didn't require one to use extra code and once the
polyfill was no longer needed, requiring alteration of code to be
semantically correct (e.g., if it no longer is a x-polyfill-dialog
because the registration for it was removed) and non-redundant.
Best wishes,
Brett
On 6/10/2014 2:00 PM, Dominic Cooney wrote:
On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir bret...@gmail.com
mailto:bret...@gmail.com wrote:
I was looking to make a genuine polyfill for dialog (not just a
shim), and I found Polymer's CustomElements helpful, but realized
too late that the spec required x- prefixes.
I still feel like it would be useful to have a means for polyfills
to be built according to well-recognized semantics via a standard
extension mechanism.
It is possible to do this using a type extension. For example:
document.register('x-polyfill-dialog', {prototype: ..., extends:
'dialog'})
This produces a type extension of the HTMLUnknownElement with the tag
name dialog in browsers that don't support dialog, and a type
extension of the HTMLDialogElement of ones that do.
The only wrinkle is that markup must use dialog is=x-polyfill-dialog.
Your polyfill can degrade gracefully in whichever way you decide. For
example, you could detect HTMLDialogElement and not register the
Custom Element, in which case the markup will create unresolved type
extensions of HTMLDialogElement that get the browser's native dialog.
Or you could go ahead and register your polyfill anyway, in which case
your prototype object would hide the browser's HTMLDialogElement
prototype. Or you could do something dynamic inbetween.
HTH,
Dominic
Custom-elements: document.registerPolyfillElement ?
I was looking to make a genuine polyfill for dialog (not just a shim), and I found Polymer's CustomElements helpful, but realized too late that the spec required x- prefixes. I still feel like it would be useful to have a means for polyfills to be built according to well-recognized semantics via a standard extension mechanism. How about something like `document.registerPolyfillElement`? As I envision it, it would, besides also allowing for elements without hyphens, behave in the same way as `document.registerElement` (I understand this will be replacing `document.register`), but if `document.createElement` would return anything besides `HTMLUnknownElement` for the supplied element name, it would immediately return that element's own constructor (or perhaps throw an exception if no constructor were allowed for that element). This would provide the added convenience of not having to feature detect existing support. Or perhaps `document.registerElement` could be supplied a flag to indicate a polyfill was intended. (Maybe the mechanism could even allow one to polyfill specific methods of existing elements, taking advantage of `attributeChanged`, for example.) Thanks, Brett
Scoped absolute paths in querySelector/All
I am wondering whether thought has been given to allowing selectors
beginning with for use with querySelector/All such as:
.sharedClass
Sometimes one wishes to resolve a precise hierarchy but relative to the
current element. Currently, to do so with precision, one must either
specify a path starting from the document root, a unique ID, or use
other scripting methods.
Having such an option would provide the same convenience for precise
access as XPath or to a lesser extent, as JSON, allow.
The following document illustrates the concern--in this case, where we
are trying to get only the second span relative to #div1 but without
needing to specify or be aware of the whole document hierarchy:
!DOCTYPE htmlhtmlheadmeta charset=utf-8 //headbody
div id=div1
span class=sharedClassFirst/span
div
span class=sharedClassSecond/span
/div
/div
script
var s = document.querySelector('#div1');
// The following gets both spans instead of the one directly inside
that we want
var relativeSelector = s.querySelectorAll('.sharedClass');
alert(relativeSelector.length); // 2
// The following gets the desired span, but required us to specify
the full path or redundantly express the path to our parent again
var absoluteSelector = s.querySelectorAll('#div1 .sharedClass');
alert(absoluteSelector[0].textContent); // First
/script/body/html
(Although the use case would be far less common, a path might also begin
with when run against documents to allow usage with XML documents
where a path was desired relative to the root but without committing to
a specific root element.)
It would also be nice to be able to modify the element or
elements--e.g., if there were a removeSelector(sel) analogue to the
ability to use delete obj.prop.prop2 on a JSON object, a
replaceSelector(sel, el) convenience method, etc..
Best,
Brett
Server-Sent Event types
I am a newcomer to the Server-Sent Events spec, so my apologies if I am covering old ground. While I can understand that Server-Sent Events may be intending to start off simple, I wonder whether there is some reason a formal mechanism was not adopted to at least allow the specification of event types. I think such a convention would have a number of important benefits. Of course, one can already simulate event types: 1) One could exclusively alter the data itself to embed such types, but this pushes more responsibility for parsing the response data to the user (and will increase the amount of data needing to be transferred, both for the need to always respecify for each message the type in the data stream, as well as for the need of a particular client to receive all types of data even if it didn't register itself for receiving that type). And that parsing of types would not end up becoming familiarly uniform for users of libraries, and would not be conducive to extensibility; if someone wished to add new events later on, old client-side code might need to be rewritten. 2) One could instead simulate event types by supplying a different URL or a URL with different parameters, but with the disadvantage that multiple requests would presumably need to be established for each parameter combination--adding unnecessary connections and an inability to handle different types within the same response handler. Moreover, without a specific REST type of convention for event types, there again would be no familiarly uniform way to specify event types, preventing a clear and easy way to add new event types. It would seem to me that the specification could still be kept simple, while still offering safer and more convenient flexibility for the future, if something like the following were followed: 1) The EventSource object could be optionally supplied with a particular query string parameter (e.g., sse-type= or sse-types=) (if not also as a key-value object second argument). If no other types were added, the data stream itself would not need to encode type, although a type property could still be set on the event object (see below). This would allow a common convention, regularizing client-side and server-side library creation, and in the case where only a single type were specified, avoids the need for extra data to be added to the stream to indicate type. 2) For cases where the application did wish to share a connection for different types, an analogue to addEventListener could make it possible for the client to notify the server to add more types to the stream while reusing the same connection (though this would require some additional mechanism, such as a different REST parameter like add-sse-type= if not adding to a two-way stream). A type property could then be made available on the response event object to allow the user to be able to conveniently filter the types depending on the response and the state of the client application, without the need for hackish and non-uniform parsing of response data. 3) Custom event types should be indicated by some unique mechanism (e.g., requiring unrecognized types to be preceded by x-) so that if the specification were to be expanded upon in the future to support official protocols, they could do so without impacting existing code. However, when no type is supplied, this could also be assumed to be a custom event, but without any namespace. This would allow the specification to be backwards-compatible. It seems to me that the above suggestions would not add an undue amount of complexity (and avoid or postpone any commitment to defining specific event types), while also providing a better framework for manageable extensibility into the future. Best wishes, Brett
Server-Side Events encoded in JSON
user to parse the response text, why not simply allow each event to be a JSON-encoded object of some kind (boolean, number, string, array, object). Then the event.data could be an object which was already conveniently accessible to JavaScript consumers. Presumably server-side libraries would handle the work of doing the encoding, but the average client-side consumer should, in my opinion, not need to be concerned with implementation details, except to become familiar with the specific JSON response types being sent by the server-side code/library. Although this would add encoding responsibilities to the server and decoding responsibilities to the browser, I think it ought to avoid the need for the client code to be concerned with ugly implementation details such as the need to parse strings. A convention might also be used in the stream (e.g., error: followed by a JSON object) to trigger errors, allowing the normal responses to be simple strings or the like, while offering a means to distinguish them from error messages sent by the server (e.g., to indicate that a data source was no longer available). The event object could add an error property which could be checked (or, if types were allowed as per my previous post, it could set the event type to the reserved string error). Brett
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On 6/29/10 2:36 PM, Chris Wilson wrote: See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. Note that the Firefox behavior I described is irrelevant to specification efforts, because it's not visible to web pages I would really like to know (along the lines of the changed thread title) why other browsers are not, as it appears, interested in making this part of a specification effort. Although there might not yet be interest to make some official standard for browser add-ons at this point, I would think that in this one crucial area, browsers could consider allowing extension authors and web developers the ability to have a common means, regardless of browser, of communicating back-and-forth in the same protocol by using custom DOM events in this way as Firefox currently does. It is no small functionality to allow websites the abiility to communicate with add-ons and in an extensible manner. Despite being an advocate of open source and open formats myself, I strongly disagree with the sentiment I have heard some express, that the ability to make custom formats within X/HTML, whether through namespaced elements and attributes or processing instructions (both regrettably disallowed by HTML at present, in my view) or by custom DOM events, is only promoting proprietary formats. On the contrary, I feel that such ability to experiment allows new standards to emerge which meet needs that HTML is not presently willing to implement. Here are just a few use cases, though the list could really go on and on: 1) Allowing websites to interact with client-side chat clients for real-time collaboration by site visitors (as the Firefox extension SamePlace does) 2) Allowing websites to share and access each other's databases when permitted by the site (or even by the user alone) a) Adoption of more specific shared database formats in a specific genre like the ability to view, schedule, and edit meetings or events 3) Supporting the ability to query XML databases with powerful XQuery and update facilities through the browser. While it is great that the big browsers have settled on avoiding too extreme a competition with their own new markup, going through standards bodies at least in cases like video/ where there is no need for 1000 different ways to express the markup (even while the case could be made for allowing 1000 different namespaced attributes on the tag until standardization is complete), smaller sites or special interests if not bigger organizations as well, still need the ability to innovate. The web will clearly not settle for perpetually proprietary formats anyways, except in cases where the standards have not yet caught up. And proprietary here is a relative term since the underlying platform (DOM/XML) is still itself standardized. Better to give the means for innovation in the first place but in a way which can be made to work cross-browser, rather than shut the door and treat web innovators and users paternalistically if not outright domineering them by maintaining exclusive control in the name of their supposed interest. While it is great that web authors have not been precipitously forced to use XML, it is a pity, in my view, that the extensibility of XML has not been carried over and embraced, even if a co-editor of XML himself (reasonably) suggested avoiding creating new dialects where possible. Please give us at least one means of extending functionality beyond what you currently happen to support or want to support... Brett
Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On 6/25/2010 5:09 PM, Anne van Kesteren wrote: On Wed, 23 Jun 2010 01:53:51 +0200, Travis Leithead tra...@microsoft.com wrote: This topic came up internally on the IE team, and we thought it would be noteworthy to put this question before the working groups in hopes of getting a spec clarification made. The question is: for XHR and other non-DOM related objects that support the EventTarget interface, meaning objects that will be surfaced off of window but aren't really a part of the markup tree, how should event propagation be handled? Events only propagate within a DOM tree. In addition there are some special cases for the global object noted in the HTML5 specification. Other than that there is no propagation. This is I guess a bit unrelated, but I was wondering whether thought been given to allowing custom events to allow formal propagation beyond the document (as described in https://developer.mozilla.org/en/Code_snippets/Interaction_between_privileged_and_non-privileged_pages#Sending_data_from_chrome_to_unprivileged_document ) in a way that works cross-browser? Although this is more suitable for small-scale experimentation rather than formal APIs (especially with events not allowing formal namespaces), it would be nice to have a method for allowing web-extension communication that could potentially be expanded to work in more than one browser, especially as other browsers enhance their add-on infrastructure. (I guess in Firefox the document is all part of one big tree that includes the add-on markup, so propagation is indeed within the same DOM tree, but not sure whether other browsers treat add-ons as fully separate, or if there is at least interest to make them work the same way.) Brett
