Re: Custom-elements: document.registerPolyfillElement ?

2014-06-10 Thread Brett Zamir
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,

On 6/10/2014 2:00 PM, Dominic Cooney wrote:
On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir 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: 

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.



Custom-elements: document.registerPolyfillElement ?

2014-06-09 Thread Brett Zamir
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 

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.)


Scoped absolute paths in querySelector/All

2013-09-06 Thread Brett Zamir
I am wondering whether thought has been given to allowing selectors 
beginning with  for use with querySelector/All such as:


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
span class=sharedClassSecond/span


  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


(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..


Server-Sent Event types

2011-04-28 Thread Brett Zamir
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,

Server-Side Events encoded in JSON

2011-04-28 Thread Brett Zamir
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 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).


Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-30 Thread Brett Zamir

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 


Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-25 Thread Brett Zamir

On 6/25/2010 5:09 PM, Anne van Kesteren wrote:
On Wed, 23 Jun 2010 01:53:51 +0200, Travis Leithead 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 
) 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.)