It has been suggested that I use CSS for displaying XML. I know in my heart that this is wrong, but cannot find the words to adequately convince others. Can anyone provide me with a list of pros/cons of using CSS and XSLT for displaying XML.
Thanks!
What your heart tells you is correct. Though it is possible to use CSS for XML, XML itself does not have any semantics. CSS is meant for the web, for HTML and for giving semantic data a (good) look.
XML is way more general then that. XSLT is was invented for transforming one data format to another (XSLT 1.0 only XML, XSLT 2.0 any Unicode data format), i.e., XML to HTML or XML to XSL-FO or another XML or text format. XSL-FO was invented for laying out XML on paper or screen and is much more detailed then CSS.
Some pros and cons on CSS+XML
Mainly cons, esp. in the light of using XML in a browser. Skip to the overall advice below if you don't want all my babbling ;-)
CSS cons 1: no CSS+XML for internet
The cons: it depends a lot on the context, but if you want to use XML for display on the internet, think again: don't use XML, but transform it into HTML. Then use CSS + HTML to display your data. If you use XML on the internet, no search engine or crawler, will understand the difference between <x> and <y>, but they will understand the difference between <h1> and <h2>.
This alone is enough a reason for using XSLT to transform to HTML + CSS and avoid XML on its own.
CSS cons 2: CSS means lots more work
The other extremely big reason you can use: XML + CSS means defining each and every element in CSS. Using HTML + CSS means user agents already know the default layout properties for all elements. Using XML + XSLT means usually you create HTML + CSS. You should do this on server side, because client side XSLT is not very reliable and cross-browser compatible still.
CSS cons 3: accessibility
(sorry, I can't find pros) Unless XML has semantics (SVG, as mentioned by another user), it makes little sense to use CSS for layout. If the layout is supposed to be semantically understood by a user agent, XML + CSS is a no-go. Text-to-speech readers have no idea what to do, WAI (accessibility) validity will be impossible etc.
CSS cons 4: maintainability, understandability, scripting, trouble
Using XML makes it hard to do any client side scripting (yes, the DOM is available, but how do you tell the browser what the script-tag is? But perhaps it'll react to <script>, but hey, you need XSLT to get that tag in there) and makes it hard to make it cross-browser correct (some browsers have a hard time using XML per se). Anything HTML (like meta, title, body, script) will not be available. There's no way to add title attributes or to tell the browser what an image is (afaik).
No script in existence will work on you XML-only page (prototype.js? jquery.js? ajax? no no and no).
Anybody looking at your code will have to learn what each tag "means". Using XSLT to transform to HTML, prevents this. This extra step is beneficial and should be applied whenever you go from XML to browser display.
CSS pros 1: domain specific
If your domain is SVG, SMIL, OD or anything else, you probably already know this: CSS is an integral part of the specification and should be used. This is completely different from pure, possibly unstructured, data XML.
AJAX thought
Just for comparison: any asynchronous AJAX call (should) return XML. But any library working with it, will either interpret it as HTML, or will use XSLT or another means to transform it prior to injecting it in an existing page.
Overall advice
Based on the remark from the OP, we are looking at data XML (not SVG or OpenDocument) and it needs to be displayed in browsers. Accessibility and indexability are not important. But that doesn't really matter: you shouldn't use XML + CSS alone, unless you're really into some adventure and want to find out all the shortcomings of XML in browsers, want to invent every HTML tag again and define each and everything, only to give up after a while and revert to HTML (XML + XSLT == HTML + CSS).
Update: added cons 2
Update: added cons 3 and pros 1
Update: added cons 4, AJAX note and a conclusion
CSS:
Styling and overall visual presentation
XSLT:
Styling and visual presentation (if desired)
Allows complete and radical changes of the actual tree that's rendered
If your XML maps pretty nicely to individual layout elements then use CSS, if you need more work in adapting it for display, then use XSLT. Things like arbitrary re-orderings of content or collapsing multiple lists of values into a table, etc. don't lend themselves well to CSS. CSS really only works nicely if your overall structure of the document is already the same you want to display.
CSS seems to fail for XML in IE8: How to apply CSS to namespace prefixed elements in IE8?
There is nothing inherently wrong with using CSS to style XML, it's just not done very often (although I've done it in the past as an experiment).
Take SVG as an example: it's XML, and it can be styled with CSS. Also, have a look at section 3.1, "Definitions", of CSS 2.1:
Source document
The document to which one or more style sheets apply. This is encoded in some language that represents the document as a tree of elements. Each element consists of a name that identifies the type of element, optionally a number of attributes, and a (possibly empty) content. For example, the source document could be an XML or SGML instance.
Document language
The encoding language of the source document (e.g., HTML, XHTML, or SVG). CSS is used to describe the presentation of document languages and CSS does not change the underlying semantics of the document languages.
(My emphasis).
The primary possibilities to consider in deciding whether whether to use CSS as opposed to XSLT strike me as being:
Does it make sense to transform the XML document into a different structure (e.g. XHTML) the better to represent the semantics of the document?
Is the semantic structure of the document sufficient in itself, such that only presentational styling needs to be applied?
If you have some pretty arbitrary and meaningless XML - something like <data><column><row><value>1</value><value>foo</value></row></column></data> then the XSLT route would make sense. If however you have a document that has its own clearly defined semantics (e.g. an SVG file, or one of any number of XML applications) and all you want to do is make the headings stand out and the font look nice, then CSS is fine.
Ultimately, do the simplest thing that could possibly work. CSS - at least from version 2 onwards - was specifically designed to be language-agnostic (that is, not tied to HTML) so there's no good reason not to use it when it makes sense.
Did they mean a stylesheet? Any XML Stylesheet is different to a CSS stylesheet. XSL is sometimes refered to as a Stylesheet so you might both be right :)
Related
Maybe this is a stupid question, but what is the difference between XSL and CSS? They are both styling sheets. When would you want to use one over the other. I looked around and saw that CSS is generally used before XSL when possible... but why?
XSL is used to refer to a family of languages used to transform and render XML documents.
CSS is a style sheet language used for describing the presentation semantics (the look and formatting) of a document written in a markup language.
Hence XSL and CSS are not the same and not interchangeable. While XSL languages are used to impact the structure of XML documents (i.e. the arrangement of the tags) CSS is used to impact the visual formatting of those tags.
Edit: There are no stupid questions, just badly researched ones ;)
Assuming you are talking about XSLT rather than "XSL" (the latter term should be avoided because it is used in different ways by different people):
CSS provides a great deal of capability for rendering content. This capability is increasing all the time.
XSLT focuses on transforming content.
For example, you can write a report that groups, sorts, and summarizes data in XSLT, but you can't do so in CSS. Until recently CSS couldn't alter the content in any way, for example by rendering <cite>3</cite> as [3].
You should use XSLT and CSS together. Use CSS for the pure rendering parts of the job, and XSLT for the transformation parts.
With the availability of Saxon-CE in the browser, you can also start to use XSLT for handling user interaction, such as responding to clicks by showing or hiding data: the kind of things you would otherwise have to do in Javascript.
I need to collect data from a visitor in an HTML form and then have them print a document with the appropriate fields pre-populated. They'll need to have a couple of signatures on the document, so it has to be printed.
The paper form already exists, so one idea was to scan it in, with nothing filled out, as an image. I would then have the HTML form data print out using CSS for positioning and using the blank scanned form as a background image.
A better option, I would think, would be to automatically generate the PDF with this data, but I'm not sure how to accomplish either.
Suggestions and ideas would be greatly appreciated! =)
I would have to respectfully disagree with Osvaldo. Using CSS to align on a printed document would take ages to do efficiently in the aspect of cross-browser integration. Plus, if Microsoft comes out with a new browser, you're going to have to constantly update for the new use in browsers.
If you know any PHP (Which, if you know JavaScript and HTML, basic PHP is very simple), here's a good library you can use, FDPF:
Thankfully, PHP doesn't deprecate a whole lot of methods and the total code is less than 10 lines if you have to go in and change things around.
You can control printed documents acceptably well with CSS, so I would suggest you to try that option first. Because it's easier.
This is actually a great php library for converting HTML to PDF documents http://code.google.com/p/dompdf/ there are many demo's available on the site
XSL-FO is what I would recommend. XSL-FO (along with XSLT and XPath) is a sub-standard of XSL that was designed to be an abstract representation of a formatted document (that contains, text, graphic elements, fonts, styles, etc).
XSL-FO documents are valid xml documents, and there exist tools and apis that allow you to convert an XSL-FO documet to MS Word, PDF, RTF, etc. Depending on the technology you use, a quick google search will tell you what is available.
Here are a few links to help you get started with XSL-FO:
http://en.wikipedia.org/wiki/XSL_Formatting_Objects
http://www.w3schools.com/xslfo/xslfo_intro.asp
http://www.w3.org/TR/xsl11/
Regarding inline v. internal v. external CSS, I understand the cacheing issues, and the tradeoff between multiple downloads and single downloads of larger files. What I would like to know is how rendering speed varies, based on the three places you can put CSS.
In other words, what takes the least time to actually draw the page? I assume that external is the slowest, because even if it's cached, the browser still has to retrieve the rules, parse them, and apply them to the current elements. I also assume that internal (in the page but inside style tags) would be second slowest, because there's still the process of parsing the rules and determining which rules to apply to which elements. And I assume that inline (applied directly via style attribute) is the fastest, because the browser can skip the process of matching rules to elements.
Anybody ever looked at this in depth? I know that I've had some rendering problems on large pages with complex CSS that could only be solved by going inline. (Please, no lectures on the evils of large pages with complex CSS.)
either way, once the actual rule text is loaded, it's run through the same css parser - there aren't different parsers for external v.s. internal css. it's all just css. External might be a bit slower to get applied because it'll require an extra HTTP request to fetch that file, but once it's transferred to the host browser, it'll parse just as fast as if you'd physically embedded the same rules in an inline <style> block.
I don't think you should care which mode is fastest. HTML, CSS and JS are not meant to be fast in any case.
I think you should worry about readability and maintainability, think about managing a webpage with styles directly applied inside HTML tags. You wouldn't be able to manage anything complex in that way.
What you are asking mainly depends on browser implementation (with respect to the css file that could be downloaded separately according to which solution we are talking about). In any case I don't think the difference is so much considerable just because they all need to be parsed by the same parser.
If a page is really too complex to be styled with a stylesheet and requires inline style then the problem should be solved not by having inline css but refactoring things at a different level.
In addition I would say that many performance issues could be caused by writing CSS just without any kind of structure, just adding things day by day without even considering having strict/clever selectors. Developing things while thinking about them (that is something that is usually left behind in web development, especially with front ends) usually is the best way.
I am new to Asp.net and i saw many tutorials talking about css and Html and Xml Style sheet so please can anyone tell me what is the difference between those 3 Languages and what they are used for ? Also i want to know if we need to know HTML since when i was training on visual studio i saw that it is automatically generated when we add a control from the tool box . Thc for any help .
HTML is a markup language for describing the semantics and structure of documents.
CSS is a language for describing how to present documents written in markup languages.
XSL is a collection of specifications for presenting and manipulating documents written in markup languages.
[Do] we need to know HTML since when i was training on visual studio i saw that it is automatically generated when we add a control from the tool box
Yes. Visual Studio generates pretty poor markup.
The WikiPedia pages for HTML, XML and CSS will have a ton of information, as well as links to a ton more information. So I'll just address the second part of the question...
If you're doing web development, it's definitely in your best interests to learn these things, especially HTML. Sure, Visual Studio will generate stuff for you and all you have to do is drag and drop widgets onto a form. However, if you don't actually know what it's doing for you or understand how the tool works then you're seriously limiting yourself.
Sometimes dragging an ASP .NET server control onto the form and setting a few properties is the best (as in quickest and easiest without significant side-effects) way to accomplish a particular task, sometimes it isn't. If you're familiar with only one tool then you can only do what that one tool is designed to do. You'll end up trying to fit other tasks into the scope of that tool, with potentially dismal results.
Visual Studio has a history of generating poor HTML. It's certainly improved over the years, but it's not something on which you want to rely. You can create simpler, more efficient, and ultimately easier to support code by having a better understanding of the underlying technologies involved and putting in a little work yourself.
I think you did not search for these:
HTML - Tutorial
HTML, which stands for HyperText
Markup Language, is the predominant
markup language for web pages. A
markup language is a set of markup
tags, and HTML uses markup tags to
describe web pages. HTML is written in
the form of HTML elements consisting
of "tags" surrounded by angle brackets
(like ) within the web page
content. HTML tags normally come in
pairs like and . The first tag
in a pair is the start tag, the second
tag is the end tag (they are also
called opening tags and closing tags).
Example:
<html>
<body>
<h1>My First Heading</h1>
<p>My first paragraph.</p>
</body>
</html>
Cascading Style Sheets - Tutorial
Cascading Style Sheets (CSS) is a
style sheet language used to describe
the presentation semantics (the look
and formatting) of a document written
in a markup language. Its most common
application is to style web pages
written in HTML and XHTML, but the
language can also be applied to any
kind of XML document, including SVG
and XUL.
Example:
<style type="text/css">
body {color:red;}
h1 {color:#00ff00;}
p.ex {color:rgb(0,0,255);}
</style>
XML - Tutorial
Extensible Markup Language (XML) is a
set of rules for encoding documents in
machine-readable form. It is defined
in the XML 1.0 Specification
produced by the W3C, and several other
related specifications, all gratis
open standards.
Example:
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
I have been developing web apps for a while now and for the past year I have been really exploring as many technologies as possible. I know some people are creating pages using XML and XSLT or maybe css style sheets; however, it seems to me that the trends are still not moving in direction. Plus it seems less functional/easy than XHTML/CSS based pages.
What are the benefits of using XML/XSLT, and is it ideal to start developing in that manor? Is there anything else new that is pulling ahead of the pack in regards of front end web development?
The reason I am bringing this stuff up is because it seems that many people are switching from XML as a datasource to JSON, which makes more sense as a datasource; however, XML is still functional as a markup language...
And on that note, why would I even want to use XSLT vs CSS for the XML pages if i were to start develop that way. It seems to me that they serve the same purpose except that XSLT looks like tag soup.
I hope this question makes sense....
XSLT can be useful if you have an XML data source that needs transforming into HTML. Otherwise you should be using HTML, CSS and jQuery for front-end development.
Right now, there is no reason to use XSLT at all. It's virtually incomprehensible compared to XML/XHTML, and offers no real advantage for you or your users.
As for using XML in lieu of (X)HTML, with the growing acceptance of the emerging HTML5 standard, I can't see why you'd give up canvas and the (eventually, they'll be good!) audio capabilities for XML. Even now, XML is nice for marking up documents, but for marking up a webpage, HTML is king – it's essentially XML tailor-made for the web.
There is no antagonism between XML/XSLT and XHTML/CSS, these are complementary technologies. Thus, in my web apps, XHTML pages are produced by mean of XML/XSLT (transformation occurs in client side).
You'd use XSLT to transform some XML document into XHTML. Then you'd use CSS to style the XHTML.
XSLT is for transformation of one XML format into another. The data stays the same, but the representation changes. There is even XSLT-FO, which transforms XML into other objects, like pdf.
Also note, XSLT can be used client-, or serverside. You can do XSLT transformation in the browser or with a simple handler on the server. Java-based nonsql data stores like existdb use XQUERY to transform database entries with XSLT to any other XML format, including XHTML.
Using XSLT to generate XHTML from simple XML documents basically gives you a templating engine.
Since browsers still lack XFORMS support, you can use javascript+XSLT to transform XFORMS into valid HTML.
JSON is used to serialize and deserialize objects and transport them, thus replacing XML as a transport format, more specifically as a AJAX query response, in rich internet applications.