Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Mon, Mar 15, 2010 at 3:05 AM, Maciej Stachowiak m...@apple.com wrote: === Summary of Data === 1) In all browsers tested, copying to an ImageData and then back to a canvas (two blits) is faster than a 2x scale. 2) In all browsers tested, twice the cost of a canvas-to-canvas blit is considerably less than the cost of copy to and back from ImageData. 3) In all browsers tested, twice the cost of a canvas-to-canas blit is still less than the cost of a single 0.5x scale or a rotate. With hardware acceleration in play, things seem to change a lot there, though it may be that it's just breaking the test somehow? The displayed images look correct, FWIW. My results on a Windows 7 machine, with the browsers maximized on a 1600x1200 display. FF 3.6: direct copy: 8ms indirect: 408ms 2x scale: 1344ms 0.5x scale: 85ms rotate: 440ms FF 3.7a (no D2D): direct copy: 12.5ms indirect: 101ms 2x scale: 532ms 0.5x scale: 33ms rotate: 389ms FF 3.7a (D2D): direct copy: 0.5ms indirect: 136ms 2x scale: 0.5ms 0.5x scale: 0.5ms rotate: 0.5ms WebKit r56194: direct copy: 18.5ms indirect copy: 113ms 2x scale: 670ms 0.5x scale: 112ms rotate: 129ms This supports the idea of specialized API, perhaps, since it will keep authors from having to figure out which path to take in order to avoid a massive hit when using the canvas copies (100x or more for D2D-enabled FF, if the test's results are correct). It also probably indicates that everyone is going to get a lot faster in the next while, so performance tradeoffs should perhaps not be baked too deeply into the premises for these APIs. Other more complex tests like blurring or desaturating or doing edge detection, etc. may show other tradeoffs, and I think we're working on a performance suite for tracking our own work that may illuminate some of those. Subject, of course, to the incredibly fluid nature of all browser performance analysis these days! Mike
[whatwg] Input search reset event
Hi, On webkit based browser, we can see a little cross used to reset the field, it's usefull, but in some ajax based application, it could be usefull to be able to handle this event, to dispatch the event to any controller and reset results. Use case : Highlight a given text in webpage. Input search is likely to be used since the highlight functionnality will search through the webpage and highlight all matched patterns. In a server side solution, the problem is likely to be inexistant, but if we use a plain _javascript_ option, it'll be usefull to handle the reset event to remove the highlighting from the page in browser impletementing this functionnality. What are your thoughts about this ?
Re: [whatwg] Parsing processing instructions in HTML syntax: 10.2.4.44 Bogus comment state
On Thu, 18 Mar 2010, Brett Zamir wrote: On 3/2/2010 6:54 PM, Ian Hickson wrote: On Tue, 2 Mar 2010, Elliotte Rusty Harold wrote: The handling of processing instructions in the XHTML syntax seems reasonably well-defined; but it feels a little off in the HTML syntax. There's no such thing as processing instructions in text/html. There was such a thing in HTML4, because of its SGML heritage, though it was explicitly deprecated. Doesn't seem deprecated per http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.6 Section B.3.3 says, speaking of SGML features with limited support, which at the time of that section's writing included PIs, that We recommend that authors avoid using all of these features. Section 3.2 specifically says The appendix lists some SGML features that are not widely supported by HTML tools and user agents and should be avoided. Briefly it seems that? causes the parser to go into Bogus comment state, which is fair enough. (I wouldn't really recommend that anyone use processing instructions in HTML syntax anyway.) However the parser comes out of that state at the first. Because processing instructions can contain and terminate only at the two character sequence ? this could cause PI processing to terminate early and leave a lot more error handling and a confused parser state in the text yet to come. In HTML4, PIs ended at the first, not at ?. ?target data is the syntax of PIs when the SGML options used by HTML4 are applied. In any case, the parser in HTML5 is based on what browsers do, which is also to terminate at the first. It's unlikely that we can change that, given backwards-compatibility needs. There's a simple workaround: don't use PIs in text/html, since they don't exist in HTML5 at all, and don't send XML as text/html, since XML and HTML have different syntaxes and aren't compatible. In http://dev.w3.org/html5/html4-differences/ , it says: HTML5 defines an HTML syntax that is compatible with HTML4 and XHTML1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML4, such as processing instructions http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.3.6 and shorthand markup http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.3.7. This seems to me to suggest that backward compatibility can be broken as far as processing instructions (i.e., requiring ? and not merely to close a processing instruction). Backwards compatibility with legacy content can only be broken in extreme cases (e.g. for security reasons). That's one of the fundamental design goals of HTML5. If not, then it doesn't seem clear from the specification that processing instructions are indeed not allowed because the parsing model does allow them, and with processing instructions being platform-specific by definition and not apparently explicitly prohibited by HTML5 (unless that is what you are trying to say here), HTML5 syntax does seem to be compatible with them. HTML5 prohibits PIs in text/html. See: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#writing ...and notice how PIs are not listed as a possible syntax element. But if you are trying to prohibit them for any use whatsoever yet still technically allow them to be ignored for compatibility, it seems this would contradict the statement at http://dev.w3.org/html5/html4-differences/ that there is no longer a need for marking features deprecated. Or is the difference that these are forbidden from doing anything but will be allowed (and ignored) indefinitely into the future in future versions of HTML? They are forbidden but are ignored in this (and probably future) version(s) of HTML. Btw, I've added a talk section at the wiki page http://wiki.whatwg.org/wiki/Talk:HTML_vs._XHTML#Harmony to suggest covering XHTML-HTML compatibility guidelines specifically, so would appreciate a reply there, so I know whether we can begin edits in this vein on the page. Please feel free to edit the wiki or add new pages! Everyone is welcome to edit the wiki. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] EventSource remark
On Fri, 19 Mar 2010, Anselm R Garbe wrote: I came across this one today: http://dev.w3.org/html5/eventsource/ In section 8 the following is said [..] Authors are also cautioned that HTTP chunking can have unexpected negative effects on the reliability of this protocol. Where possible, chunking should be disabled for serving event streams unless the rate of messages is high enough for this not to matter. [..] Is there any evidence for this? I'm curios to get some insight ;) It's not really chunking that's the problem specifically, it's the caching that servers who support chunking often perform. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec formats
On Sat, 20 Mar 2010, Perry Smith wrote: Can the original source of this, whatever it is stored in, be posted as well? The source file used to generate the various specs described here: http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F ...is the following very large (4MB) HTML fragment: http://www.whatwg.org/specs/web-apps/current-work/source It requires extensive postprocessing to generate the various aforementioned documents. If you need any help with that, please don't hesitate to contact me. 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. If you just need a smaller version of the spec, http://whatwg.org/html may be what you want. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Real-time networking in web applications and games
Hi all, I am currently engaged by InstantAction to develop a minimum-footprint web API prototype plugin for real-time networked games. The purpose of this work is to propose to this standards process a path for real-time networked client/server and peer-to-peer games and applications to live as first-class citizens in the browser app sandbox. This work has involved separating the lightweight UDP-based connection protocol from IA's Torque game technologies into a standalone C API (torque_sockets), and the first drafting of the TorqueSocket interface, patterned after the WebSocket interface from Google. Where WebSocket allows for a persistent TCP connection to a remote host, TorqueSocket enables in its essence connected UDP connections to a remote host as well as peer-introduced connections. The first draft of the TorqueSocket specification can be found here: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt , which includes the high level requirements, a proposed API spec and some details on the connection handshake and wire protocol. The torque_sockets C API definition can be found here: http://github.com/nardo/torque_sockets/raw/master/torque_sockets_reference_api.h I was pointed in the spec to http://www.whatwg.org/specs/web-apps/current-work/complete.html#devices and also noticed section 4.11.6.2 Peer-to-peer connections -- both look like they are works-in-progress. Is anyone actively working on this functionality in the HTML5 spec? Any feedback about TorqueSocket and the approach would be welcome. Regards, Mark
[whatwg] Real-time networking in web applications and games
Hi all, I am currently engaged by InstantAction to develop a minimum-footprint web API prototype plugin for real-time networked games. The purpose of this work is to propose to this standards process a path for real-time networked client/server and peer-to-peer games and applications to live as first-class citizens in the browser app sandbox. This work has involved separating the lightweight UDP-based connection protocol from IA's Torque game technologies into a standalone C API (torque_sockets), and the first drafting of the TorqueSocket interface, patterned after the WebSocket interface from Google. Where WebSocket allows for a persistent TCP connection to a remote host, TorqueSocket enables in its essence connected UDP connections to a remote host as well as peer-introduced connections. The first draft of the TorqueSocket specification can be found here: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt , which includes the high level requirements, a proposed API spec and some details on the connection handshake and wire protocol. The torque_sockets C API definition can be found here: http://github.com/nardo/torque_sockets/raw/master/torque_sockets_reference_api.h I was pointed in the spec to http://www.whatwg.org/specs/web-apps/current-work/complete.html#devices and also noticed section 4.11.6.2 Peer-to-peer connections -- both look like they are works-in-progress. Is anyone actively working on this functionality in the HTML5 spec? Any feedback about TorqueSocket and the approach would be welcome. Regards, Mark
Re: [whatwg] window.print() when printing is not supported
On Mon, 28 Dec 2009, Olli Pettay wrote:
currently
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#printing
says that window.print() should prompt user to print the page, but that
For instance, a kiosk browser could silently ignore any invocations of
the print() method.
A print button in web pages is quite common, and if pressing that
doesn't give any feedback (and the web page can't even detect if it
should give some feedback of missing printing), the user experience
isn't quite optimal.
So I think it *might* make sense to throw some error if printing isn't
supported.
That is a conforming implementation of the first step of the printing
steps (The user agent may display a message to the user and/or may abort
these steps).
Or should browsers which don't support window.print() just not have
print() method in the window object? (problem is that I'd guess everyone
just expects .print() to be there)
All browsers are required to have the method.
On Mon, 28 Dec 2009, Markus Ernst wrote:
I'd rather suggest to mark the print() method as deprecated, encouraging
authors to use modern printer-friendly authoring techniques. Also,
browser vendors could be encouraged to offer a setting to disallow
scripts to hide the main menu, or the toolbar that contains the print
button.
On Mon, 28 Dec 2009, Tab Atkins Jr. wrote:
I've had design requirements to include a print button in pages.
Apparently many users *expect* such, and don't realize they can print
from the File-Print option (and/or don't realize that this can print a
printer-friendly version automatically).
I include print stylesheets, so all this button ever does is call
window.print() for them.
On Mon, 28 Dec 2009, Aryeh Gregor wrote:
Wikipedia is the same deal. We've supported print stylesheets for ages,
so there's absolutely no difference (at least in theory) between
printing a page, and clicking Printable version on the sidebar and
then printing the page. But some users apparently expect a print link
of some type on the web page itself.
I've left window.print() as conforming, based on the above feedback.
On Mon, 28 Dec 2009, Michael A. Puls II wrote:
As for window.print(), what if it returns false if printing is not
supported? Then, authors that want to can use that and provide info *if*
the want to. Or, it could throw a not supported exception and one can
catch it and do something. Those sound better than just ignoring the
print() call.
What could a Web page do that a browser couldn't do better in the same
situation? (The browser could offer a PDF, so having the site offer a PDF
when there's no printer doesn't seem like a good solution.)
On Mon, 28 Dec 2009, Michael A. Puls II wrote:
Since making print() return something isn't going to help with older UAs
and returning true would feel backwards, instead of:
if (window.print()) {
alert(Printing is not supported);
}
, we could do this:
if (typeof navigator.printingEnabled === function
!navigator.printingEnabled()) {
alert(Printing is not supported);
} else {
window.print();
}
It's more verbose though and I'm not sure any will like it. But, tossing
it out there.
If all it's going to do is alert Printing is not supported, then the
current spec text (which allows the UA to alert such) seems better, since
then it only has to be implemented once per UA rather than once per site.
On Tue, 29 Dec 2009, Olli Pettay wrote:
Yeah, navigator.isPrintingEnabled or some such could be also useful.
To do what?
On Mon, 28 Dec 2009, Kornel Lesinski wrote:
Why would page need to know if printing works? What (useful) thing could
it do if it detects failed print?
If all you want is to display error when printing fails, that's a UA
issue. Why burden all sites with handling of error they can't fix? UA
can signal the error, and can do it better, e.g. offer option to
configure a printer.
Indeed.
I'm afraid that even letting pages know whether printing is available
might have negative consequences.
I can't print anything from computer I'm using at the moment, BUT if I
need to print something, I can save page/document and print it from
another computer. If pages could detect that my computer can't print,
they could wrongly assume I can't print anything at all, and hide
print-related options from me. I'd hate if ticket sites automatically
decided to snail-mail me tickets without offering option to print them
myself.
Also a good point.
I haven't made any changes to the spec in response to the above, because
it's not clear what change would benefit users. The spec already allows
UAs to basically do whatever they want in response to window.print().
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer.
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
