Undolog.com

A few days ago I installed - on a special machine - the beta of Microsoft Internet Explorer 7. The installation lasted an eternity, inflating the PC robbaccia as usual. The first problems came to the first required reboot, as usual, missing icons, strange flickering, etc. ...

At Microsoft we have been working for years and still do not support CSS as Christ commands! You just can not understand how they can develop bad. They will have a team of 50 people at least have all the money in the ground but, nevertheless, to create garbage persevere software.

Congratulations to the team instead of FireFox, which in the beta for version 2 already looks a JavaScript 1.7!

What can I say ... it would be better that Microsoft stopped producing its own browser, since it can not quite keep pace with the times. Delays and continuous structural deficiencies make IE basically useless. The bugs, then, seem to be at home in Redmond, then we strongly recommend to stay away. The development team: please support PNG transparency with 24bit ... are centuries FireFox implemented it! Let's go ...
Hopefully Firefox 2.0 arrives soon!

Continued ...

Due to incompatibilities of style and perhaps output - yet - cross-browser, not everyone knows the vast potential of style sheets. We want to show, therefore, some features of CSS syntax unknown to many and to remind us how little - often - we exploit fully the tools we have available.

Note: All examples were tested on Firefox 1.5.0.5

Select by attributes

This feature, often referred cone advanced CSS2, allows strabiglianti things, if we reflect for a moment. The biggest advantage you ottinene HTML side, where there is no need to distinguish between classes or id tag in the CSS. It is precisely the attributes - though present - in the TAG to indicate which style associated. Furthermore, any attribute of the tag can be taken as a selector: alt, title, accesskey, etc. ...

Selection for depth

This type of selection is nothing short of spectacular, if you consider that may be added to the previous one. It allows you to define the hierarchy of elements. Looking at the example below we will immediately realize the extraordinary importance of this type of selection, which keeps the HTML clean and free of unnecessary indicators.

e – fantastico – first-letter ! Indeed, just to conclude this overflight, as well as last-child exists first-child and - amazing - first-letter ! Try it.
We have barely touched the subject, of course, quite broad to say the truth, who sees CSS as advanced instrument for the definition of layput pages. There are other selectors and behaviors, and great news for the specification of the CSS file for future generation.

Continued ...

Finally we are! The Web, using the well-known Google brand, officially arrives on mobile phones. The fact that it has launched an advertising campaign (TIM), which shows the use of the Google search engine on mobile phones, light up the few who still do not sapevavo the Internet - after all - it was also accessible from your mobile phone.
Actually there is a real technological innovation in the strict sense of the term. WAP and derivatives (Flash Lite, for example) are available and used for some time, but what makes it interesting is the official sponsorship of the use of Google via mobile.

You can now open a new market for the realities of IT should be scheduled in their schedule of offerings, the ability to provide a version of Web browsers for mobile.

But how widespread is the use of mobile as a web browser?

Tim has also posted a short time ago, a text message (advertising) where informed that the rates of browsing the Web (or WAP) mobile mode were changed! In this case you pay only the connection fee (we hope soon to be eliminated, too) for free after which you browse for what you want. This is a step that confirms the fate that - sooner or later - waiting for us.

It is therefore evident a movement, a ferment in this area, tried - for example - an agreement on a set of guidelines for site development WebMobile between Nokia, Vodafone and Google. The W3C, for its part, proposes its guidelines .

According to a survey by M: Metrics, 19% of U.S. mobile phone users regularly consult the Web through their mobile phones! Imagine the Japanese!

Daniel Applequist, an executive of Vodafone, said "we now know that the devices available to users have the ability to surf the Internet, but are not used as much as they could be." This is true depends, almost exclusively, by the costs of connection, yet substantially different than home connections and not well advertised to the masses. In addition to this we must also consider - at least in Italy - it is relatively recently that mobile phones have become popular color! ISSUES to be reckoned with!
In addition, Applequist, argues that "the majority of available Web sites do not work well with mobile phones", and a closer look, add us, do not work well even with the standard browser on your PC!
The question is - unfortunately - still the same! The standard - in this area - seems to suffer from huge and insurmountable difficulties. The developers already fear, in fact, any repetition of the same wasteful scenario present on the desktop, where even the likes of Firefox browser still suffer from different operations depending on which operating system is installed. It 'hard to imagine a robust standard for mobile and secure when - even now - Microsoft IE renders a page in one way and another opera!

Surely part of the blame must be attributed also to Web developers often use proprietary features specific to a particular browser, thus making navigation - if not the reading - not possible with other systems. However, for those who work in the Web, the prospect of a new device to explore is certainly fascinating, a few clouds on the horizon could discourage more, but we are confident, will open a new market and could perhaps be an opportunity to fix - once and for all - the greater nightmare that plagues the majority of Web developers

W3C offers his guidance, it's up to us - but - try to follow them and, last but not least, to manufacturers of mobile phones could soon become ... Apple or Microsoft or Adobe if anything, as is buying it all!

Continued ...

The development of web applications with Ajax-type technologies has highlighted the limitations of all Internet protocol HTTP. Sooner or any programmer trardi collides with the need - for example - to have a permanent connection with the client. Sending a broadcast to the client message is still impossible without resort to some artifice risky!

In the Internet scenario, however, the use of special components such as ActiveX Object, Flash or Java applet, allowing to circumvent the problem well. Often, in fact, one wonders if the HTTPRequest object (brick base for Ajax experience) can not be substituted by an ActiveX component or by using an invisible Flash movie just in case!

This is one of the most poignant part of the development of next-generation web applications. To prove it, in fact, there are a number of "beta" web application using mixed technologies to solve the various problems that arise - and that the HTTPRequest is unable to perform. The same FlickR , one of the most successful photo-blog, makes use of Flash movies in some sections of the site. There are actually more articulate where there are Java applets or ActiveX controls to get them where no one - Ajax - was gone before!

What should be done in the short term, is a new standard for the HTTPRequest, even calling it another way. Being able to get an object, present in all browsers, capable of making connections permanet and able to handle multiple protocols. However, this would be a pipe dream for developers, but reason well, could lead to death of the Internet as we know it.

When HTTP was designed as a global network we know today had very different speeds and users. The important points of HTTP are:

• Connecting to the Web Server
• Request a file
• Disconnecting

The HTTP is born with the basic idea of not burdening the network transmission; minimal support handshake! Even today, when the browser requests a page to a Web Server, the place just three steps above. It 'important to note that Google has developed a software like Google Earth in order to overcome the obstacles of connection and other stuff. Internet connection is ready to bear permanet? We think it's premature. Most hosting will collapse in a few seconds. Banda and CPU should be much more able to withstand the amount of traffic that is produced today.

The fact that support connections permanet are well circumscribed, and always make use of specific technologies and components, and sophisticated.

Continued ...

Rumor has it that a discussion is currently underway on the use of Javascript as a manufacturer of HTML content. In particular, the dilemma haunts the Ajax world. Under this acronym hides a method that allows you to contact the Web Server using JavaScript scripts, without the browser has to reload the entire page with the result - and annoying - "fliker" video.

The fact that this technique allows to communicate with the Web Server means, in practice, you can send - and receive - information from the Web server without the user - in fact - if you know it! Statements of the latter would be the case to open a separate discussion.

Returning to our question, the main question is the following: once receiving the response from the Web Server who has to build the scaffolding that you can insert the HTML response to the current page? It must do so at the time of the Web Server or the response is a task delegated to the client side JavaScript?

In practice, some say the best way is to pack the complete answer directly on the server side, so that the client JavaScript and should only take place (get & insert). Others, however, argue that the best thing is to receive garbage data, raw, perhaps in an XML structure and process all the client side, using JavaScript, and always with JavaScript to create the scaffolding needed to insert the HTML page.

It seems readily apparent, however, that you can not - a priori - to support one model over another. Both, of course, must be contextualized. It 'possible that in some cases to pack everything in the web server it is actually the best choice, both in development and speed of transmission.

It must be said at once that the idea to load large quantities of Javscript code on the client is not a beautiful solution. I say this in memory of scalability. A system that has already heavy in its early stages, has little chance to progress in peace in the future. Moreover, even among the widespread incomptibilità browser available, then the client side Javascript code make it too tiring to develop articulated. However there are those who do it! Undoubtedly.

The moral, to date, with browsers and operating systems we have, seems to be that everyone must choose his own way, tomorrow we'll see. Visit our website Applick.com , the code was written using both methods, as appropriate.

Tomorrow, perhaps, will come out of the browser with code pre-board! The component will certainly be revised HTTPRequest. For now, this technique is its re-birth (see use of the IFRAME TAG) is the minimum standard HTTPRequest made ​​on the component, its presence and implementation in browsers, and both the increase in average available-bandwidth Internet users. The HTTPRequest is still a sub-channel HTTP, no more and no less. Sending an XML instead of HTML does not make much difference, there sniffing the network realize now. Perhaps these are moaning about something else that goes beyond the question of Ajax. It 'undeniable that a certain part of the Internet community calls for a change, structural changes. There has been talk - rightly - of the connections, Further, that certainly has nothing to do with the current policy (and original) of the HTTP protocol.

The reality, in the end, it may be to admit that the current technology of the Internet is exceeded. His protocols, designed for other network speed and other conditions, are obsolete.

Continued ...