Each link allows you to manipulate the shapes listed. All intersections between the two shapes are updated as you manipulate the shapes. Some intersections display additional information when the shapes do not intersect. As an example, the circle-circle intersection determines if one circle is contained by the other circle.
It is important to note there are known problems with the Bezier-Bezier (any combination of quadratric and cubic) intersection routines. Incorrect intersections are reported when the control points use small values.
I do NOT work for Adobe. I do NOT work for Microsoft. I do not work for Borland. I do not work for Oracle. I do not work for any competing manufacturer of any kind. I am Joe Developer. In the end, it’s folks like ME that will decide which technology survives and which dies - simply by our choices.
That was said by Joe Nismet on the Serge Jespers thread that discussed the good, the bad, and the ugly of Silverlight. Serge went on a Silverlight training course and compared his experience.
Moxie Zhang summarizes the post starting with the good:
“The first thing I really like is the concept of threading. Being able to spawn off complex tasks without choking the main thread is pretty cool. You could, for example, show a really smooth animation when you are loading a bunch of data in a separate thread.”
“A Silverlight application can directly communicate with the HTML document it is hosted on by simply setting a parameter.”
“Being able to code in either C# or VB.NET is also a great feature. Especially since these two languages are pretty familiar to people developing for the Windows platform. I’m not one of them, but I found that C# is similar to ActionScript. Next to those languages you also have XAML, which does more or less the same things as MXML.”
and then the rest:
Code in XAML and C# is really verbose.”
“Styling controls is an absolute nightmare! I honestly think that this is going to be Silverlight’s Achilles’ heel!”
“Another thing that I really couldn’t grasp is the lack of HTML tag support in text fields.”
“I know the Expression tools are still in beta, but it has to be said that all the tools (including Visual Studio, which is no longer in beta) felt extremely buggy and incomplete.”
“Over these three days, I got a strong feeling that Silverlight was created by people who don’t know anything about designers.”
It was bound to cause a bit of a fuzz as people read into things. Interesting to ready from the side lines.
David Recordon has just started his OSCON talk, embedded above, on supporting the Open Web.
He is announcing the Open Web Foundation, a new attempt to have a place for us to incubate, license, and build community around specifications, protocols, and more.
I posted about this on my blog as I am an initial member:
I am excited to see the recent talk of Open Web Foundation is now out there. I think that it is poised to become a great new corner of the Web giving us a place for the other stuff.
Let’s take an example. Imagine that you came up with a great idea, something like OAuth. That great idea gains some traction and more people want to get involved. What do you do? People ask about IP policy, and governance, and suddenly you see yourself on the path of creating a new MyApiFoundation.
Wait a minute! There are plenty of standards groups and other organizations out there, surely you don’t have to create MyApiFoundation?
Well, there is the W3C and OASIS, which are pay to play orgs. They have their place, but MyApi may not fit in there. The WHATWG has come up with fantastic work, but the punting on IP was an issue too (solved by working with the W3C).
MyApi has some code in there, so how about putting this in Apache? Apache is great for code, but it doesn’t deal with the other stuff, which is fine. That isn’t its mandate. Apache does things very well though, especially when it comes to governance and the incubator process. What if we had a foundation that had some of the same values around people participating (so anyone can, versus companies) and a varied community (not just a few blokes from the same company).
This is why I am hopeful for the Open Web Foundation. It is a new place to look at if you come up with something helpful for the Open Web, a place that may match your values.
But wait a minute, what about this “Open Web” thing again. As I just said on a post about defining the term, people can’t agree on what the darn thing is! There is a lot of gut feel “Flash and Silverlight are not the Open Web, but GWT is!”
I believe that the Open Web Foundation needs to be a leader in working this out. With metrics in place, the foundation can bless projects that meet the requirements. When a project starts it may not be Open Web yet (e.g. multiple browser implementations). We need a place to move forward and push the Web. Can’t wait to see what happens there.
Announcing a new foundation isn’t what matters. What really matters is what comes of it. I am excited to see how this all evolves.
Safari and IE8 are already changing the way scripts are getting loaded. Their idea is to download the scripts in parallel, but execute them in the sequence they’re found on the page. It’s likely that one day this blocking problem will become negligible, because only a few users will be using IE7 or lower and FF3 or lower. Until then, a dynamic script tag is an easy way around the problem.
Danny Thorpe wrote some comments and the issue with Safari:
This works great for Firefox and IE, but fails completely in the Safari browser. Safari doesn’t implement onLoad notifications for script tags. This forces you to abandon the onLoad technique and instead use the technique of embedding something at the end of each script file to signal when the file has been loaded.
The script libraries for the Windows Live sites use this technique - every source file contains a function call at the bottom that tells a central notifier that it has been loaded. Other code can ask the notifier to signal them when a file or set of files have been loaded. This works in all browsers without relying on diverging browser idiosyncrasies.
Ext GWT 1.1 development is moving along nicely and includes a new Grid component. Grid is based on the Ext JS Grid and will support the same features including grid plugins, grouping, totaling, and inline editing.
Grid vs. Table
One if the biggest differences between Table and Grid is performance. Table does not scale well with a large number of rows. Grid renders its data much faster and can handle larger data sets with noticeable differences in initial rendering times.
Table is a container of TableItems which work without a model. TableItems deal directly will cell values. Model support is added using a TableBinder which works with a Store. With Grid, there are no child components and Grid works with the Store directly. This design simplifies use and the binder is no longer needed.
The first couple of paragraphs says a lot. First we have the "look at the companies supporting it":
It’s Bill Hill here again, still fighting the good fight to make typography on the Web as good as we’re used to seeing in print. We made significant progress this week, when one of the USA’s most prestigious font companies announced its support for the Embedded OpenType format for font embedding on the Web, and launched a new website to promote other browsers to support it in addition to Internet Explorer (which has had EOT support built-in since 1996).
And then the fear about font linking ;)
At the same time, Ascender Corporation and its collaborators in the typographic community also warned of the legal dangers of using the Font Linking mechanism currently supported by other browsers.
So, EOT is "in front of the W3C". What are your thoughts?
One performance technique without having to simplify the page design is to combine multiple scripts into a single script, and similarly combine multiple stylesheets into a single stylesheet.
Combining multiple files reduces the extra bytes from HTTP headers as well as potential transfer latency caused by TCP slow starts, packet losses, etc.
Tenni continues to discuss the issue and a solution that Yahoo! implemented, a simple app that combines the files on the fly:
Combo Handler provides a way to allow developers to maintain the logical organization of their code in separate files, while achieving the advantages of combining those into a single file as part of the final user experience. It alleviates the need for the time-consuming re-build and re-push processes. In addition, Combo Handler integrates seamlessly into a content delivery network, taking full advantage of the benefits of a CDN while reducing the drawbacks of dynamically combining separate files.
We’ve been using this service across many Yahoo! properties for some time now to help improve end users’ response times. Thanks to the YUI team, it is now available to all of you that are using the Yahoo!-hosted YUI JavaScript files. (Note: Combo-handling of CSS files is not supported at this time.) Head over to the YUI Configurator to generate combo-ready filepaths customized for your specific YUI implementation.
What about the numbers though. Well, this simple technique saved HotJobs 8% on their response time, and this was on a page that already had an A grade in YSlow, so was highly optimized.
Combining six JavaScript files into one single JavaScript file improved performance by almost 8% on average for Yahoo! HotJobs’ users on broadband bandwidth speeds and 5% for users on lan. No design or feature changes required!
The window.name transport is a new technique for secure cross-domain browser based data transfer, and can be utilized for creating secure mashups with untrusted sources. window.name is implemented in Dojo in the new dojox.io.windowName module, and it is very easy to make web services available through the window.name protocol. window.name works by loading a cross-domain HTML file in an iframe. The HTML file then sets its window.name to the string content that should be delivered to the requester. The requester can then retrieve the window.name value as the response. The requested resource never has access to the requester’s environment (JavaScript variables, cookies, and DOM).
var deferred = dojox.io.windowName.send("GET", {url:"http://somesite.com/resource"});
deferred.addCallback(function(result){
alert("The request returned " + result);
});
Kris then goes on to show how to use this with Web services and other scenarios, and explains why you may be interested:
This technique has several advantages over other cross-domain transports:
It is secure, JSONP is not. That is, it is as secure as other frame based secure transports like fragment identifier messaging (FIM), and Subspace. (I)Frames also have their own security issues because frames can change other frames locations, but that is quite a different security exploit, and generally far less serious.
It is much faster than FIM, because it doesn’t have to deal with small packet size of a fragment identifier, and it doesn’t have as many “machine gun” sound effects on IE. It is also faster than Subspace. Subspace requires two iframes and two local HTML files to be loaded to do a request. window.name only requires one iframe and one local file.
It is simpler and more secure than Subspace and FIM. FIM is somewhat complicated, and Subspace is very complicated. Subspace also has a number of extra restrictions and setup requirements, like declaring all of the target hosts in advance and having DNS entries for a number of different particular hosts. window.name is very simple and easy to use.
It does not require any plugins (like Flash) or alternate technologies (like Java).
$wnd.sayHello(name); // $wnd is a JSNI synonym for 'window'
}-*/;
But finally, what about if you wrote a bunch of Java code for GWT, and you want JavaScript to call that? Simply link the code back through the $wnd world:
I heard that when asked who knew what the "Open Web" meant at a recent conference, hardly anyone put their hands up. Those that often think that they do understand it, understand it at a gut level.
Brad Neuberg has been thinking about this, and wrote the following asking for our input:
What the Heck is the Open Web?
Do you toss the term Open Web around? Ever wonder what the heck it means? Me too.
I'm looking for a definition of the Open Web that:
Doesn't constrain the web from growing in the future (i.e. that it's expansive enough that it's not just defending the status quo but can adapt to new innovations)
I've got my own opinions on these but I'm interested in hearing what you think. Basically, what's the elevator pitch for the Open Web? Its easy to talk to the Converted (tm), but what about when talking to other folks that might not care as much yet?
You get bonus points if you can answer the following:
If Adobe were to open source Flex/Flash, or Microsoft Silverlight, would that be the Open Web? If so, why? If not, why not?
Why should developers care about the Open Web? How about users?
How would you define the web itself, again in a way that doesn't constrain it from future growth and development (i.e. "It's a place to publish a bunch of documents" doesn't allow room for deploying applications, as we are seeing with Ajax today).
We toss around the term Open Web a bunch, but I've never seen it succinctly defined. What is it, and why do we support it? I believe its important and worth supporting but it's all a bit fuzzy right now.
What's the greater of these evils: contorting site designs around the standard Web-safe fonts, using images to render type, or relying on sIFR to render type with Flash?
Who knows, but man, it sure would be nice if we could reliably use any font we wanted in our web work. And, as it turns out, IE4+ and Safari 3.1 offer mechanisms for doing just that.
The linked font can be a regular old TrueType font. Compare this to IE6/7 which also support the @font-face at-rule but only support special "Embedded OpenType" fonts.
At first blush, you and I might think, "Yay for Safari! And, thanks IE for yet another screw." But that was before we considered the DRM issues. You see, there's an established technology for enforcing the use of fonts in embedded applications, and CSS's @font-face bypasses it by directly linking to TrueType fonts. At least one major font foundry is mighty uncomfortable with the thought of more browsers following Safari's lead.
Hence fontembedding.com, a newly-launched site promoting the virtues of the long-misunderstood and under-loved Embedded OpenType (EOT) format and the evils of linking to TrueType on the Web, complete with a call to action to other browsers to support EOT once the recent W3C EOT submission is ratified (i.e., maybe we can expect to use them cross-browser in 2014). EOT, you see, embeds the URL of the website that licensed the font for embedded use so that User-Agents can enforce font licensing restrictions.
Fascinating.
I wish them luck with EOT; in the meantime I suspect Firefox will implement @font-face and enough high-quality freely embeddable TrueType fonts will emerge to ensure that EOT remains as irrelevant as it ever was.
But then, I've been wrong before.
Still, fun to realize that as soon as Firefox implements @font-face, thanks to TrueType-EOT converters, we can finally use fonts on the web. Myspace will never be the same.
If there's a single experience that bonds all Web developers, it is the incomprehensible joy of wasting hours of our lives supporting IE6. The quasi-palindromic Dionysios Synodinos (alright, it's pretty far from reversible, but there's got to be a good anagram in there) over at InfoQ has put together a fun piece discussing wither IE6. From the article:
Since attaining a peak of about 95% usage share during 2002 and 2003, Internet Explorer 6 (IE6) has been rapidly losing market share. As the end of 2008 approaches, significant online services, vendors and web frameworks are dropping support for IE6. Will this year be the end of IE6 and what does this signify for Web 2.0 developers?
Dionysios draws examples and quotes from Apple, SproutCore, 37signals, Douglas Crockford, Dylan Schiemann, John Resig, and more as he searches for an answer. There's no conclusion to the piece, but plenty of perspective. Some excerpts:
