Re: [whatwg] Technical Parity with W3C HTML Spec
On Jun 25, 2010, at 5:13 AM, Doug Schepers wrote: There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. 5) W3C could go away
[whatwg] entry script
Sorry for the repeat message... But entry script is a rather fundamental concept in web workers and its not defined as far as I can tell. Can someone tell me where and how its defined? I don't see how entry script is set, when it is set, or what it is set to. Initially, there is no entry script. [1] Can someone help me out? [1] http://dev.w3.org/html5/spec/browsers.html#entry-script Thanks, Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
[whatwg] entry script
I don't see how entry script is set, when it is set, or what it is set to. Initially, there is no entry script. [1] Can someone help me out? [1] http://dev.w3.org/html5/spec/browsers.html#entry-script Thanks, Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
Re: [whatwg] Should scripts and plugins in contenteditable content be enabled or disabled?
On May 19, 2010, at 8:14 PM, Collin Jackson wrote: On Wed, May 19, 2010 at 4:57 PM, Adam Barth w...@adambarth.com wrote: Virtually none of the JavaScript framebusting scripts used by web sites are effective. Yes. If anyone would like to see more evidence of this, here's a recent study of the Alexa Top 500 web sites. None of them were framebusting correctly with JavaScript. http://w2spconf.com/2010/papers/p27.pdf This probably is not the right list for this but seems like the X-FRAME-OPTIONS http header could be strengthened by having the UA send all requests from pages that have the X-FRAME-OPTIONS to also containt either the X-FRAME-OPTIONS or another tag. One weakness pointed out in the paper is that proxies can strip the header. If the server doesn't see the header come back, it would know that it got stripped out and the request needs to be questioned. I don't know if there is a way to introduced fake http headers into requests or not. If there is, that would need to be addressed too. Perry
Re: [whatwg] WebSockets: what to do when there are too many open connections
On May 13, 2010, at 9:00 PM, Boris Zbarsky wrote: On 5/13/10 7:55 PM, Perry Smith wrote: Its not that hard and it won't happen that often. And it gives the javascript authors more control and choices. If a situation doesn't happen often, then historically speaking most authors will have no provisions to handle it. Try browsing the web with non-default colors set in your browser, with a default font size that's not 16px, or with a 13px minimum font size set. These aren't exactly hard things to deal with, but authors just don't deal with them. I sincerely doubt they'd deal with the possibility of a websocket not actually opening unless is was _very_ common. Maybe the spec should say that attempts to open a websocket should have a 50% chance of failing even if there's no good reason for it, just so it is in fact common for opening to fail? ;) (No, that's not a completely serious proposal, but it's not completely facetious either; it would take something like that for authors to handle failure properly.) That wasn't what I meant. it won't happen often I meant, the need to have a queueing mechanism written in Javascript. i.e. most applications of web sockets would want to just fail. The few that do not, can roll their own.
Re: [whatwg] WebSockets: what to do when there are too many open connections
On May 13, 2010, at 10:05 AM, Simon Pieters wrote: On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman micha...@google.com wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters sim...@opera.com wrote: establishing a WebSocket connection: [[ Note: There is no limit to the number of established WebSocket connections a user agent can have with a single remote host. Servers can refuse to connect users with an excessive number of connections, or disconnect resource-hogging users when suffering high load. ]] Still, it seems likely that user agents will want to have limits on the number of established WebSocket connections, whether to a single remote host or multiple remote hosts, in a single tab or overall. The question is what should be done when the user agent-defined limit of established connections has been reached and a page tries to open another WebSocket. I think just waiting for other WebSockets to close is not good. It just means that newly loaded pages don't work. Hosts have limits on open file descriptors but they are usually in the ten's of thousands (per process) on today's OSs. I don't think this is an area for the spec. The open must be allowed to fail if something goes wrong. The OS might reject it and the browser might reject it too. Aside from that, I don't think the spec should dictate what to do here. A nice UA, I think, would monitor a particular tab or browsing context for being out of control. This might be opening an infinite number of sockets or running infinite threads to bog the user's system down (or it might be because I forgot a semicolon :-). There are countless ways for nasty javascript to upset the user. A nice UA from a nice group would learn these new ways and adapt to them over time. When detected, the UA could ask the user if they want this mayhem to continue or not. I think rampant socket abuse is just one of countless places nasty javascript is going to exploit the user. I don't see how the spec can foresee all of them nor should a complaint UA be required to detect all of them. Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
Re: [whatwg] New File attributes creationDate, modificationDate and size
On May 11, 2010, at 3:43 AM, J Ross Nicoll wrote: Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file There doesn't appear to be anyway of retrieving creation date, modification date or size of the file. Could I suggest adding attributes creationDate, modificationDate and size to provide this information? For a use case; we're working an a student coursework submission system, where they'll be able to drag and drop files. It would be useful to show the student details of the file they're uploading (for example, modification date is useful to confirm they're uploading the most recent version). We do actually see a fairly large number of mis-uploads with the existing upload system, and are hoping exposing more information during the upload (rather than once the file is received) will help. I was just going to ask the same question. My use case is for a progress bar. As I parse a file, it would be nice to have a progress bar based upon the file size and how much has been parsed.
Re: [whatwg] Need document.available_fonts() call
On May 11, 2010, at 9:26 AM, Ashley Sheridan wrote: On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote: On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? E.g. allowing the user to select a font in a text editing or drawing application. However, for portability it would probably be better if these were limited to fonts already on the Web. I agree, portability dictates that they should stick to the few common fonts, or we end up with the same situation I've had countless times where someone sent an MSWord file with all the bullets as some character from the Wingdings font then wonder why people complain that all their bullets are letters. Embedding the font isn't feasible in this case because you really can't trust the end-user to observe the legal aspects of the fonts they have on their system. The designer of a font may not have given user rights to distribute the font in a document that is publically available like this. Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable. People, users, authors, etc learn over time. We are seeing with HTML5 and all of its capabilities a real working platform for almost anything. I'm sure there will be ten times as many beasts created from it as beauties but I don't see that as a reason to constrain the possibilities. pedz
Re: [whatwg] getElementById
On May 10, 2010, at 10:54 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 8:28 PM, Perry Smith pedz...@gmail.com wrote:
snip
So, how about this?
As part of HTMLElement, have a defined bucket, maybe call it elementObject
which is defined to be a native ECMAScript object. If X denotes a
particular DOM element, then X.elementObject is defined to return the same
native ECMAScript object each time. More details could be added perhaps to
define how the object is created (i.e. which prototype to use, etc). I'm
thinking making it the same as {}.
WebIDL could require DOM objects to be implemented as native ECMAScript
objects.
To me, the host objects and the fact that they are mostly unspecified seems
rather critical and limiting. The getUserData seems terribly awkward and I
guess it suffers from portability issues as well.
Is WebIDL the best place to address this?
Thanks,
pedz
Re: [whatwg] Need document.available_fonts() call
On May 11, 2010, at 3:59 PM, Tab Atkins Jr. wrote: On Tue, May 11, 2010 at 11:09 AM, Perry Smith pedz...@gmail.com wrote: Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable. Actually... some machines can display colors with rgb values outside of the [0,255] range. But CSS clamps you to that range because it's portable. True, CSS restricts the color space to sRGB. But CSS allows for 16 bit colors. That is more what I was referring to. The older machines can not display such subtleties so wise authors choose to confine their color choices but we are still allowed to pick the other colors. Drifting off the topic a bit, has anyone suggested introducing the Lab color space to CSS and HTML? It is a very nice for some applications. pedz
[whatwg] getElementById
I see places that explicitly state that the same object is returned on some
operations. For example, the element.style has that clause.
I have not found in either html5 or the DOM documentation that is referenced an
explicit statement to this effect for getElementById.
In FF 3.5, it seems to be true but it would be nice to know if it is or is not
something that can be depended upon.
The other part to this that is not explicitly mentioned is if I attach a new
javascript attribute to the object, is that legal? Is it defined to work? I
have not found a statement one way or the other.
e.g.
foo = getElementById('foo');
foo.newAttr = true;
/* later */
foo = getElementById('foo');
if (foo.newAttr) {
alert(happy happy joy joy);
}
Thank you,
Perry
Re: [whatwg] getElementById
On May 10, 2010, at 3:06 PM, timeless wrote:
On Mon, May 10, 2010 at 9:10 PM, Perry Smith pedz...@gmail.com wrote:
I see places that explicitly state that the same object is returned on some
operations. For example, the element.style has that clause.
I have not found in either html5 or the DOM documentation that is referenced
an explicit statement to this effect for getElementById.
if someone changes the id value on the node you used to think about
and assigns it to another node then it most certainly will not return
the same node.
Yea, that is an interesting point.
I wonder also if I change the id for the node to 'dog' and then do
getElementById('dog') if it will give me back the same javascript object with
newAttr set.
I am not sure if I am making myself clear. The question(s) boils down to, are
these objects going to behave consistently as javascript objects.
There are different ways the browser could implement the mapping from DOM
elements to javascript objects.
For example, the following code could fail and not give the alert box:
foo = getElementById('foo');
foo.newAttr = 1;
if (foo.newAttr)
alert(hi);
The setting of newAttr could simply not work at all. The browser could throw
it away. There is nothing I see that says that it must work. I say this
because there are particular methods and attributes defined. No mention is
made of other attributes. They could do anything including throw an exception,
silently fail, or randomly do something else.
I might have missed something obvious.
Perry
Re: [whatwg] getElementById
On May 10, 2010, at 7:04 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 4:55 PM, Perry Smith pedz...@gmail.com wrote:
On May 10, 2010, at 5:12 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 2:27 PM, Perry Smith pedz...@gmail.com wrote:
On May 10, 2010, at 3:06 PM, timeless wrote:
On Mon, May 10, 2010 at 9:10 PM, Perry Smith pedz...@gmail.com wrote:
I see places that explicitly state that the same object is returned on
some operations. For example, the element.style has that clause.
I have not found in either html5 or the DOM documentation that is
referenced an explicit statement to this effect for getElementById.
if someone changes the id value on the node you used to think about
and assigns it to another node then it most certainly will not return
the same node.
Yea, that is an interesting point.
I wonder also if I change the id for the node to 'dog' and then do
getElementById('dog') if it will give me back the same javascript object
with newAttr set.
Careful, it might actually not be a native ECMAScript object that you
get back. A host object could be implemented as a native ECMAScript
object, as seen in many implementations, but, as seen in recent
discussions, MSIE = 8 has host objects that are not native objects
and that do throw errors.
That is what I'm asking. I can't find where that is allowed (in the spec)
or not allowed in a conforming UA.
Any DOM object is a host object in ECMAScript parlance and host
objects have great liberty.
Look how IE's shoddy catchall implementation of the styleSheets dhtml
collection blows up on numeric [[Get]] access:
alert(document.styleSheets[9]); // Boom.
javascript: alert(document.styleSheets['a']); // OK
More indications on host objects in IE will show that they are not
native ECMAScript objects.
javascript: alert(document.body.valueOf); // undefined.
javascript: alert([].slice.call(document.childNodes)); // Boom.
I am not sure if I am making myself clear. The question(s) boils down to,
are these objects going to behave consistently as javascript objects.
There are different ways the browser could implement the mapping from DOM
elements to javascript objects.
For example, the following code could fail and not give the alert box:
foo = getElementById('foo');
foo.newAttr = 1;
if (foo.newAttr)
alert(hi);
The setting of newAttr could simply not work at all. The browser could
throw it away. There is nothing I see that says that it must work. I say
this because there are particular methods and attributes defined. No
mention is made of other attributes. They could do anything including
throw an exception, silently fail, or randomly do something else.
The code attempts to assign a property, not an attribute.
Setting a property such as newAttr is not specified. If it throws an
error or does nothing, it is your fault.
Ok. (Sorry for the incorrect use of terms.) If setting a property is not
specified, that means that a conforming UA can disallow setting properties.
Or it could silently ignore the attempt to set a property. Is that what was
intended?
Yes. An implementation can also throw errors with that. Nothing in
HTML 5 prevents that. Nothing in ECMAScript prevents that, for host
objects.
The browser can do whatever it wants with that property. Take a look
at MSIE document.expando.
Wow. I happened to pull down the ECMAScript 5 doc this past weekend to
understand exactly how an event handler is called. html5 refers to functions
defined in the ECMAScript doc. But I've never heard of host objects. The
first hit in the EMCAScript 5 doc for host object tells all. These guys did
not learn from the mistakes of Pascal. An utterly hopeless feeling came over
me.
So, how about this?
As part of HTMLElement, have a defined bucket, maybe call it elementObject
which is defined to be a native ECMAScript object. If X denotes a particular
DOM element, then X.elementObject is defined to return the same native
ECMAScript object each time. More details could be added perhaps to define how
the object is created (i.e. which prototype to use, etc). I'm thinking making
it the same as {}.
[whatwg] Security thoughts
In HTML5 6.3.1 Relaxing The Same Origin Restriction [1] bullet 3, sub bullet 3 there is a clause that says that if the domain is reduced down to something that is on the Public Suffix List, the new value is rejected. That phrase caused me to pause. I was wondering about internal attacks. First, we need to assume a couple of things but they are relatively easy to assume. The first is that the relaxing of the restriction has a valid use. This seems easy or it would not be in the spec. The second is that an internal domain can effectively be a public suffix list to users on the internal intranet. For example, at the place I work, I connect my laptop to the wifi, it grabs an address and also registers the name. Even if the name was not registered, it would still have some DNS entry. The point is that all DNS entries within this subdomain are not trusted. If we have a site like official_site.area_subdomain.big.com which relaxes the restriction to area_subdomain.big.com, it is now exposed to the potential of an attack from any of the systems within the same area_subdomain including laptops connected via wifi. The wifi is secure. The place I work at trusts me to some degree but with a large corporation, they very often try to restrict information on the need to know basis. And, corporate espionage is a real threat. I don't know how common it is for internal corporate sites to relax the same origin restriction but I could see it becoming more and more common as they try to take advantage of various technologies. The corporations could take steps of course to secure the sites. They could put all official web sites in their own subdomain and then relax to this more trusted subdomain. The purposed of this email is to ask if a warning should be added in the 3rd bullet to advise web developers of internal sites to be careful in assuming that all the hosts on their internal subdomain are trusted. Thanks, Perry [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#relaxing-the-same-origin-restriction
Re: [whatwg] onshow event
On May 6, 2010, at 3:19 AM, Anne van Kesteren wrote: On Wed, 05 May 2010 13:47:13 +0900, Ian Hickson i...@hixie.ch wrote: On Tue, 4 May 2010, Perry Smith wrote: It would be wonderful if an element had an event that would fire when that particular element is shown on the page. This might be due to the display attribute changing or it might be due to it scrolling into view. That's more of a presentation issue; I recommend raising this in the context of CSSOM. Anne, is there a bug database or issues list for CSSOM where things like this can be logged? No. I suppose new ideas could be added here (under CSSOM): http://wiki.whatwg.org/wiki/Companion_specifications Issues with the current specification I mostly track through email. I sent an email on the www-style list. Thanks, Perry
[whatwg] onshow event
I see in the html5 spec an 'onshow' event but no text describing when the 'show' event is triggered. I've poked at FF 3.5 and Opera and can not get it to fire. But I may be completely confused on when it should fire. It would be wonderful if an element had an event that would fire when that particular element is shown on the page. This might be due to the display attribute changing or it might be due to it scrolling into view. onshow appeared to be the closest match to this. The case I'm trying to do is write a dodad which needs to be initialized but if I call the initialization method while it is hidden, the height and width come back 0 and the code doesn't work. I could add a hook into the parent to call the init when the parent decides to show the element but it would be nicer if I didn't have to do that. It would be nice if the element knew it was time to initialize itself based upon it being shown on the page. Also, I can't temporarily change the elements display attribute because its display is not the one that is hiding it. It is actually hidden (initially) but two of its parents. It seems like this would be a fairly frequent desire. Perhaps there is already an idiom for this. Thank you, Perry
Re: [whatwg] HTMLCollection and HTMLAllCollection suggestion
On Apr 5, 2010, at 1:04 PM, David Flanagan wrote: Perry Smith wrote: On Apr 3, 2010, at 11:58 PM, David Flanagan wrote: Perry Smith wrote: HTMLCollection has a namedItem method that returns either null or one object. [1] HTMLAllCollection has a namedItem method that returns either null, one object, or a collection of objects. [2] I'm a Rails freak and one of the things that they do which I love is foo returns an item and foos returns a list of items. The unconscious benefit of this I believe is huge. My suggestion is to have namedItem always return either null or 1 object. And have namedItem*s* always return a collection. We can debate whether it is better to return null or an empty collection. I prefer the latter myself. Then I can always feed it to an iterator. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlcollection-0 [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlallcollection-0 Perry, But no one actually invokes namedItem()--they just use a regular property access expression on an HTMLAllCollection. namedItem() is left over from the strange days when the W3C was specifying Java APIs for working with XML instead of JavaScript APIs for HTML! Hmm. I was wondering. The pop up boxes on the side did not have any icons in them so I thought no one had implemented them. Can you give me an example of regular property access expression on an HTMLAllCollection ? I can't figure out what you are referring to. Thanks, Perry Perry, I think the only HTMLAllCollection is the deprecated document.all. By regular property access expression, I mean something like: document.all.foo or document.all[foo] instead of: document.all.namedItem(foo) I'm confused by the spec at this point. The title for section 13 is obsolete features but then 13.3 is Requirements and indeed 13.3.4 has features not yet implemented but considered deprecated by David (who I assume knows what he is talking about). I test a little bit in firefox and document.all doesn't work. So I look and see that Firefox is developing it. Is the HTMLAllCollection coming or going? Sorry for the confusion. Perry
Re: [whatwg] HTMLCollection and HTMLAllCollection suggestion
On Apr 6, 2010, at 12:24 PM, Boris Zbarsky wrote: On 4/6/10 12:17 PM, Perry Smith wrote: I'm confused by the spec at this point. The title for section 13 is obsolete features but then 13.3 is Requirements Right. Just because a feature is obsolete doesn't mean that UAs aren't required to implement it in a particular way. I test a little bit in firefox and document.all doesn't work. Sure it does: data:text/html,bodyscriptalert(document.all.length);/script Or were you testing in standards mode or something? Gack! probably. document.compatMode returns CSS1Compat so I'm in no- quirks-mode which is probably what you mean by standards mode. I'm then using Firebug to poke at things interactively from the console. Is the HTMLAllCollection coming or going? Neither. It's here; no one is planning to add new features to it, web pages are discouraged from using it. Ok... sorry if I've wasted peoples time. Perry
Re: [whatwg] HTMLCollection and HTMLAllCollection suggestion
On Apr 3, 2010, at 11:58 PM, David Flanagan wrote: Perry Smith wrote: HTMLCollection has a namedItem method that returns either null or one object. [1] HTMLAllCollection has a namedItem method that returns either null, one object, or a collection of objects. [2] I'm a Rails freak and one of the things that they do which I love is foo returns an item and foos returns a list of items. The unconscious benefit of this I believe is huge. My suggestion is to have namedItem always return either null or 1 object. And have namedItem*s* always return a collection. We can debate whether it is better to return null or an empty collection. I prefer the latter myself. Then I can always feed it to an iterator. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlcollection-0 [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlallcollection-0 Perry, But no one actually invokes namedItem()--they just use a regular property access expression on an HTMLAllCollection. namedItem() is left over from the strange days when the W3C was specifying Java APIs for working with XML instead of JavaScript APIs for HTML! Hmm. I was wondering. The pop up boxes on the side did not have any icons in them so I thought no one had implemented them. Can you give me an example of regular property access expression on an HTMLAllCollection ? I can't figure out what you are referring to. Thanks, Perry
[whatwg] Section 2.7.2.1 (HTMLCollection) question
From [1] The namedItem(key) method must return the first node in the collection that matches the following requirements: It is an a, applet, area, embed, form, frame, frameset, iframe, img, or object element with a name attribute equal to key, or, It is an element with an ID equal to key. Should equal be clarified? In particular, from 2.4.9, I got the idea that comparing names would be compatibility caseless at least in that instance. Is that also true here? I don't see the term valid hash-name reference in this section so I don't think I missed something but I easily could have. Also, off topic a little: should these questions be posted here or is it more productive to use the form on the page? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlcollection-0 Thank you, Perry
[whatwg] Web Apps as epub
Hi, Ian and I have been working trying to get the overall.html document as an epub format for ebook readers. I have got a version that appears to be working on my nook. I've put it here: http://aix-consulting.net/web_apps.epub If anyone has an ebook reader, please download it and let me know if you have any problems reading it. So far, its been working for me. The process is not yet 100% automatic but we hope to get that accomplished at some point so that it will be up kept up to date. Thanks, Perry
[whatwg] HTMLCollection and HTMLAllCollection suggestion
HTMLCollection has a namedItem method that returns either null or one object. [1] HTMLAllCollection has a namedItem method that returns either null, one object, or a collection of objects. [2] I'm a Rails freak and one of the things that they do which I love is foo returns an item and foos returns a list of items. The unconscious benefit of this I believe is huge. My suggestion is to have namedItem always return either null or 1 object. And have namedItems always return a collection. We can debate whether it is better to return null or an empty collection. I prefer the latter myself. Then I can always feed it to an iterator. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlcollection-0 [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlallcollection-0
Re: [whatwg] Video Tag Proposal
Isn't the concept of a submarine patent also possible against a patented algorithm? Perry
[whatwg] width and height
I'm trying to piece some things together. I end up with this idea: ele.style.height returns the used value if display is not set to none. By used value I assume the CSSOM spec means the actual value used. e.g. if the span takes up 100 pixels, it would return a value equivalent to 100px. But its not defined. I see a few old messages on this list about clientWidth and innerWidth and a reply that they were moved to CSSOM but there is nothing really defined in the copy of CSSOM I'm looking at. I also don't see a mailing list to discuss it so I thought I'd ask here. Thank you, Perry
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Mar 26, 2010, at 4:24 AM, Olli Pettay wrote: On 3/25/10 11:50 PM, Ian Hickson wrote: It seems that the consensus is now leaning towards changing the spec again to include the overhead, Well, what if the overhead isn't buffered? What if the implementation just buffers the bytes from send(), and writes the websocket protocol specific bytes to the socket when needed? And if bufferedAmount includes the overhead, it needs to be specified what bufferedAmount is during handshake. I'm a little confused. I sent out a rather long reply that no one replied to. Did it get put into everyone's spam bucket? There is no way that someone could even define the protocol overhead... what does that mean? There are layers of protocols. Perry
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Mar 25, 2010, at 4:50 PM, Ian Hickson wrote: It seems that the consensus is now leaning towards changing the spec again to include the overhead, but I haven't changed it yet because I don't want to be flip-flopping back and forth -- if we change this, I don't want to change it back. I think the use cases I know of are addressed whether we include overhead or not, so from an objective perspective I don't think it really matters, which makes this more of an opinion thing. I'd encourage anyone else with an opinion on this to make their opinion known. (Yes, I'm actually _asking_ for people to suggest colours for this bikeshed!) As an author, I'd rather not know about the overhead. To me it would be confusing to queue up 10 bytes and ask for bufferedAmount and get back 15. The sample scripts are doing one of two things. Either they are trying to prevent saturating the network and they are doing this by testing for bufferedAmount being equal to zero. Or, they are trying to saturate the network given the existing interfaces. I believe there are other options to allow the application to maintain an asynchronous interface and achieve saturation that would consume less cpu overhead. I'm not sure if we want to open that can of worms in this thread or not. pedz
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Mar 25, 2010, at 10:55 AM, Anne van Kesteren wrote: On Thu, 25 Mar 2010 16:35:19 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: On 3/25/10 4:25 PM, Niklas Beischer wrote: Easy. The bufferedAmount is: The amount of bytes waiting to be transferred, including protocol overhead. That doesn't define exactly what the bufferedAmount means and what kinds of values are expected. What I'd expect the API to tell me is, for example, that if I call ws.send(foo), and nothing is yet sent over the network, what is the exact value of bufferedAmount. Again, I'd really wish to keep the API to work reasonable similar way as XHR+progress events where protocol overhead isn't reported. Why? Progress events are completely different from this. This is about not saturating the network with too much data; it makes sense if the actual amount of data that is going to hit the network is known. (Yes, I changed my mind.) Hi, I'm going to wade in here but I may be way off base. I looked rather quickly at the doc on w3.com. Given that, here are my thoughts: I do kernel level networking support as my day job. Trying to get javascript to not saturate the network is not going to work. There are vast amounts of technology that govern how data flows in a network and a primitive javascript app is woefully under equipped. Even if Quality of Service is the objective, javascript would be a poor place to put your hopes. I like the idea of bufferedAmount but it could almost be arbitrary units -- just something that the app can determine Hey! I'm not making any progress or perhaps give the javascript a way to keep the users updated as to the progress. But making this into a way to not saturate the network is not going to work. Indeed, if the javascript wants to try to do some type of quality of service, then the only way for it to do that would be to send data, watch until bufferedAmount goes to zero, then pause for some length of time to un-saturate the network.. As soon as something is queued up (sent), everything below is trying its best to send it out as fast as possible. Watching bufferedAmount isn't going to change the lower levels of the network stack. So, again, the units could be arbitrary. If the script knows it sent N bytes, and it took X time, it knows how much bandwidth it is getting. If it wants to play nice, it can calculate how much time to pause based only on those two parameters. As far as adding in any protocol overhead, there is no way an application is going to know what that is unless you split the protocol stack at some point. I don't see why the application level would want to know anything about the lower level protocol. At the same time, if an implementation wants to add in some of the overhead that it sees, that is still going to give the application all the tools it needs to implement whatever it can. I would focus on words like monotonically decreasing after a send. And eventually ends up at zero. Those two things are what I'd like to be sure are true. Perry
Re: [whatwg] Spec formats
On Mar 23, 2010, at 1:11 AM, Ian Hickson wrote: On Mon, 22 Mar 2010, Perry Smith wrote: On Mar 22, 2010, at 7:00 PM, Ian Hickson wrote: If you would like to generate ePub or other formats of the spec, I would be happy to coordinate with you to set up a system that can do this on a regular basis for the spec, just like the PDF and multipage versions of the spec get regularly generated each day or with each update. I would like to help with this. I downloaded the source you pointed me to. Are the post processing tools available? The ePub generators all start with HTML. What the best way to do this is depends on what exactly the generators do. I hope you are patient with me. Its clear that I'm not up to speed on all the different versions and features of these specs or even how many specs there are. I think its best to think of ePub format as being similar to PDF or printed copy. The typical reader device does not have a mouse. It is possible to tab through links and press open to go, for example, from an entry in the table of contents to the entry itself. But the UI is very crude and the devices are very slow. To start, I'd like to do something pretty simple. Eventually, if plausible, it would be nice to have a way for the user pick which features he wants and have a custome html file downloaded to them which they can feed to their ePub generator. We can have pre-made ePub versions too which would be whatever options we decide to have. For me, there are two modes when I read one of these specifications. One is I am writing and debugging code (as an author in this case). In that mode, I am constantly opening new windows and doing all manner of searches to try and understand a particular part. An eBook is not going to work for this mode at all. The other mode is when I want to sit down under a shade tree and really read an entire section. That is the place where an eBook works. I think keeping this use in mind will help us determine what to keep and what to leave out. Do you need the files with or without the section numbering and cross-references, for example? Yes. I think we want cross-references. The generators understand HTML so they will auto number a ol. I'm not sure what the source has (yet) so as far as section numbering, I am not sure how to answer that question yet. I would assume we want the same as what the single page versions have. Do you want the JavaScript that does the reverse cross-referencing of dfn elements? These are super cool but I don't see how that would work in an eBook. I don't think they have the concept of a pop up window. For now, lets leave these out. How about the alternative style sheets for authors, and the UI to support them? I'm not 100% sure I know what you are referring to. I see a radio button for Hide UA text. Is that for authors? Also, which specs do you want to generate? The most useful spec to generate might be the complete.html file, since it's essentially a superset of all the others, but we might also want to just do the WHATWG HTML spec (i.e. HTML5), which would be shorter. Yes. Lets do the complete html file first. As I mentioned above, I'm hoping that we can allow users to customize it later on. I'm sure there will be users that want only the official or final version of the w3.com version of each spec(s). There will also need to be some style sheet tweaking because usually the readers are black and white. There are a number of style sheets involved in the current scheme, but we can probably come up with some set of overrides to make the ePub copy suitably black and white. On a slightly different topic, is there an official cover for this book (or these books)? Not currently, but I'm sure we can figure something out. What should it look like? A .png file. These can be simple like HTML 5 put into Photoshop and let it spit out a png file. I can do this as we work through this. I just wanted to ask to make sure. We might get some volunteers to create nifty book covers (hint hint). The way the multipage version is generated currently is that I have a script that generates an HTML file, and when it's ready, I do an HTTP request to a service Philip maintains. That service then processes the HTML file appropriately and sends back a tarball with the multipage version all ready to be expanded. If we can set up something similar, that would be awesome. Yes. I think I'm hoping for something a bit more eventually. I'd like eventually to offer a service where users and pick various features and get back either an html file, or maybe a final ePub file. The reason I'm leaning this way is because the readers seem so limited -- given the users exactly what they want seems more important in this format than in a web environment. If you'd like to coordinate this by IRC instead, which can
Re: [whatwg] Spec formats
On Mar 23, 2010, at 5:29 PM, Ian Hickson wrote: Ok. So basically we are looking for a version of the complete.html file with an override style sheet for blackwhite and no scripts? I haven't done the styles yet but how's this otherwise?: http://www.whatwg.org/specs/web-apps/current-work/epub.html If that's something you can work with, then we can work out a way where I can make my update scripts invoke some script on your side to generate the document every 24 hours or some such, like the PDFs. (Mail me privately to set this up off-list.) Between the last emails I worked on getting the w3.com single page version to at least load into Calibre. I discovered if I take out all the comments, it loads. My guess is that the state machine to find the comments is ever so slightly broken. It took me a few tries to get it right too. I then learned that ePub is basically a zip file of xhtml files but each file needs to be only about 260KB. If they are too big, the nook will simply die. Calibre tries to break up the output into files but it can't. I'm working on its options to try and teach hit how to break up the output into separate files. The file you produced I think is workable but I need to figure out how to get the ePub software to be happy with it. I'll let you know when I get something working. Perry
Re: [whatwg] Spec formats
On Mar 22, 2010, at 7:00 PM, Ian Hickson wrote: If you would like to generate ePub or other formats of the spec, I would be happy to coordinate with you to set up a system that can do this on a regular basis for the spec, just like the PDF and multipage versions of the spec get regularly generated each day or with each update. I would like to help with this. I downloaded the source you pointed me to. Are the post processing tools available? The ePub generators all start with HTML. But the various versions available all had one problem with them or another. I won't elaborate here. There will also need to be some style sheet tweaking because usually the readers are black and white. I'm am using Calibre at this point although I tried other ePub generators too. Calibre is a open source Python based tool that can generate ePub documents starting from html. It is like iTunes except for eBooks. My initial objective will be to produce a single page html version and stylesheets that Calibre will work with and produces something that looks decent on my eReader (I have a nook.) On a slightly different topic, is there an official cover for this book (or these books)? Thank you, Perry
[whatwg] Spec formats
Hi, I'm somewhat frustrated right now. I hope this email is not too caustic. The page at http://www.whatwg.org/specs/web-apps/current-work/ causes my Firefox to freeze for a minute or more. Eventually it recovers and it has all the pretty do-dads and things but it sure is painful to wait. And, this may be a Firefox problem but every time I hit a link, it freezes again as it recomputes (I guess) all the pretty do-dads and things. The pretty do-dads and things just are not worth it to me. Maybe there is something I can turn off but not until after the first wait period. Second, I downloaded the PDF (the html-letter.pdf) and various tools (like Acrobat reader) complain when I try to reflow the document. Third, if I save the page above to my disk and open it with dreamweaver and try to make it in to an xhtml document, it dies. The reason I'm trying to do that is some html to pdf converters insist upon xhtml format. My ultimate goal (which I have now determined is hopeless) is to put these documents on my nook so I can read them. Putting the html- letter pdf on my nook works but has many UI issues. I thought if I could redo the formatting somehow it might be nicer. Which leads to my final question or request. Can the original source of this, whatever it is stored in, be posted as well? There is a comment somewhere that says the W3 version and the whatwg version comes from the same source. It might allow energetic folks to offer other formats of the books such as in epub format or some other eReader style format. Thanks, Perry
