Re: [whatwg] use of article to markup comments
On 01/26/2013 05:30 AM, Bruce Lawson wrote: (It makes some sense, I suppose, to think of comments as a list, but *unordered*? If you're going to group them at all, wouldn't the order be important? Bruce Lawson ( http://lists.w3.org/Archives/Public/public-html/2013Jan/0111.html)'s observation that comments are heavily dependent on context would seem to support the idea that it *is* important, especially since some comments are responses to others.) agreed it would be better to use order lists. Wordpress blogs, for example, have comments like Bob Smith said at a href=#permalink9.55 on 31 Febtember/a: LOL Thus, every comment has a link that a UA can use to jump from comment to comment. The order is implied via the timestamp. So what's wrong with article h1Witty blogpost/h1 plorem ipsum section h235 erudite and well-reasoned comments/h2 divBob Smith said at a href=#permalink19.55 on 31 Febtember/a: Can I use DRM in Polyglot documents?/div divHixie said at a href=#permalink29.57 on 1 June/a: What's your use case?/div ... /section /article In short, why should the spec suggest any specific method of marking up comments? I think examples are useful for clearly illustrating the spec. An example in the spec shouldn't be construed as the only right way of doing things, of course. So, maybe a better question is why should the spec suggest only one specific method? -- Adrian Testa-Avila adr...@custom-anything.com http://www.custom-anything.com/contact follow on facebook http://www.facebook.com/customanything
Re: [whatwg] HTML5 web messaging - postMessage
http://jackiszhp.info/postMessage.html
The postMessage design outlined in the W3C document edited by Ian
Hickson is not good!
The design of the cross document messaging by Ian Hickson (Google,
Inc.) is very bad.
Even the last version is not good either. The design can be sketched
here as follows.
The sender:
var o = document.getElementsByTagName('iframe')[0];
o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
The receiver:
window.addEventListener('message', receiver, false);
function receiver(e) {
if (e.origin == 'http://example.com') {
if (e.data == 'Hello world') {
e.source.postMessage('Hello', e.origin);
} else {
alert(e.data);
}
}
}
This design was messed up by pulling origin (a word that some people
put too much attention more than should).
Even worse, it requires o.contentWindow, this is really no
professional sense. Because of this design, if I open two tabs with
the same url http://www.google.com/ they are not able to communicate.
My proposal is discard the o.contentWindow part requirement.
My better proposal
the sender:
window.postMessage(messageObject,targetDomain optional,windowIDs optional);
Either targetDomain or windowIDs should present.
I propose to use ID rather than name (though window can have a name),
since window.name is not required to be unique within the browser.
then the user agent(i.e. the browser, such as firefox) will do the following
var e={source: {href: get the sender's window.location.href,
windowID: unique windowID within this browser
},
target: {domain: targetDomain as the sender requested,
windows: the array of windowID
},
data: JSON.parse(JSON.stringtify(messageObject)),
ts: the timestamp when the post is requested
};
if(windowIDs presents){
postEvent to those windows.
} else {
traverse the list of all windows
for (each window){
if(the domain of the window matches the target domain of the message) {
postEvent(e);
}
}
the receiver
/*
return true to indicate to continue to receive message from this sender
return false to indicate to deny messages from this sender forever
(as long as the browser can remember this)
*/
function receiver(e) {
if (e.source is accepted) {
take the e.data to do whatever as desired.
return true;
}
return false;
}
window.addEventListener('message', receiver, false);
if the receiver wants to respond to the sender
window.postMessage(messageObject,targetDomain optional,windowIDs optional);
targetDomain can be found from e.source.href
windowID can be found from e.source.windowID
messageObject is the message object intended to be sent.
About domain match
the specification of the target domain can be
www.google.com
or google.com this should match *.google.com
or com this should match *.com
or as for all
or https://www.google.com
or http://www.google.com:9876/abc/
For the last case, if a
window.location.href==http://www.google.com:9876/def/;, then they do
not match.
About Security
As long as the receiver check who is the sender which is identified by
the user agent, there is no security issue at all.
About context sharing within the browser
Whether session data should be shared among the different processes of
the same browser. such as cookies. It seems that firefox does not
allow 2 different processes unless use different profile.
Here, one more setting, whether the windowIDs should be unique across
different process. Within the same process among different tabs, they
must be unique. If no more than one process is allowed, then such
setting is not relevant.
Challenge
A bad design waste people's energy time, to promote the better
solution. I am offering a reward for the 1st one who implement my
proposal. If you can do this before march 1st, 2013, I will give you
$10.
jackis...@gmail.com
pdf version
Last update: 2013.01.27 21:30
Re: [whatwg] HTML5 web messaging - postMessage
Please choose a list to send mail to, rather than spamming multiple lists, or else the thread will become fragmented as people choose one or the other list. On Sun, Jan 27, 2013 at 9:03 PM, Jack (Zhan, Hua Ping) jackis...@gmail.comwrote: This design was messed up by pulling origin (a word that some people put too much attention more than should). Even worse, it requires o.contentWindow, this is really no professional sense. Because of this design, if I open two tabs with the same url http://www.google.com/ they are not able to communicate. You want shared workers for that, not Web Messaging. http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#shared-workers-introduction -- Glenn Maynard
Re: [whatwg] Proposal: HTMLCanvasElement.printCallback API
1) I feel like this should probably be an event. I don't know why we're
inventing new callback facilities everywhere.
canvas.onprintcanvas = function(e) { e.printState ... }
2) What does send the canvas' content without rasterization to the
printer mean? How are blending and overlapping images handled? Your
current description makes it sound like if I did two drawImage() calls it
would make my printer print the images on top of each other.
3) If we're advocating that developers put a canvas on every page that
covers the whole page as the standard way to handle large document
printing why not have a handler that gets given a canvas for every page
automatically instead of requiring the developer to insert it themselves.
This seems much easier, and handles the memory management for since we can
drop the backing buffer between events for each page.
document.onprintpage = function(e) {
e.index // number of the page
e.range // range that encompasses all the nodes to print
e.canvas // canvas to send drawing commands to for printing
};
4) SVG is for vector graphics, not canvas. Why can't I replace an entire
page with an svg instead of drawing to a canvas? :)
- E
On Wed, Jan 23, 2013 at 3:11 PM, Julian Viereck
julian.vier...@googlemail.com wrote:
Discussing the proposal with Robert roc O'Callahan, we came up with the
following adjustments. They are targeting the Some more details on the
behavior of the API from before:
(1) With the previous proposal, printCallbacks are executed even after the
window is unloaded. We think this is not a good idea. There shouldn't be
any JavaScript execution after a window is unloaded. Therefore let's add
the following:
Encourage the UA to prevent closing the window while print callbacks
are pending. If the window is nevertheless closed and while some
printCallbacks have not completed yet, all printCallbacks are canceled, the
JavaScript execution is stopped and the print job is aborted. Canceling the
printCallbacks is done to prevent any JavaScript execution after the window
is unloaded.
(2) Given the change in (1), we can now change the following point:
* the canvas property on the printContext points to the canvas on the
page and not the canvas element that is printed. Otherwise it's possible to
change the layout of the printing while printing. As the canvas on the page
might not be available anymore (e.g. the canvas was removed and garbage
collected from the document before the printCallback gets invoked), the
canvas property might be undefined or null.
to:
* the canvas property on the printContext points to the canvas on the
page and not the canvas element that is printed. Otherwise it's possible to
change the layout of the printing while printing.
Simply saying, if the window object is always alive while the
printCallbacks are happening (thanks to (1)), the canvas property on the
printContext can always point to the canvas on the page.
Best regards,
Julian
On 9/26/12 2:46 PM, Julian Viereck wrote:
Hello WHATWG members,
This email is about proposing a new attribute printCallback on the
HTMLCanvasElement (in the following called Canvas). This new API allows
to:
* define the content of a canvas element during the printing progress
* send the canvas' content without rasterization to the printer
The basic API was implemented in [1] and is available in Firefox Nightly
18.
## Motivation And Use-Case
The motivation for designing and implementing the API was to add proper
printing support for the PDF.JS project. The PDF.JS project is an
implementation of aPDF viewer using only web technologies. Without this API
it is not possible to:
* render only the pages needed for printing. A webpage is printed with
the content visible at the moment the print action is started. For PDF.JS
this means that all pages are required to be rendered before printing.
Rendering all the pages takes quite some time for complex and huge
documents ( 100 pages). But the user might only want to print the first
page. That means, the user waits for unnecessary computation to finish.
* print the content of a canvas element without rasterization artifacts
on the printout. One could increase the size of the canvas such that the
rasterization doesn't becomes visible, but this is not possible due to the
large usage of memory going with this. Using a different way to render the
pages than using canvas (e.g. SVG) is not possible, due to memory and
performance issues.
Although not directly relevant to PDF.JS - it's also not possible to
* define the content of a printed page that looks exactly the same cross
all user agents. There are small variations, that cause breaks and styles
to look slightly different between user agents. Using CSS it's possible to
make one canvas element take up one physical page and then precisely layout
contenton the canvas.
(I will later describe briefly how the API was used to solve these
