Web Interface Definition Language [WIDL]

which collectively are referred to as "the submission". We request the submission be known as the "WIDL" submission.

Abstract

This document provides the specification for the Web Interface Definition Language (WIDL), a metalanguage that implements a service-based architecture over the document-based resources of the World Wide Web. WIDL is an application of the eXtensible Markup Language (XML); it allows interactions with Web servers to be defined as functional interfaces that can be accessed by remote systems over standard Web protocols, and provides the structure necessary for generating client code in languages such as Java, C/C++, COBOL, and Visual Basic. WIDL enables a practical and cost-effective means for diverse systems to be rapidly integrated across corporate intranets, extranets, and the Internet.

1. Introduction

The World Wide Web is providing millions of end-users access to ever-increasing volumes of information. While the Web initially served browsers static documents, the resources of legacy systems, relational databases and multi-tier applications have all been made available to the Web browser to provide corporate users with interactive information resources including financial services, inventory management, on-line purchasing and package tracking.

While the Web has achieved the extraordinary feat of providing ubiquitous accessibility to end-users, it has in many cases reinforced manual inefficiencies in business processes as repetitive tasks are required to transcribe or copy and paste data from browser windows into desktop and corporate applications. This is as true of Web data provided by remote business units and external (i.e. partner or supplier) organizations as it is of Web data accessible from both public and subscription based Web sites. The problem of direct access to Web data from within business applications has been largely ignored.

The purpose of the Web Interface Definition Language (WIDL) is to enable automation of all interactions with HTML/XML documents and forms, providing a general method of representing request/response interactions over standard Web protocols, and allowing the Web to be utilized as a universal integration platform.

A central feature of WIDL is that programmatic interfaces can be defined and managed for data (HTML, XML or text files) and services (CGI-bin, database, or other back end systems) that are not under the direct control of programs that require such access. WIDL definitions can be co-located with client programs, centrally managed in a client/server architecture, or referenced directly from HTML/XML documents.

WIDL defintions provide a mapping between Web resources and applications written in conventional programming languages such as C/C++, COBOL, Visual Basic, Java, JavaScript, etc., enabling automatic and structured Web access by compatible client programs, including mainstream business applications, desktop applications, applets, Web agents, and server-side Web programs (CGI, etc.).

Automatic means that complex interactions with Web servers do not require human intervention; programs can request Web data and services by making local calls to functions which encapsulate standard Web access protocols and utilize WIDL definitions to provide naming services, change management, error handling, condition processing and intelligent data binding.

Structured means that Web data and services are described as interfaces with well defined input and output variables.

Standard Web access protocols means HTTP and HTTPS.

Compatible means any program that both utilizes WIDL definitions to define the location of Web services and the structure of data that is returned by standard HTTP and HTTPS requests, and allows WIDL definitions to be managed locally, centrally, or by individual service providers.

WIDL describes business objects on the Web, providing the basis for a common API across Web servers, legacy systems, databases, and middleware infrastructures, and effectively transforming the Web from an access medium into an integration platform.

This document provides a complete description of the Web Interface Definition Language (WIDL).

2. Benefits of WIDL

A major part of the value of an Interface Defintion Language (IDL) is that it can define services offered by applications in an abstract but highly usable fashion. WIDL brings to the Web many of the features of IDL concepts that have been implemented in distributed computing and transaction processing platforms including DCE, and CORBA.

2.1 Business-to-Business Integration

WIDL makes it easy for organizations to automate business transactions with customers and suppliers. WIDL describes and automates interactions with services hosted by Web servers on intranets, extranets and the Internet; it transforms the Web into a standard integration platform and provides a universal API for all Web-enabled systems.

Using HTML, XML, HTTP and HTTPS as corporate standards glue, WIDL requires only that target systems be Web-enabled. There are hundreds of products in the market today which Web-enable existing systems, from mainframes to client/server applications. The use of standard Web technologies empowers various IT departments to make independent technology selections. This has the effect of lowering both the technical and 'political' barriers that have typically derailed cross-organizational integration projects.

A number of analysts have already warned that proprietary e-commerce platforms could lock suppliers into relationships by forcing them to integrate their systems with one infrastructure for business-to-business integration, making it costly for them to switch to or integrate with other partners who have selected alternate e-commerce platforms. Buyer-supplier integration issues involve many-to-many relationships, and demand a standard platform for functional integration and data exchange.

A service defined by WIDL is equivalent to a function call in standard programming languages. At the highest level, WIDL files describe the locations (URLs) of services, input parameters to be submitted (via Get or Post methods) to each service, conditions for successful processing, and output parameters to be returned by each service.

WIDL provides the following features:

A browser is not required to drive Web applications

WIDL definitions are dynamically interpreted and can be centrally managed

Client applications are insulated from changes in service locations and data extraction methods

Developers are insulated from network programming concerns

Application resources can be integrated through firewalls and proxies

WIDL can be used to describe interfaces and services for:

Static documents (HTML, XML, and plain text files)

Dynamically generated documents (HTML, XML, and plain text files)

HTML forms

URL directory structures

WIDL can be used:

to automate interactions with Web servers

for both on-demand and scheduled extraction of targeted Web data

to aggregate data from a number of Web sources

to chain services across multiple Web sites

to rapidly integrate Web resources with traditional application development languages and environments

WIDL has the ability to specify conditions for successful processing, and error messages to be returned to calling programs. Conditions further enable services to be defined that span multiple documents.

2.2 Change Management

One of WIDL's most significant benefits is its ability to insulate client programs from changes in the format and location of Web documents. Unlike the way CORBA and DCE IDL are normally used, WIDL is interpreted at runtime; as a result, service URLs, object references in variables, definitions of document regions, success/failure conditions, and directives for service chaining can all be administered without requiring modification of client code. This usage model supports application-to-application linkages that are far more robust and maintainable than if they were coded by hand.

There are three models for WIDL management:

client side - where WIDL files are co-located with a client program

naming service - where WIDL definitions are centrally managed and referenced via directory services, i.e. LDAP

server side - where WIDL files are referenced by, co-located with, or embedded within Web documents.

WIDL does not require that existing Web resources be modified in any way. Flexible management models allow organizations to describe and integrate Web sites that are uncontrolled, as well as to provide their business partners with interfaces to services that are controlled. The ability to seamlessly migrate from independent to shared management eases the transition from informal to formal business-to-business integration.

2.3 Language Bindings

The primary purpose of WIDL is integration of Web resources with corporate business applications. In much the same way that DCE or CORBA IDL is used to generate code fragments, or 'stubs', to be included in application development projects, WIDL provides the structure necessary for generating client code in languages such as C/C++, Java, COBOL, and Visual Basic. Developers can thus be insulated from the need to understand both HTML/XML parsing and Web protocols. This capability enables the existing skills of innumerable programmers to be rapidly leveraged in the utilization of Web based resources.

3. Object Model References

Many of the features of WIDL require a capability to reliably identify and extract specific data elements from Web documents. Various mechanisms for accessing elements of HTML and/or XML documents have been defined, such as the Javascript Page Object Model, the Document Object Model, and XLL XPointers. WIDL does not define or determine a mechanism for accessing document data, but rather allows an object model referencing mechanism to be specified on a per-interface basis.

The following capabilities are desirable for accessing elements of Web documents:

HTML Parsing

XML Parsing

Text Pattern Matching

Object referencing mechanisms would ideally support both parsing and pattern matching. Pattern matching extracts data based on regular expressions, and is well suited to raw text files and poorly constructed HTML documents. Parsing, on the other hand, recovers document structure and exposes relationships between document objects, enabling elements of a document to be accessed with an object model.

4. WIDL Reference

The Web Interface Definition Language (WIDL) is an application of the eXtensible Markup Language (XML); its definition consists of the various XML elements defined in this section.

Major Elements

WIDL - defines an interface

SERVICE - child of WIDL - defines a service

BINDING - child of WIDL - defines input and output parameters for services

Minor Elements

VARIABLE - child of BINDING - defines a variable within a binding

CONDITION - child of BINDING - defines a condition within a binding

REGION - child of BINDING - defines a area within a document

UI Web Developer - Interview Questions

Excellent Communication Skills:-
The candidate should be a good communicator as most of the cases he will be the liason between business stakeholders and project management team.

Technical Skills:-
Should be Strong with : HTML, CSS, Javascript/JQuery

UI Design/Javascript/CSS/JQuery:
How would you make sure that your CSS are cross browser compliant?
What testing tools you've used for cross browser testing?
Which javascript frameworks have you used?
How would you achieve a Corporate Heading on all pages?
What would be your approach to desing following elements:
Navigation Menu
3-Column Layout
A Grid with more than 2000 rows
How would you manage a grid which has more columns than the page width (without horizontal scrolling)?
What is CDN based referencing? Why do some site use JS files from Google or Yahoo CDN instead of their own server?
How would you optimized the javascript footprint of the page?
What all measures you would take to reduce the rendering time for a HTML page?
What are the 3 key usability consideration you would make to design a website which will be used by School Principles (the users can change based on your requirements like CTO/CEO or Lawyers)
Which tools you've used for javascript/jquery debugging? In which scenario?
How would you handle a heirarchial response in JSON?
How would you implement Error Handling in jquery or javascript?
What all validation frameworks you have used?
What all jQuery Plugins you have used? Where?? To achieve what??
Tell me a scenario where you faced an issue with a jQuery plugin and you fixed/hacked it?

Information Architecture - Planning out a web site

Introduction
Traditionally, the planning stage of a web site (or any project) can be a little stressful. Everyone has an opinion about how a web site should be built, and often their opinions will conflict with one another. Your number one goal on any web site should be to build something that’s useful for the people who will be using it. It really doesn’t matter what your boss says, what that guy down the hall with a doctorate in software engineering says, or even what your personal preferences are; at the end of the day, if you’re building a web site for a particular group of people, their opinion is the only one that matters.
This article is going to look at the early stages of planning a web site, and a discipline that is commonly referred to as Information architecture, or IA. This involves thinking about who your target audience will be, what information and services they need from a web site, and how you should structure it to provide that for them. You’ll look at the entire body of information that needs to go on the site and think about how to break that down into chunks, and how those chunks should relate to one another. The sections below are as follows:
• You need to plan out the site you’re building
o Introducing “The Dung Beatles”
o Now what? Drawing a site map
o Naming your pages
o Adding some details
• Summary
• Exercise questions

You need to plan out the site you’re building
You’ll come upon the odd web project that you can just dive right into without any up front thought, but these are, by far, the exception and not the norm. We’re going to take a look at a fictional band called “The Dung Beatles” and try to help them work through the early stages of planning out their web site. We’ll talk with the band and find out what goals they have, and what they would like to see on their web site. Then we’ll dive in and start working on a structure for the band’s information.

Introducing “The Dung Beatles”
The Dung Beatles (TDB) have a problem. They are the hottest Beatles tribute band in Moose Jaw, Saskatchewan, but they need to raise their profile for an upcoming North American tour this summer. They’ve got venues scheduled throughout Canada and the United States, but they’re virtually unknown outside of their hometown. If only there was some way, using technology, to reach a large number of Beatles fans for relatively little money.
Lucky for TDB, we’ve got this thing called the World Wide Web, and they quickly decide that building a web site is the answer they’ve been searching for. TDB needs a place to promote their tour dates, build a fan base in other cities and raise awareness of the band. You’re going to work through their ideas with them and see if you can chart out a plan for their web site.
You schedule a meeting with your new clients to hash out the details of what they’re looking for and to decide on due dates and costs. You open the conversation by suggesting that you talk about the goals and objectives of the web site in order to get an idea of what they want. What does the band hope to achieve with their online presence?
TDB starts talking about their upcoming tour, and how they want to get the word out to Beatles fans in all of their scheduled stops. It’s February now, and they’re scheduled to kick off their tour in five months time.
Hang on a second! A web site alone won’t build it’s own traffic and publicize itself. You extract from the conversation thus far that the main goal for the site is to provide a home for TDB fans online; a place where they can keep up to date on the latest news, tour dates and venues. Through the fans (word of mouth), and some other advertising venues, new people will be driven to the web site where they can download sample tracks, check out pictures of the band (in full costume) and find out where/when they can check them out live.
Raul McCoffee, the front man of the group, points out that it would be nice to be able to raise a little extra money for the tour through the sale of some CDs and band merchandise. You gather the band around and draw out a quick sketch of what a visitor might want when they visit the web site. This is just a really rough brainstorm of ideas; it’s got very little structure at this point.
There are two general groups of people who will visit the site—people who know TDB already and like them (fans), and people who are unsure. You’ve got to cater to both those groups in different ways; potential fans need to be “sold” on the group, whereas current fans want to “feed their addiction” (so to speak). What sort of information is each of these groups going to be looking for? Figure 1 gives an indication of this—this is a typical sketch of the type that you’ll want to make at this point in future web site projects. From this, you’ll work out what pages the web site needs, and how they should link to one another.


Figure 1: What your web site visitors want.
You settle on a budget, and agree to launch the web site in one month. You promise to get back to the band in a couple of days with some plans outlining the direction you’re going in.

Now what? Drawing a site map
A lot of people will throw together a site map at this stage—this looks like an org (organizational) chart. This is usually a pretty basic graphic showing simply the names of each page on the site and how they link into the overall structure of the web site. Personally, I like to put in a little more detail and talk about the purpose and content of each page. For example, a page may be labeled “Home”, but what is the home page? Is it a cheesy “welcome to our web site” message (yuck!) or is it a more dynamic page containing news items and enticing images? Take a few minutes to think about what pages the above sketch might turn into, and what might be contained on each page. Have a go at drawing your own site map before moving on to the next section.
Now let’s get started with the basics: one of those org charts that I mentioned above. Figure 2 shows my attempt at taking the brainstorm and turning it into a site org chart:


Figure 2: First iteration of site structure.
That definitely captures all of the pages we’ll need, but there’s no real grouping going on here. It’s just a big mess of pages now, and at this point I hadn’t really given a lot of thought to what things are called. I did one more pass and try to “chunk” the information into slightly larger groupings—Figure 3 shows what I did:


Figure 3: Site structure, revised
I’ve done a couple of things with the revised site structure. The “Band News” page gives TDB a place to post anything they want to share with their fans. Even after their summer tour is over, and the “Tour dates and locations” page is no longer relevant, they’ll be able to post stuff. Adopting a blog format here will let fans comment in context on the various stories, and will help to build an online community around TDB. News and tour events will likely spark the most discussion, so let’s group that all together. Additionally, the word “News” is a simpler, more general word that people will be able to recognise faster if they’re skimming a page for the information they want.
Our new “About The Dung Beatles” page groups together the band members’ biographies as well as their pictures. Going this route gives us a jumping off point for individual band member biographies. Following a similar argument to the one we made above, “About” is a common term used on a lot of web sites. Any time a visitor wants to learn more about a company, a product, a service, or an individual, they usually look for an “About” link.
Finally, the term “Discography” is a bit of a technical term. It’s possible that fewer people will understand what that term means than “The Music”. Also, it opens up this page to additional content: sources of inspiration, history of a particular song…you get the idea. I think we’re ready to roll. After I’ve talked a bit about naming pages sensibly, we’ll move on to add a little more detail about each page.

Naming your pages Page names can be one of the most crucial decisions you’ll make during web site design. Not only is it important for your visitors so that they can find their way around your web site; it is also another thing that dictates how easy your site is to find using a search engine (you’ll find various mentions of search engine optimisation throughout the course).
In general, search engines look at the text included in a web page, the URL of that page, and the text of any links to that page when they’re deciding “how important” it is. Giving your pages sensible names and sensible URLs will encourage anyone linking to your pages to use sensible descriptions.
Here’s an example. Let’s say you’re a car company, and you have a model called “The Speedster”. You’ve got a web site to promote your automobile, and one of the pages lists available features. Do you call this page “Features”, “Available Features”, “Features of the Speedster”, or “Bells and Whistles”? I would suggest that “Features of the Speedster” is the best option from this list. It’s specific to what the page contains, chances are that the title will be displayed high up on the page and will be prominent (good for search engine indexing), and you may even be able to fit it into the URL (something like “www.autocompany.com/speedster/speedster-features/”).

Adding some details You don’t have to figure out everything at this point, but you need to at least provide a brief description of what you have in mind for each page. After you’ve got the site structure, number each of your pages and provide a brief description for each page, like I’ve done in Figure 4 for the home page (you’ll get a chance to do this for the other pages in one of the exercises questions at the end of the article.)


Figure 4: Page Details for the Home page
This is about as involved as you want to get at this point. You don’t need to describe page functionality, the technology you’ll use to build it, or the design/layout in great detail. Just describe what you have in mind in general terms. Your goal here is to communicate what you’re thinking to your client and to force you to think things through.
It’s not uncommon at this stage to come to the realisation that you have too many pages, and you’ll never be able to find content for them. You can go crazy in creating a hierarchy of pages. For example, if the band members just wanted to publish one paragraph about themselves, it wouldn’t be necessary to create separate biography pages for each member. They could all be combined into a single page.

Summary This article has looked at the web site as a whole, and how you should think about structuring it. In the next article, you’re going to get taken down to the page level, and look at what goes into making a great web site: what features to include and where to include them. Articles 8, 9 and 10 then look at the visual design of a page. So this is being done in 3 logical steps (check it with the client at each stage to make sure they are happy with it):
1. First you decide on the content of a web site, and decide how to structure that content into pages.
2. Next you decide on the functionality that will actually be used on your web site.
3. The last thing you do before you actually start going ahead and coding your web site is work out the visual design of it—the page layouts, and the colour scheme, etc.

Exercise questions
• Look back at Figure 1 and try to develop a similar brainstorm for a web site about a car (pick any current or imaginary car).
o What will visitors to the web site want to know?
o Is there anything at existing car web sites that you see as essential? Frivolous?
• Take your brainstorm and try to organise the information. What page groupings make sense?
• Another activity that is sometimes useful when planning out a web site is to check out the competition. Do a search for band web sites (bonus points for tribute bands), and take a look at what they’re offering. Did we miss anything?
• Take a look at Figure 4 and try to develop similar figures for the other pages I’ve identified on the web site.

CSS3

CSS-Only form

A great example of a table-less form created by Jeff Howden. A real time saver for web developers:

http://jeffhowden.com/code/css/forms/

Link Thumbnail with CSS

A great way of previewing what the link you are about to click is about. Why send your users to a website they dont wanna go? Let them preview it through a thumbnail:

http://lab.arc90.com/2006/07/link_thumbnail.php

CSS Submit Buttons

Almost every single website has a form of some sort. Here’s a good way of treating your beloved form submit button. Great article:

http://www.ukthoughts.co.uk/journal/css…

Star Ratings

You see theese more and more. Mostly on CSS Galleries, Netflix, etc. Here’s a looooooong but very interesting article on how to put stars on your already-rocking website:

http://www.komodomedia.com/blog/2005/08/…

Target WHO?

Let users decide if they want to open a link in a new window or not. A good article on the subject:

http://webdesign.maratz.com/lab/new…

Oh yeah, the link above opens a new window :)

You will never ask about round corners again!

A massive set of techniques to create rounded corners with CSS. Some use images for the corners, some dont. Try the different methods and see what matches your preference. I personally think: The less images the better, but it all depends on what you are trying to create. Enjoy:

http://www.smileycat.com/miaow/archives/…

Photoshop-Style Drop Shadows with CSS

I was recently working on a project that required each uploaded image to have a drop shadow blow it. After searching all over the place, I found a really simple and comprehensive solution to the problem. Check this out:

http://theshapeofdays.com/….

CSS Tab Menus!

A great set of CSS Menus created by exploding boy. Take a look at the source code and notice how each menu code is segmented so that it’s easy to follow.

http://exploding-boy.com/images/cssmenus/menus.html

About CSS3.com

WHAT IS CSS

Cascading Style Sheets (CSS) are the modern standard for website presentation. When combined with structural markup language like HTML, XHTML, or XML (though not limited to these), CSS provide Internet browsers with the information that enables them to present all the visual aspects and elements of a web document. CSS apply things like borders, spacing between paragraphs, margins, headings on images, control of font faces or colors, background colors and images, textual effects like underlined or strike-through text, layering, positioning, and a number of other presentational effects. CSS controls the presentational aspects of a web page’s design, whereas HTML, XHTML, or XML control the
structure of a webpage, which means more than determining that certain text is a heading, other text is a paragraph, other text os a list of hyperlinks, and so on.

By using modern standards like CSS and XHTML, you can dramatically reduce the cost of building and maintaining a website when compared to legacy HTML-only pages. You can also greatly reduce the amount of physical bandwidth and hard disk space required, resulting in immediate long-term benefits for any webmasters and web visitor

CSS TUTORIAL

Cascading Style Sheets, commonly referred to as CSS, is a simple design language intended to simplify the process of making web pages presentable. Put simply, CSS handles the look and feel part of a web page or a whole website. With CSS, you can control the color of the text, the style of fonts, the spacing between paragraphs, how columns are sized and laid out, what background images or colors are used, as well as a variery of other effects and styles explained here.

The term cascading in Cascading Style Sheets refers to a specific way in which browsers determine which styles to apply to a specific part of the page. This method is called “the cascade”, and it’s from the cascade that CSS takes its name.

CSS3.com’s new style.

What do you think? approve? disapprove? Love it? Hate it?

I like the way all properties were easy to reach before. I will add a list of each one of them to the side menu very soon.

Also, Ive noticed I should have made each one of the properties a “page” and not a “post”. Is there a way to easily change that on wp?

New Version of HTML Launched...HTML 5

Abstract

This specification defines the 5th major revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability.

Browsable version-control record of all changes:

What Is CSS 3?

CSS 3 is the next version of the CSS (Cascading Style Sheet) specification, and a current working draft by the Wirld Wide Web Consortium (W3C). The draft attempts to monularize the specification to allow easier updating in the future. Here's the abstract of the current draft (retrieved December 10th 2007):

"The members of the CSS&FP Working Group have decided to modularize the CSS specification. This modularization will help to clarify the relationships between the different parts of the specification, and reduce the size of the complete document. It will also allow us to build specific tests on a per module basis and will help implementors in deciding which portions of CSS to support. Furthermore, the modular nature of the specification will make it possible for individual modules to be updated as needed, thus allowing for a more flexible and timely evolution of the specification as a whole."

Major Updates in CSS 3

In addition to modularization, there are several other major additions or changes in CSS 3. Here are the ones that should be most interesting to web designers.

• Multi-Column Layout
• New Selectors
• Improved Color Control

Multi-Column Layouts in CSS 3

The multi column layout module in CSS 3 adds functionality to flow the content of an element into multiple columns. This will be important in designing CSS layouts, because the space on wide screen resolutions can be more effectively used without forcing long lines of text.

Firefox has partial support of the functions of CSS 3 multi column layout: It supports -moz-column count, -moz-column width and a few other CSS attributes. They work like column-width and column-count in the CSS 3 draft module do.

CSS 3 Selectors

In addition to the selectors found in CSS 2, many additional selectors are added. The most useful of the many new CSS 3 selectors are the attribute selectors [a^=v], [a$=v] and [a*=v], and the nth-child selector.

With the attribute selectors, targeting only some elements is easy without the need of adding classes. Targeting all images from a certain location, all links with a certain relationship, etc. is very simple. The newest browser versions support these selectors, though some incompletely.

The nth-child selector allows highlighting of every other row in a table, of every other paragraph in a long piece of text, or many other meat tricks. The selector is supported partially by the current version of Firefox.

Color Improvements in CSS 3

The most widely supported and the most interesting addition to color handling in CSS 3 is alpha support. This functions both through opacity, and the new RGBA color values. Opacity works in all major browsers except Internet Explorer. RGBA colors are currently only supported by Safari 3 and Firefox 3 beta.

New Cascading Style Sheets Recommendation from W3C

The World Wide Web Consortium (W3C) today issued a Recommendation for Web style sheets. The Recommendation - Cascading Style Sheets, level 1 (CSS1) - gives Web designers a robust set of tools to help them specify Web page presentation properties such as fonts, colors and margins. Through links, CSS1 allows a single style sheet to apply to all Web pages on a site and thereby dramatically simplifying Web site maintenance. Also, a style sheet can be put inside a Web document and in detail specify how the document is presented. W3C Members have reviewed the CSS1 specification and support its adoption by the industry.
Microsoft and other software vendors have products that support CSS1; Netscape, Adobe, SoftQuad and Grif are among the W3C Members who will be adding support for CSS1 in their upcoming software releases.
With Hypertext Markup Language (HTML) content providers do not have the control they have in print media over color, text indentation, positioning, and other aspects of style. Today CSS1 offers a powerful and manageable way for authors, artists and typographers to specify the visual presentation of an HTML document or collection of documents.
"The Web's main document format, Hypertext Markup Language (HTML), was intentionally designed as a simple language that valued document structure over document presentation. However, with the commercialization of the Web, presentation of Web documents is becoming increasingly critical," said Tim Berners-Lee, Director of the W3C and creator of the World Wide Web. "CSS1 brings HTML authoring to the next level by effectively combining the structure and content of Web pages with powerful presentation capabilities. We look forward to the industry's further adoption of CSS1."
"CSS1 is a powerful tool. It can alter the look and feel of an entire web site simply by changing a single style sheet," said Håkon Lie, co-architect of CSS1. "CSS1 makes it very much easier to maintain a consistent style throughout the entire Web site. At the same time, CSS1 enables rich individual expressions that Web designers will appreciate."
Creative web designers have tried to bypass HTML's limitations by using images of text, which look like good typography but result in documents that cannot be searched, fed to speech synthesizers for visually impaired users, and do not print well. They have also used non-portable proprietary HTML extensions to gain control of spacing, and tables to simulate margins and indents. CSS1 allows designers to directly express the appearance they seek while retaining device-indepedent document structure, reusability, searchability and accessibility for the disabled.
"By separating the structure from the visual presentation of documents, we ensure the documents created today can also be displayed on the presentation devices of tomorrow," said Bert Bos, co-architect of CSS1. "HTML has become a universal storage format that will outlast current computers. CSS1, when used correctly, assures that documents can be preserved without sacrificing aesthetics on the Web."
It is expected that other specifications will build on CSS1 to provide support for Web fonts, speech style sheets, extended layout and printing capabilities. Also, W3C is actively working with its members to ensure that script-based applications can take advantage of style sheets. For example, a script attached to a Web page may dynamically alter properties, such as color, set in a CSS1 style sheet.
Please see attached fact sheet and testimonials document for additional information on CSS1.