26 Apr 2002
Fri, 26 Apr 2002
Eliminate browser printing problems with CSS
Mark Pilgrim has a really interesting article about using CSS to provide well-formed print output automagically in the browser without needing to create a separate printable page for each and every page designed for online viewing. I asked Mark to share his print.css with the community. I'm hoping it might be useful, ie. that I don't have to write my own to get the benefits that Mark describes.
Posted at: 23:20 | permalink
Netscape's still in the browser game
If my web server statistics are to be believed, Netscape isn't as far behind in the browser war as we believed. Of course, there's a certain audience that reads this web page but still, who would've guessed that the numbers would be that close.
|
Top 2 of 120 Total User Agents | |||
|---|---|---|---|
| # | Hits | User Agent | |
| 1 | 63967 | 48.09% | Internet Exploder |
| 2 | 60199 | 45.25% | Netscape |
Posted at: 06:24 | permalink
Response to Paul Prescod's Email
This morning, I got email from Paul Prescod regarding my rebuttal of his article: "I wondered if you were going to update your weblog to admit that your log was actually agreeing, not disagreeing, with my article." And my reply: I wondered if you were going to update your article to admit that SOAP does not preclude the use of HTTP GET/POST? And further clarification: My use of HTTP/GET POST with SOAP solves the problem of getting data from the SOAP service when that idiom is necessary and provides lower implementation cost than SOAP libraries provide. That is clearly the case with browser interfaces but not with full-blown GUI clients. All of the other client interfaces that I have written including Java and C# use Electric's GLUE or the Microsoft SOAP libraries, respectively. In the case of Java or C#, writing the HTTP GETs or POSTs long-hand would not produce the ease of use and low implementation cost that the SOAP client libraries provide. In the end, most people will not be concerned with the details of the SOAP/REST mud-slinging, as Joel Spolsky says, they'll be more concerned about the fact that they get an intellisense pop-up in their IDEs when they go to write their clients. Sam Ruby clarifies my point even further here. Sam's right, we use this for read-only operations where the infrastructure that we've built with Glue just makes it trivial to hook up the pieces. We're not trying to launch a satellite with the HTTP GET interface. To clarify even further, the example that I'm talking about is one in which we, the implementors, are writing both client(s) and server. Obviously, that makes it much easier to control the use of this type of interface. I am working at home on some stuff that would expose an HTTP GET interface for public consumption but that's not ready for prime time. Finally, in his posting to the comments on the article, Paul asks, "By the way, I would be very grateful if you could give me information on whether GLUE can also generate HTTP *clients*. My impression after a few minutes of playing is that it cannot and that is too bad." And my answer is: no, to the best of my knowledge there is no way to generate HTTP clients as it is a very limited form of interaction with the web service and I believe it was designed to solve the aforementioned problem with browser clients. I'd be curious what Graham Glass would have to say on the subject. Side note: now I understand what Dave Winer was talking about.
Posted at: 05:35 | permalink
