On Thu, May 17, 2012 at 3:21 PM, Yehuda Katz wyc...@gmail.com wrote:
I am working on it. I was just getting some feedback on the general idea
before I sunk a bunch of time in it.
For what it's worth, I definitely support this idea too on a general
level. However as others have pointed out, the
On 5/17/12 7:03 PM, ext Julian Aubourg wrote:
To me the biggest abomination of all is
Just a reminder that WebApps' [PubStatus] page enumerates all of its
specs and for each spec, there (or will be): a) a link to the spec's
Bugzilla component; b) a link to the spec's Test Suite.
Finally,
[ My previous response was accidentally sent before it should have been
(delete it) ... ]
On 5/17/12 7:03 PM, ext Julian Aubourg wrote:
To me the biggest
Comments on all of WebApps' specs are always welcome, regardless of
where the spec is in the W3C's Recommendation process.
I've been
A related TL;DR observation...
While we may get 5 things that really help shrink the current set of
problems, it adds APIs which inevitably introduce new ones. In the
meantime, nothing stands still - lots of specs are introducing lots of new
APIs. Today's 'modern browsers' are the ones we are
Chris Pearce is not on this mailing list. Chris are you okay with
moving discussion to here? Anyone else who should be kept in the loop?
On Thu, May 17, 2012 at 11:21 PM, Edward O'Connor eocon...@apple.com wrote:
Document.fullscreenEnabled is not defined in normative spec prose.
It is
Not that I want to start another bike-shedding, there is one clear
distinction between innerHTML and createDocumentFragment, which is that
innerHTML sets already-started flag on parsed script elements
but createDocumentFragment does not (or rather it unsets it after the
fragment parsing algorithm
On May 17, 2012, at 10:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 17, 2012 at 3:21 PM, Yehuda Katz wyc...@gmail.com wrote:
I am working on it. I was just getting some feedback on the general idea
before I sunk a bunch of time in it.
For what it's worth, I definitely support
So the Web Socket spec is a little vague on how JS is notified when
the targeted web socket server is down/nonexistent/etc.
Firefox is firing an 'error' event when this happens, based on the language
here in the W3C spec:
if the status code received from the server is not 101 (e.g. it is a
To me the biggest abomination of all is the XMLHttpRequest object:
- the spec is probably one of the most complex I've seen
- yet, vast portions are left to interpretations or even not specified
at all:
- the local filesystem comes to mind,
- also every browser has its own
So the Web Socket spec is a little vague on how JS is notified when
the targeted web socket server is down/nonexistent/etc.
Firefox is firing an 'error' event when this happens, based on the
language here in the W3C spec:
if the status code received from the server is not 101 (e.g. it is
a
10 matches
Mail list logo
