Re: [whatwg] [html5] window.print() undefined
On Mon, 18 Jul 2005, Dimitri Glazkov wrote: What do you guys think about this -- and this is just theoresizing and hypothizing :) Print representation, if defined, should probably not be viewed as the byproduct of the screen presentation. For instance, if script modified DOM properties in the screen presentation, these changes should not affect the print presentation, and vise versa. How is this accomplished? I've been thinking about DOM sandboxing idea lately, and it seems interesting, but I haven't have time to cook up anything delicious quite yet. So, here's the half-baked version: DOM Sanboxing Markup is serialized content that comes over the wire. DOM is an object representation of markup. This representation can be (and routinely is in Web apps) modified to something else. This would've been perfectly hunky-dory if the modifier of the DOM was the only player in the game. However, with the advent of the GreaseMonkey era, the rules a-changing. Now, instead of one UA, you have multiple UAs (let's call them UA-plets) of various degrees of completeness and importance, custom to each client, all operating inside of one big UA called the modern Web browser. This has certain unexpected and hard-to-regulate effects. How do you make sure that the semantics of DOM tree have not been messed with, so that a UA-plet that relies on semantics could still get its turn at the original markup? So, here's proposition minimus: store the original DOM tree and make it always accessible, regardless of what the final DOM tree will look like. It is, after all, the purest representation of data. The original DOM tree is read-only and can not be altered. Now, a proposition maxiumus: allow access to the original DOM tree AND provide facilities to create a mutable snapshot of it. This way, the UA-plets can have the cake and eat it, too: they can view DOM representation of the original markup, and also tweak it as they see necessary. This implies, of course, that printing is a UA-plet: it simply gets the original markup and either simply applies stylesheets to it or tweaks it as necessary, then sends it off to the printer. In effect, this allows the overarching UA environment (the browser) to sandbox DOM manipulation for specific purposes of each UA-plet, be that rendering for viewing, printing, or hCalendar data harvesting. Whaddayathink? This sounds overly complicated, and quite similar to what XBL2 allows. I'm not sure it's something we would want in HTML5, though. In particular I'm not really sure what problem we're trying to solve here -- that printing is inconsistent when GreaseMonkey scripts are involved isn't really a high-priority problem as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
On Mon, 18 Jul 2005, Olav Junker Kjær wrote: I dont think you should set element.style.display to block, if the element should be visible only on screen and not in print. It would be better to dynamically assign it a class which is defined in the stylesheet to be visible on screen and not in print. (Its a bit tricky to add and remove class names, but still cleaner than using print events.) It should now be easy, with our new 'classList' DOM attribute. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
Ian Hickson wrote: On Tue, 19 Jul 2005, Dean Edwards wrote: The point is, I can do all sorts of things using script. Alter styles, create elements etc. But when I switch media, I have no programmatic way to alter those effects. Please specify I means to do this. You don't switch media. It's quite possible to have multiple media all at the same time. For instance Opera can be in speech mode and in screen mode simultaneously. See the introduction to the Browsing Context section: http://whatwg.org/specs/web-apps/current-work/#browsing I'm getting fed up going round in circles trying to justify this. OK, we don't switch media. But when I press print or invoke the print method, a copy of the DOM is sent to the printer. If I have altered the DOM by adding elements or by changing the style property then I would like to be able to undo those changes before my DOM goes to the printer. It is not good enough to say that I should start messing about with classes and so forth or that it is bad practice to amend the style property directly. So long as I can do these things I want a way to undo them before my DOM is sent to a print device. -dean
Re: [whatwg] [html5] window.print() undefined
Dean Edwards wrote: OK, we don't switch media. But when I press print or invoke the print method, a copy of the DOM is sent to the printer. If I have altered the DOM by adding elements or by changing the style property then I would like to be able to undo those changes before my DOM goes to the printer. It is not good enough to say that I should start messing about with classes and so forth or that it is bad practice to amend the style property directly. So long as I can do these things I want a way to undo them before my DOM is sent to a print device. I know this isn't how you meant it, but this all seems a bit user hostile. The user sees something on the screen he/she wants to print, but an event is called at the last minute that changes the content to something else before the user can print. So if I select the part of the page you want to undo and tried to print the selection, I'd get a blank page? And in theory, the entire page could be hidden. Sounds like print-specific DRM to me. Perhaps what you really want is a media-specific way of setting styling properties: | element.style.media(print).display = block;
Re: [whatwg] [html5] window.print() undefined
Matthew Raymond wrote: Dean Edwards wrote: OK, we don't switch media. But when I press print or invoke the print method, a copy of the DOM is sent to the printer. If I have altered the DOM by adding elements or by changing the style property then I would like to be able to undo those changes before my DOM goes to the printer. It is not good enough to say that I should start messing about with classes and so forth or that it is bad practice to amend the style property directly. So long as I can do these things I want a way to undo them before my DOM is sent to a print device. I know this isn't how you meant it, but this all seems a bit user hostile. The user sees something on the screen he/she wants to print, but an event is called at the last minute that changes the content to something else before the user can print. So if I select the part of the page you want to undo and tried to print the selection, I'd get a blank page? And in theory, the entire page could be hidden. Sounds like print-specific DRM to me. You can do that with css anyway, what is your point? Every browser feature adds opportunities to both help and annoy the user, but please let is be up to de web developer to act responsible with the features he has available. Who wants to annoy the customer anyway? -- Sjoerd Visscher http://w3future.com/weblog/
Re: [whatwg] [html5] window.print() undefined
Kornel Lesinski wrote: style attribute is supposed to have cascade value like ID selector. No, style attributes override everything. See http://www.w3.org/TR/CSS21/cascade.html#specificity smime.p7s Description: S/MIME Cryptographic Signature
Re: [whatwg] [html5] window.print() undefined
Matthew Raymond wrote:
I know this isn't how you meant it, but this all seems a bit user
hostile. The user sees something on the screen he/she wants to print,
but an event is called at the last minute that changes the content to
something else
You can already do that with CSS...
@media print { html { display:none; } }
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [whatwg] [html5] window.print() undefined
Sjoerd Visscher wrote: Matthew Raymond wrote: I know this isn't how you meant it, but this all seems a bit user hostile. The user sees something on the screen he/she wants to print, but an event is called at the last minute that changes the content to something else before the user can print. So if I select the part of the page you want to undo and tried to print the selection, I'd get a blank page? And in theory, the entire page could be hidden. Sounds like print-specific DRM to me. You can do that with css anyway, what is your point? That CSS can be overridden by the user stylesheet? Every browser feature adds opportunities to both help and annoy the user, but please let is be up to [the] web developer to act responsible with the features he has available. Who wants to annoy the customer anyway? Businesses annoy customers all the time, but that's beside the point. If all HTML content is semantic rather than presentational, what is the purpose of not displaying it in a specific media? We're not talking about media-specific presentation (since CSS+XBL handles that nicely). We're talking about media-specific content. The only reason I can think of for such control is if you're using the web app like a word processor or something and you want to print the document but not the UI. In that situation, it may be better to simply allow the web developer to copy the document contents into a separate document object, then manipulate and print the content from that document separately. This allows the same effect as the before and after print events without tampering with the browser's normal print mechanism. You just clone the document, modify the clone at will, print it and destroy it. The web app should never hijack the behavior of a common browser function.
Re: [whatwg] [html5] window.print() undefined
Quoting Matthew Raymond [EMAIL PROTECTED]: You can do that with css anyway, what is your point? That CSS can be overridden by the user stylesheet? Userbase: 2. (Both are geek.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] window.print() undefined
On Tue, 19 Jul 2005, Dimitri Glazkov wrote:
No, I don't believe that is always the case. The user _sometimes_ wants
to print what he/she sees, but my experience tells me that most of the
time, the user wants to print what is considered main content of the
page. For example, I am using my online banking, and want to print an
invoice. Do I want to print the navigation and all contextual content
that surrounds my invoice on the Web page? Of course not.
@media {
navigation { display: none; }
}
Now, the second question is whether @media print is enough to provide
all functionality needed for getting this done. I tend to think no.
Why? Because just CSS (in its current state) is not enough to provide
all functionality associated with rendering of the page. How is print
rendering different?
What functionality are you lacking? (Both in screen and print.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
On 7/19/05, Ian Hickson [EMAIL PROTECTED] wrote:
@media {
navigation { display: none; }
}
Ok, at least we all agree that it's not what the user sees :)
What functionality are you lacking? (Both in screen and print.)
Like, adding contextual content for print. Just like your main content
is not the only thing on the page, same may hold true for the print.
I think this discussion is about to turn into debunking of specific
application requirements and approaches, but I'll bite:
a) my invoice format requires a timestamp that says something like
this: printed by [person] on [timestamp].
b) To capture the essence of the browsing session, I would like to
build a breadcrumb at the bottom of the printed page, displaying
titles and urls of pages the user have visited on the site during this
visit.
:DG
Re: [whatwg] [html5] window.print() undefined
Ian Hickson wrote:
What functionality are you lacking? (Both in screen and print.)
Suppose I want to add inprint links' full urls in parenteses after
links' text. In CSS I can do;
a[href]:after {
content: attr(href);
}
But it's not enough since href may contain unresolved URL and I want
them full.
Re: [whatwg] [html5] window.print() undefined
Dimitri Glazkov wrote: On 7/19/05, Ian Hickson [EMAIL PROTECTED] wrote: What functionality are you lacking? (Both in screen and print.) Like, adding contextual content for print. Just like your main content is not the only thing on the page, same may hold true for the print. I think this discussion is about to turn into debunking of specific application requirements and approaches, but I'll bite: a) my invoice format requires a timestamp that says something like this: printed by [person] on [timestamp]. b) To capture the essence of the browsing session, I would like to build a breadcrumb at the bottom of the printed page, displaying titles and urls of pages the user have visited on the site during this visit. :DG I'll add another case: the onafterprint event could be used in a "wizard"-style application where printing some document is step 3 of 10, for example. The application could proceed to the next step (not necessarily a different document) automatically without requiring a button that says "click here when done printing". That's a case that a media-specific stylesheet cannot handle. Automating tasks and reducing clicks are both high priorities in my development of web applications. If the ability to set printer settings such as portrait/landscape is available, an "onbeforeprint" event could be used to prompt the user whether they'd like to automatically switch their paper orientation to portrait or landscape before printing. (The same can be said for margins and headers/footers.) This can be done in the print dialog, but if it is truly important to how the page prints, a separate step that highlights the importance of the print setting to the user would be helpful in reducing calls to my company's tech support line. Greg
Re: [whatwg] [html5] window.print() undefined
On Tue, 19 Jul 2005, Dimitri Glazkov wrote:
a) my invoice format requires a timestamp that says something like this:
printed by [person] on [timestamp].
This use case is being dealt with in the CSS paged media and CSS generated
content specifications.
b) To capture the essence of the browsing session, I would like to build
a breadcrumb at the bottom of the printed page, displaying titles and
urls of pages the user have visited on the site during this visit.
That seems like something that would be useful regardless of the medium.
Put it in the content, and then hide it in the media you don't want it
visible for, e.g.:
@media screen {
footer .breadcrumbs { display: none; }
}
I agree that your use cases are real, don't get me wrong. I just don't
think that it makes sense to consider them as being something you would do
upon entering a print mode.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
On Tue, 19 Jul 2005, Maniac wrote:
Suppose I want to add inprint links' full urls in parenteses after
links' text. In CSS I can do;
a[href]:after {
content: attr(href);
}
But it's not enough since href may contain unresolved URL and I want
them full.
That's a use case for a new feature in CSS, not in HTML. :-)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
Ian Hickson wrote: That's a use case for a new feature in CSS, not in HTML. :-) It is solvable with events discussed. My point is that authors traditionally use scripting to solve things that can't be solved with other means. It's normal.
Re: [whatwg] [html5] window.print() undefined
On 7/19/05, Ian Hickson [EMAIL PROTECTED] wrote:
b) To capture the essence of the browsing session, I would like to build
a breadcrumb at the bottom of the printed page, displaying titles and
urls of pages the user have visited on the site during this visit.
That seems like something that would be useful regardless of the medium.
Put it in the content, and then hide it in the media you don't want it
visible for, e.g.:
@media screen {
footer .breadcrumbs { display: none; }
}
This one was a trick question, sorry :) The per-session breadcrumbs
most definitely do not belong in markup. This breaks REST paradigm and
makes things like caching next to impossible. It's just wrong use of
HTTP.
The only correct way to implement them is to generate and render then
on/from the client side. Obviously, this doesn't impact either line of
reasoning behind print/screen media and does not invalidate what you
were saying -- consider it a sideline story :)
However, I think am starting to see what you're seeing. Basically,
your approach is to provide all content in the DOM tree and then flip
switches as needed to present it to various media types. Right?
Essentially, you are creating all-in-one DOM tree, where all content
co-exists in the same DOM space, then providing illusion of disparate
DOM spaces by turning on/off parts of the tree as needed using CSS. In
a way, you are using CSS to control representation of information,
rather than just content presentation.
This is the exact opposite of my sanboxing thinking, where I suggest
that separate DOM trees (representations) may be created.
But what about the cases where content needs to be reordered or just
plain needs to be slightly different? Is that still realm of CSS?
:DG
Re: [whatwg] [html5] window.print() undefined
On Tue, 19 Jul 2005, Maniac wrote: Ian Hickson wrote: That's a use case for a new feature in CSS, not in HTML. :-) It is solvable with events discussed. My point is that authors traditionally use scripting to solve things that can't be solved with other means. It's normal. Granted. But the events assume a specific UI model which is not necessarily the UI model of the browser. In IE it's fine because in IE the people who invented the events know the UI model. But in the HTML5 spec we can't assume the UI model. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
On Tue, 19 Jul 2005, Dimitri Glazkov wrote: However, I think am starting to see what you're seeing. Basically, your approach is to provide all content in the DOM tree and then flip switches as needed to present it to various media types. Right? Right. Essentially, you are creating all-in-one DOM tree, where all content co-exists in the same DOM space, then providing illusion of disparate DOM spaces by turning on/off parts of the tree as needed using CSS. In a way, you are using CSS to control representation of information, rather than just content presentation. I guess. I'm not sure I understand the difference. But what about the cases where content needs to be reordered or just plain needs to be slightly different? Is that still realm of CSS? Anything that is just changing the presentation without changing the semantics is the realm of CSS. Reordering certainly so. There are several lines of study in the CSSWG right now about reordering, in fact. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
Jim Ley wrote: This is flawed though, as it requires all the content to be in the page, including media-specific content. CSS cannot remove content, CSS is optional, consider: This page span id=viewedviewed/spanspan id=printedprinted/span on ... This is a contrived example of how people want web-applications to have media specific content - printed media particularly, although it would also apply to web applications deployed over interactive voice systems, but it shows how relying on optional methods to change content is simply flawed. I understand what you're saying, but I don't agree that events related to UA printing of the web document is the answer. For instance, such events could be combined with AJAX to force people into a pay-to-print scenario. There's just to much potential there for the web developer to control the user, and even if you considered that a valid thing to do, the user could simply create a Firefox fork or extension to circumvent it. There are two far better options. The first option is the one Mapquest and other sites use: provide a link to a printable version of the page. It's not ideal for all cases, but it probably satisfies most of the use cases where CSS isn't an option. The second is to allow the document object to be cloned, to allow operations to be performed on the clone, and then to allow printing from the clone. This allows specialized printing without tampering with the user's ability to do basic page printing. In my opinion, we should just have people do the former until we have interfaces for the latter.
Re: [whatwg] [html5] window.print() undefined
Btw, in HTML5 class name handling is easier through the DOMTokenString interface, you just write: element.classNames.add(somethingThatIsOnlyVisibleOnScreen) /olav
Re: [whatwg] [html5] window.print() undefined
Dean Edwards wrote: If I set element.style.display = block how do I hide it using a style sheet when it is printed? I dont think you should set element.style.display to block, if the element should be visible only on screen and not in print. It would be better to dynamically assign it a class which is defined in the stylesheet to be visible on screen and not in print. (Its a bit tricky to add and remove class names, but still cleaner than using print events.) regards Olav
Re: [whatwg] [html5] window.print() undefined
On 7/18/05, Ian Hickson [EMAIL PROTECTED] wrote: Why would you suspend a timer? (And why would the UA not suspend the timers itself?) You're saying that when a user print's an HTML5 user agent MUST stop all setTimeout counters, I don't see that in the spec, nor why it would be an expectation of a scripter. The common use of onbeforeprint/onafterprint is to add content to a document that is only relevant to printed media, this is something that cannot be done with CSS, since CSS is optional, so if we just hide content with CSS, we're stuck with the situation that users without CSS or with an appropriate user stylesheet get it and get confused. Of course for showing temporarily hidden stuff with script, as has been mentioned, there's no problem doing it with CSS. Jim.
Re: [whatwg] [html5] window.print() undefined
Olav Junker Kjær wrote: Dean Edwards wrote: IE has some nice onbeforeprint/onafterprint events. Can we add these too? Arent these event mostly used to transform the view before printing it? I think this is better handled by a print-specific style-sheet today. If I set element.style.display = block how do I hide it using a style sheet when it is printed? -dean
Re: [whatwg] [html5] window.print() undefined
Jim Ley wrote: On 7/18/05, Ian Hickson [EMAIL PROTECTED] wrote: Why would you suspend a timer? (And why would the UA not suspend the timers itself?) You're saying that when a user print's an HTML5 user agent MUST stop all setTimeout counters, I don't see that in the spec, nor why it would be an expectation of a scripter. So wait, we need to add new events because user agent vendors may be too stupid to solve print-related problems on their own? I'd rather not have events just to fix random user agent problems. The common use of onbeforeprint/onafterprint is to add content to a document that is only relevant to printed media, this is something that cannot be done with CSS, since CSS is optional, so if we just hide content with CSS, we're stuck with the situation that users without CSS or with an appropriate user stylesheet get it and get confused. What about the browsers that don't support Javascript, or have it turned off? Plus, what semantic content are you going to have that shouldn't display in all media types? I suspect that if you have to add or remove content for CSS-free user agents, you're probably using a lot of presentational HTML markup. Of course for showing temporarily hidden stuff with script, as has been mentioned, there's no problem doing it with CSS. Correct. Personally, I think using inline styles via the DOM should be discouraged in most if not all cases.
Re: [whatwg] [html5] window.print() undefined
On 7/19/05, Matthew Raymond [EMAIL PROTECTED] wrote: Jim Ley wrote: You're saying that when a user print's an HTML5 user agent MUST stop all setTimeout counters, I don't see that in the spec, nor why it would be an expectation of a scripter. So wait, we need to add new events because user agent vendors may be too stupid to solve print-related problems on their own? I'd rather not have events just to fix random user agent problems. As a scripter, I do not have an expectation that print will cause any effects on my scripts - Ian just said that it should have something that is the opposite of my expectation, as this is not defined, it needs to be defined - there are no user agent problems here. The common use of onbeforeprint/onafterprint is to add content to a document that is only relevant to printed media, this is something that cannot be done with CSS, since CSS is optional, so if we just hide content with CSS, we're stuck with the situation that users without CSS or with an appropriate user stylesheet get it and get confused. What about the browsers that don't support Javascript, or have it turned off? They don't get anything at all, this isn't necessarily a problem - having content there which is visible on screen but not understandable is a problem, a requirement from a previous project was simply date of printing, this was required by the process, and the normal footers of the browser were suppressed. Another common one is adding links explicitly in the page - to do this with CSS requires CSS3 features, or for external links to be in a different class, and of course neither are available in the most important Web Application platform. Jim.
Re: [whatwg] [html5] window.print() undefined
Ian Hickson wrote: On Mon, 18 Jul 2005, Dean Edwards wrote: OK. Forget CSS for a moment (although this is still a consideration for me). What if I want to suspend a timer while the page is being printed? Printing is (supposedly) instantaneous. Why would you suspend a timer? (And why would the UA not suspend the timers itself?) The point is, I can do all sorts of things using script. Alter styles, create elements etc. But when I switch media, I have no programmatic way to alter those effects. Please specify I means to do this. -dean
Re: [whatwg] [html5] window.print() undefined
Matthew Raymond wrote: The common use of onbeforeprint/onafterprint is to add content to a document that is only relevant to printed media, this is something that cannot be done with CSS, since CSS is optional, so if we just hide content with CSS, we're stuck with the situation that users without CSS or with an appropriate user stylesheet get it and get confused. What about the browsers that don't support Javascript, or have it turned off? Plus, what semantic content are you going to have that shouldn't display in all media types? I suspect that if you have to add or remove content for CSS-free user agents, you're probably using a lot of presentational HTML markup. I was thinking of the reverse. Scripts that add content for screen (helper widgets) but want them turned off (or at least show a different state) when printed. Please remember that the WHATWG is about web applications not simple documents. -dean
Re: [whatwg] [html5] window.print() undefined
On Tue, 19 Jul 2005, Dean Edwards wrote: Ian Hickson wrote: On Mon, 18 Jul 2005, Dean Edwards wrote: OK. Forget CSS for a moment (although this is still a consideration for me). What if I want to suspend a timer while the page is being printed? Printing is (supposedly) instantaneous. Why would you suspend a timer? (And why would the UA not suspend the timers itself?) Print Preview. If you do something during print preview, you're making big assumptions about the UI model. (e.g. that it is synchronous). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] window.print() undefined
On Tue, 19 Jul 2005, Dean Edwards wrote: The point is, I can do all sorts of things using script. Alter styles, create elements etc. But when I switch media, I have no programmatic way to alter those effects. Please specify I means to do this. You don't switch media. It's quite possible to have multiple media all at the same time. For instance Opera can be in speech mode and in screen mode simultaneously. See the introduction to the Browsing Context section: http://whatwg.org/specs/web-apps/current-work/#browsing -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] [html5] window.print() undefined
Shouldn't the print method on the window DOM interface be defined as well? Example: button onclick=window.print()print/button -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] window.print() undefined
On Sun, 17 Jul 2005, Anne van Kesteren wrote: Shouldn't the print method on the window DOM interface be defined as well? Example: button onclick=window.print()print/button It's probably best not to review the spec for missing features before the first call for comments. The spec at the moment is missing hundreds of things. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
