January 1, 2008

Cascading Style Sheets Considered Harmful?

Filed under: — admin @ 11:41 pm

HTML wasn’t designed as a page layout language, but over the years presentation elements and attributes crept in. Tags that affect how a document is displayed became mixed with tags that define the document’s structure. The <font> tag became ubiquitous, as did the use of tables for page layout. Almost from the beginning, HTML for document presentation was almost inextricably intertwined with HTML for document structure. This led to endemic coding errors, such as the improper use of <hx> tags for their presentation effects rather than their intended use, which is to provide structure to a document.Cascading Style Sheets are the solution to this confusion. CSS allows you to define the presentation of each element. It goes even further than that; you can define the presentation (or style) of a whole set of elements, or of selected elements. For example, you could define the first paragraph in a document as having a 10% larger font than the following paragraphs. CSS provides a complex set of ways to select elements, and a rich set of properties that can be set for each element.

Like most things in life, though, cascading style sheets have both advantages and disadvantages.

CSS Advantages

1.

Separates content from presentation. What happens when you want to change the margins on all the pages of your site? If you use tables for layout, then you have to change every page. With CSS, just change the default style of the <body> tag. Instead of changing all pages, you only need to change one style sheet. Using CSS makes site-wide presentation changes a snap. That allows you to spend your time on page content and structure, not presentation.
2.

Replaces frames. A fundamental Web design rule is frames are bad. They can help site navigation, but even in the best case problems remain: pages can’t be bookmarked, and it’s impossible to specify a set of frames as a link destination. CSS’s ability to give elements a fixed or absolute position allow Web designers to do away with frames; the frame is now part of the page itself.
3.

Graceful degradation. A site that uses CSS well will be just as usable on browsers that don’t implement CSS as on those that do. The site might not appear the same, but all the important information will be present. This “graceful degradation” was built into CSS by its designers, and is an example of excellent design.

Ah, if only it were all this good.
CSS Disadvantages

1.

Fails as a frame replacement. While eliminating frames is a noble idea, it’s a goal that has not yet been reached. As of this writing (2002-01-24), CSS is a failure as a replacement for frames, due to broken CSS implementations in recent browsers (Amaya 5.3, Internet Explorer 6.0, K-meleon 0.6, Netscape 6.1, Opera 6.0).

To be specific, try creating an element with a fixed position that includes a link to a named anchor. None of the browsers listed above followed the link & rendered the resulting page correctly; does your browser?

This problem should be remedied in time, but I suspect that CSS fails as a frame replacement for another reason. Consider a site with one navigation frame and one content frame. If I understand CSS correctly, the contents of the navigation frame must be replicated in each of the content pages. That can lead to a maintenance nightmare. The situation can be worse: consider a navigation frame that offers three alternative navigation pages, such as a table of contents, a subject index, and a search page. Must each content page have three different versions, one per navigation page? Yow! The headache of exponential potential!
2.

A great power. Like any design tool, CSS requires practice and experience to use well. It offers great control over presentation; however, the more control a Web designer has over presentation, the more ways that designer has to make ugly and unusable documents. With great power comes great responsibility.

Consider the useful CSS Reference, 3rd edition at the House of Style. This edition is fine, but a previous edition used a style sheet that assigned the same background color to all header elements. This made it hard to distinguish headings from subheadings, since the primary visual cue (background color) made headers appear more similar, not less. (Here’s a demonstration of the problem, and a non-CSS version of the same.) This is the kind of problem style sheets were supposed to solve, not exacerbate. If a company that makes its living from CSS could make such a simple CSS mistake, what hope is there for amateur proficiency?
3.

CSS is not designed for horizontal layouts. CSS’s page layout model is to fill the page from the top down, flowing additional content off the bottom of the visible page. This vertical bias has its drawbacks. It’s not possible to make a multicolumn layout that scrolls new columns in from the side when needed. Also, unusual sites such as Scott McCloud’s Daily Improv (a horizontally scrolling comic) have to rely on HTML tricks to achieve their layouts.
4.

Hard to retrofit. It’s possible to retrofit a site with CSS, but when you have a site with almost three hundred HTML files containing over eighty thousand elements, visions of CSS become nightmares of editing hell.

Using CSS pays off when it’s a part of a site’s design from the planning stage on. Retrofitting a site, on the other hand, can involve more than simply peppering pages with class=”hot-quote” attributes. Converting a layout to CSS invariably requires adding new HTML elements (usually divs). So we’re still mixing semantic and presentation markup, which CSS was intended to separate.
5.

Makes downloading pages harder. If you want to save a copy of a Web page for offline viewing, you’ll have to do more work if the page links to style sheets. To get the page as it’s presented in your browser, you have to download not only the page’s HTML and the style sheets it links to, but also all of the style sheets they import, and so on down the chain of @import statements. Determining style sheet dependencies is a task that, while simple, must currently be done manually.
6.

Wastes time. Time spent twiddling style sheets is time not spent improving site content. How many people go to a site just to look at the pretty design? And what percent of those who do will have a reason to return? Content gives them a reason; design doesn’t.

Conclusion

Are cascading style sheets harmful? I can’t give a sage answer, since I’ve only been using them for a week or two, and there are CSS topics I’ven’t yet explored (e.g., printing). However, from what I have learned, I’ll offer this: CSS in moderation can be a good thing, but extensive use of CSS is harmful. It’s easy to improve page readability by modifying nothing more than the margins of the <body> and <p> elements. However, when you find yourself spending an entire day getting a style sheet just right, ask yourself what you could have done with the time instead: Writing new pages? Improving site navigation? Giving people a new reason to visit your site, rather than eye candy? One focuses on design at the expense of content, and CSS gives Web site designers a tempting tool for playing with design ideas. One must remember that search engines index content, not design.

Consider this lesson:

A student went to see his master. As he walked along a riverbank, he flushed a fox from its den. So startled was the student that he lost his footing and fell into the mud. With distaste he picked himself up from the muck and cleaned himself as best he could, then hurried on to his master’s house. When the master saw his student, he asked why the student cast his gaze downward. The student related the story of the fox, and apologized that he was no longer presentable. Then you must find a new master, said the wise man, for I do not know how to teach cloth.

Upon hearing these words, the student was enlightened.

source : http://www.rdrop.com/~half/Creations/Writings/TechNotes/CSS.html


January 6, 2008

World Wide Web Consortium issues Web Ontology Language candidate recommendations; Emerging ontology standard, OWL, strengthens Semantic Web Foundations.

Filed under: — admin @ 9:11 pm

The World Wide Web Consortium (W3C) issued Web Ontology Language (OWL) as a W3C Candidate Recommendation. Candidate Recommendation is an explicit call for implementations, indicating that the document has been reviewed by all other W3C Working Groups, that the specification is stable, and appropriate for implementation.OWL is a language for defining structured, Web-based ontologies which enable richer integration and interoperability of data across application boundaries. Early adopters of these standards include bioinformatics and medical communities, corporate enterprise and governments. OWL enables a range of descriptive applications including managing web portals, collections management, content-based searches, enabling intelligent agents, web services and ubiquitous computing.

“OWL is an important step for making data on the Web more machine processable and reusable across applications, ” said Tim Berners-Lee, W3C Director. “We’re encouraged to see OWL already being used as an open standard for deploying large scale ontologies on the Web.”

OWL is specified in 6 documents: The OWL Overview; OWL Semantics and Abstract Syntax; OWL Use Cases and Requirements; OWL Test Cases, OWL Guide, and the OWL Reference. Read the FAQ…

Source : http://goliath.ecnext.com/coms2/gi_0199-3205814/World-Wide-Web-Consortium-issues.html


Technology Reports of XML and Encryption:

Filed under: — admin @ 9:11 pm

The World Wide Web Consortium (W3C) has announced the publication of XML Encryption Syntax and Processing and Decryption Transform for XML Signature as W3C Recommendations, signifying a “cross-industry agreement on an XML-based approach for securing XML data in a document. A W3C Recommendation indicates that a specification is stable, contributes to Web interoperability, and has been reviewed by the W3C Membership, who favor its widespread adoption.” The Encryption document “specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” The Decryption Recommendation “specifies an XML Signature ‘decryption transform’ that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate.”

W3C Specifications for XML Encryption Released as Proposed Recommendations. The W3C XML Encryption Working Group has released Proposed Recommendation specifications for XML Encryption Syntax and Processing and Decryption Transform for XML Signature. Pending review of comments from the W3C Advisory Committee Members and the public, the specifications may reach Recommendation status after November 14, 2002. The XML Encryption document “specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” The Decryption document “specifies an XML Signature ‘decryption transform’ that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate. XML Encryption is a method whereby XML content can be transformed such that it is discernable only to the intended recipients, and opaque to all others. There are many applications for such a specification given the increasing importance of XML on the Internet and Web including the protection of payment and transaction information.” [Full context]

XML Encryption Candidate Recommendation. XML Encryption Syntax and Processing. W3C Candidate Recommendation 02-August-2002. Edited by Donald Eastlake and Joseph Reagle.Second W3C Candidate Recommendation from the XML Encryption Working Group. “This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” See the “XML Encryption Implementation and Interoperability Report.”

[March 04, 2002] W3C XML Encryption Working Group Releases Candidate Recommendation Specifications. The W3C XML Encryption Working Group has published an updated XML Encryption Requirements document and has approved the release of XML Encryption Syntax and Processing and Decryption Transform for XML Signature as Candidate Recommendation specifications. The working group expects to meet the exit criteria for the two CRs, but solicits additional feedback (until April 25, 2002) based upon on implementation experience. The requirements specification outlines “the design principles, scope, and requirements for XML Encryption; it includes requirements as they relate to the encryption syntax, data model, format, cryptographic processing, and external requirements and coordination.” The core specification for XML Encryption Syntax and Processing defines “a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element which contains (via one of its children’s content) or identifies (via a URI reference) the cipher data. When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document. When encrypting arbitrary data (including entire XML documents), the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document.” The Decryption Transform document ” specifies an XML Signature “decryption transform” that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate.” [Full context]

[January 25, 2001] W3C Approves XML Encryption Activity. Joseph Reagle (W3C Policy Analyst, IETF/W3C XML-Signature Co-Chair) posted an announcement to the Public XML Encryption List ‘xml-encryption@w3.org’ indicating that an official W3C XML Encryption Activity has been approved. The XML Encryption Charter has been reviewed by the W3C Advisory Committee, Team, and Director. The [draft] charter says, in part: “The mission of this working group is to develop a process for encrypting/decyrpting digital content (including XML documents and portions thereof) and an XML syntax used to represent the (1) encrypted content and (2) information that enables an intendent recipient to decrypt it. XML Encryption is a method whereby XML content can be transformed such that it is discernable only to the intended recipients, and opaque to all others. There are many applications for such a specification given the increasing importance of XML on the Internet and Web including the protection of payment and transaction information. The proposed work will obviously address how to encrypt an XML documents including elements. The following additional requirements must be met by the WG; these requirements must be augmented and extended by the Requirements Document deliverable: (1) The mechanisms of encryption must be simple: describe how to encrypt/decrypt digital content, XML documents, and portions thereof. a) Only enough information necessary for decryption need be provided. b) The specification must not address authorization, authentication, nor the confidence or trust applications place in the provision of a key though it should enable (or at least not hinder) such XML based technologies. (2) XML-Encryption must be coordinated with and use the work product of other mature XML technologies including XML Schema and XML Signature. (See Coordination) (3) The mandatory portions of the specification must be implemented in at least two independent implementations before being advanced to Proposed Recommendation. The core scope of this activity will be in specifying the necessary data model, syntax, and processing to encrypt XML content. The Working Group (WG) will: (1) Specify a requirements document that further defines the scope and requirements of the WG’s deliverables. (2) Specify the syntax and processing necessary for creating XML Encryption content. The WG should decide what level of granularity is appropriate with the meta-requirement that the design be simple to implement and quickly deployable. (3) Choose a data model (and representation via XML element types or URIs) for describing any necessary public characteristics of the encrypted content (e.g., the data encrypted is an http://someURI#elementNode). The WG must use pre-existing models such as Information Set, XPath, SetX, or DOM. (4) Choose a method (that can be optional) to canonicalize XML prior to encryption such that it can be decrypted consistently. The WG must use a pre-existing canonicalization method such as Canonical XML. (5) Specify a minimal set of encryption and key information for interoperability purposes. This may be a separate document or part of the specification. (6) Address security concerns arising from the design and its implementation. This may be a separate document or part of the specification. (7) Optionally, develop a document of scenarios and recommendations regarding the affects and requirements of XML Encryption processing on XML parsing and validation. This must be a separate document. (8) Redefine the charter for subsequent work once (1-7) has been achieved. The requirement document must specify and describe the WG’s choice with respect to the granularity of encryption, the data model and representation resulting from that choice, and the necessity and choice of canonicalization algorithms. The WG must rely upon existing W3C specifications as building blocks to its own design, unless the WG can demonstrate these specifications fail to meet the requirements of XML Encryption applications. In which case the WG must give a strong rationale and obtain Director approval.” The web site for the XML Encryption WG is publicly accessible.

source: http://xml.coverpages.org/xmlAndEncryption.html


XML Trust Services - XKMS:

Filed under: — admin @ 9:12 pm

The XML Key Management Specification (XKMS) initiative was jointly developed by VeriSign, Microsoft and WebMethods as an open standard to simplify the securing of XML-based Internet transactions using PKI and digital certificates. The ability to secure all Web Services communications and transactions is critical for the success of Web Services in the enterprise.

With XKMS, developers can integrate authentication, digital signature, and encryption services, such as certificate processing and revocation status checking, into applications in a matter of hours - without the constraints and complications associated with proprietary PKI software toolkits.

Features and Benefits:

1. Easy to develop
The XKMS specification allows developers to rapidly implement trust features, incorporating cryptographic support for XML digital signatures and XML encryption using standard XML toolkits. The developer-friendly syntax used in XKMS eliminates the necessity for PKI toolkits and proprietary plug-ins.

2. Quick to deploy
XKMS moves the complexity associated with PKI deployment to the server side components. Developers can now focus on their core competency of developing applications rather than the complexities surrounding a PKI deployment.

3. Open Standards
The XKMS specification has been submitted to the World Wide Web Consortium (W3C) as an open standard for distribution and registration of keys. The common XML vocabulary used to describe authentication, authorization, and profile information in XML documents makes XKMS services completely platform, vendor, and transport-protocol independent.

4. Future-proof
By restricting the impact of future PKI developments and advancements to the server-side components, XKMS protects developers and applications from becoming incompatible with the latest developments in PKI.

source: http://www.verisign.com/developer/xml/xkms.html


January 15, 2008

SMIL Root Element Attributes

Filed under: — admin @ 9:27 pm

QuickTime SMIL Extensions define the following additional attributes for the <smil> element:

* autoplay: Specifies whether the resulting presentation should automatically start playback upon instantiation. Legal values are either “true” or “false,” and the default is “false.” Common usage is:

<smil qt:autoplay=”true”/>

* next: Specifies to the player that after this presentation is finished, the presentation referenced in the attribute value should be invoked and played in the same space. Used to chain presentations together. A valid attribute value is any URL. This capability is equivalent to the QuickTime browser plug-in’s “qtnext” attribute. Common usage is:

<smil qt:next=”nextpresentation.smi”/>

* time-slider: Specifies whether a time line should be displayed as part of the user interface. Because by default the QuickTime playback engine dynamically loads media objects as required, the duration of the overall media presentation can change as a movie is played or navigated. When the duration changes, the time line will change to reflect that. This can be unnecessarily confusing to the user. Therefore, by default, QuickTime movies created from a SMIL document do not display a time line as part of their user interface. This behavior can be overriden using the “time-slider” attribute. Common usage is:

<smil qt:time-slider=”true”/>

* immediate-instantiation: Specifies whether the media objects within the presentation should be instantiated immediately, i.e., at the same time the presentation itself is instantiated, or whether instantiation should be deferred until the element is ready to be played back. Legal values are either “true” or “false,” and the default is “false.” The value of this attribute may be overridden on a media-object basis by using it as an attribute to individual media-object elements, as described below. Because this attribute causes all media objects to be instantiated, it can take considerable time and memory for a complex presentation or one being loaded over a slow network connection. Therefore, it is recommended that it only be used on small media objects. Common usage is:

<smil qt:immediate-instantiation=”true”/>

* chapter-mode: Specifies to the player, both QuickTime Player and the Movie Controller, the way in which chapters should be used in the user interface when a time line is part of the interface. The chapter-mode attribute can have a value of “all” or “clip”. If the attribute is not present, the default value is “all”. If the chapter-mode attribute is “all”, then the player displays the time line of the entire duration of the presentation. Each chapter represents a point along that time line. If the chapter-mode attribute is set to “clip”, then the time line no longer represents the entire duration of presentation. Instead, it represents the duration of the current chapter. The “clip” behavior is useful for long presentations where the granularity of the timeline may be unacceptably low. It is also useful for network-based presentations, particularly those using streaming media, where the actual duration of a clip isn’t known until it has started to play. By using the “clip” value of the chapter-mode, the user will not be exposed to the duration changes of the presentation caused by the loading of media as the presentation is played or navigated. Common usage is:

<smil qt:chapter-mode=”clip”/>

source : http://gemma.apple.com/documentation/QuickTime/REF/QT41_HTML/QT41WhatsNew-9.html



 
 
ERP systemen
Alle ERP-systemen op een rij, compleet met ERP-nieuws en ERP-software informatie.
www.ERPcentraal.nl
ERP systemen
Alle ERP-systemen op een rij.
www.erpmatrix.nl


Quick Links
Our Friends
Cool Places
Visit also
About Us