XSLT and CSS for XML rendering. Don't use special characters


The three most common ways to convert an XML document into a user-displayable form are:

Applying styles CSS;

Application XSL;

Writing an XML document handler in any programming language.

Without using CSS or XSL An XML document displays as plain text in most web browsers. Some browsers such as Internet Explorer And Mozilla Firefox display the document structure as a tree, allowing you to collapse and expand nodes using mouse clicks.

Applying css styles.

The process is similar to applying CSS To HTML-document for display.

For applying CSS When displayed in a browser, the XML document must contain a specific reference to the style sheet. For example:

This is different from the HTML approach, which uses the .

Application xsl.

XSL is a family of recommendations that describe languages ​​for transforming and visualizing XML documents. The document is transformed into a format suitable for display in a browser. Browser- this is the most frequent use XSL, but do not forget that using XSL you can transform XML into any format, for example VRML, PDF, text.

For the task XSL transformation ( XSLT) on the client side, the following XML instructions are required:

xml dictionaries

Since XML is a fairly abstract language, XML vocabularies have been developed.

A dictionary allows developers to agree on a finite set of tag names and the attributes of those tags. One of the first dictionaries is XHTML, which most browsers understand. XHTML is often used to store and edit content in CMS.

More specialized vocabularies have been created, such as data transfer protocol SOAP, which is not human-oriented and quite difficult to read. There are commercial dictionaries such as CommerceML, xCBL And cXML which are used to transmit trade-oriented data, these vocabularies include descriptions of the ordering system, suppliers, products, etc.

Usually, when describing a document, a person comes up with some vocabulary for himself, which is then described using DTD or simply explained “on the fingers” to interested parties.

One of the most widely used dictionaries is FB2- a dictionary describing the format of the book, with all sorts of footnotes, quotations, even pictures.

What does an xml document look like?

If you are familiar with HTML, learning XML will not require much effort on your part. Although XML is certainly very different in its capabilities and intent from HyperText Markup Language, both languages ​​are subsets of SGML, and therefore inherit its basic principles.

Document structure

A simple XML document might look like Example 1

First

Second subparagraph 1

Third

Last

Just like in HTML, instructions enclosed in angle brackets are called tags and serve to mark up the main text of the document. In XML, there are opening, closing, and empty tags (in HTML, the concept of an empty tag also exists, but no special designation is required).

The body of an XML document consists of markup elements and the actual content of the document - data (content). XML tags are intended to define document elements, their attributes and other language constructs. We will talk in more detail about the types of markup used in documents a little later.

Any XML document must always begin with an instruction, inside which you can also set the language version number, code page number and other parameters necessary for the analyzer program in the process of parsing the document

How to use XML correctly

XML as a ToolCommonly Used Abbreviations
  • CDATA: Character Data
  • DOM: Document Object Model ( object model document)
  • E4X: ECMAScript for XML (ECMAScript for XML)
  • IDE: Integrated Development Environment (integrated development environment)
  • W3C:World Wide Web Consortium (WWW consortium)
  • XML: Extensible Markup Language
  • XSLT: Extensible Stylesheet Language Transformations

XML is now taken for granted. He's everywhere! But if you look from the outside, you can see that this is a powerful technology. There are integrated development environments that help you build XML trees. There are a number of technologies for checking the correctness of XML code. There is XSLT - a special language XML transformations. XML support is even built directly into the syntax of some languages ​​(such as E4X in ActionScript).

But XML also has back side. It can be used incorrectly. It can be used poorly. It can be overly complex. It may be underspecified. He can be difficult to work with. What needs to be done for more effective use this powerful technology? In my article I will give 10 tips that will help answer this question.

Don't use XML as a file name or root tag

Many times I have seen XML code stored in files with .xml extension. It is pointless. This extension won't tell me anything that I don't already know just by running cat. As soon as I see the tags, I immediately know it's XML. Instead of this extension, use an extension that makes sense to the user. You can also use a unique extension to have Google searches return links to documentation or examples of your XML file format.

Another problem in some XML documents is the use of the root tag. This again means nothing. What's in this file? If this is a list of contacts, the root node should be the tag. XML needs to be readable, so use tag and attribute names that are relevant to the business problem you're working on. If the root node is , I expect to see the tags , and then the tags , , , etc.

Don't override generic or language-specific constructs

I understand that XML is a format for saving data. Most languages ​​provide a way to store data structures in XML. It's good if you are sure that only processes written in the same language will ever read or write your XML code. This, however, is rare. If your application writes something to a file, it is likely that at some point in time it will be read by a user or some application in another language.

By this I mean that language-specific constructs should be stored outside of XML. How often have you met 07-18-2010? What is NSDate? Yep, this is the name of the class for working with dates on the application platform. What happens when I change platform or language? The NSDate tags will need to be converted to something else that is used on the new platform.

Keep language specifics outside of XML and use simple tags, say ... . Such a tag is easy to understand, readable, and independent of a specific language or framework.

Another important rule– Avoid using unnecessary generalizations in XML. Take a look at next example ():

Listing 1. Generalized jack node tree

What does this mean? I realized that this is a list of users. But it is difficult for a person to read and edit. What's worse is that this XML is very difficult to use in tools like XSLT or validate against a schema. B shows what the above XML code actually means.

Listing 2. A more efficient jack node tree

Isn't it better this way? The code says what it says and means what it says. It is easier to read and analyze. It is easier to validate and transform using XSLT. It's even smaller in size.

Don't make files too big

I know what you will say: " Disk memory it's cheap. For ten cents I'll buy another terabyte." That's true. You can indeed create gigabyte XML files. But programming is about constant compromises. You have to change disk space for a time or memory for a time. And when working with a huge XML file, you get the worst of both. The file takes up a lot of disk space, and analyzing and checking it takes a lot of time. Besides, large file eliminates the use of a DOM parser, since building the tree takes infinite time and huge amount memory.

What is the alternative? You can create multiple files. One acts as an index, and the others contain large resources that may not be needed by all users of this XML. Another option is to remove all large CDATA fragments from the XML file and put them in your own own files with your own formats. If you want to keep all data together, pack all files in new file with a new extension. Any popular programming language has modules that make it easy to quickly pack and unpack files.

Don't use namespaces unless absolutely necessary

Namespaces are a powerful part of the XML lexicon. They facilitate the implementation of extensible file formats. You can determine basic set tags for all your application's needs, and then allow users to add their own data to their own namespace in the file without affecting your object tree.

However, namespaces make it very difficult parsing and data management. They confuse programming language extensions such as E4X. They make it difficult to use XML in XSLT. Finally, they make XML files much more difficult to read.

Therefore, only use XML namespaces if you really need them. Don't use them simply because "XML allows it." XML works fine without namespaces.

Do not use Special symbols

All of my tips are aimed at keeping your XML code clean, simple, and easy to read. In this sense, even the XML specification allows a lot that is not necessarily used. For example, you can use a dash in the names of elements and attributes. But this makes it very difficult to use such XML code in language extensions such as E4X. The question is, is it worth it?

Use XML Schema

Parsing XML is not an easy task. For an accurate analysis, a lot of work needs to be done to protect the code from possible absence and incorrect use of tags or attributes. This extra work on writing code, added complexity, and also obscuring the real business logic that is your main concern. How to avoid this? Validate XML before using it. Several standards can be used for this. You can specify a Document Type Definition (DTD) or an XML Schema (links to information about DTD and XML Schema are provided in the section). Personally, I find XML Schema much easier to work with, but if you're new to this, try out the various validation systems.

The big advantage is that once the XML is checked for correctness, you can be confident in it. This may not be necessary for your application's internal XML files. But it is very useful if the XML is generated by another application or written manually.

Number the versions

It's very easy to lose sight of the fact that XML stored in files is equivalent to a file format. The first thing a file of any format must contain is a version number. It's easy enough to add: ... . The code reading the file must check that the version number is not greater than this current version, and throw an exception if it is not. This ensures that any subsequent versions of the code will not conflict with older versions when using new tags. Of course, you must ensure that all older versions of the files are supported as you continue to develop your application.

Combine Nodes and Attributes

Engineers are pretty lazy people. I can say this because I am like that myself. Don't argue, we are all like that. If the IDE offers to do the XML export for us, we'll probably agree. But typically the framework produces very bad XML. You've probably already encountered something similar to:

Listing 3. List of users 1 jack

Should it be a tag? I argue that it should be an attribute. The code becomes shorter and more meaningful, and it becomes possible to search for a user by ID using a simple XPath expression (/users/user[@id=1]).

To make the code readable, it is undoubtedly better to use attributes, as shown in .

Listing 4. A more convenient list of jack users

It is clear that the framework generated , because it is always safer to use nodes. But attributes allow you to identify important elements in the DOM tree, so you should use them.

Use CDATA, but don't overuse it

XML places many restrictions on the use of certain characters: quotation marks, ampersands, less than and greater than signs, etc. However, in practice these symbols are used very often. So you either have to convert everything to an XML-safe format, or put large chunks of text, code, or whatever into CDATA blocks. It seems to me that developers avoid using CDATA because they think it will make parsing difficult. But CDATA sections are no more difficult to parse than anything else - most DOM parsers handle them themselves, so you don't even have to think about it.

Another important reason to use CDATA is to preserve accurate data formatting. For example, when exporting a Wiki page, you will probably want to preserve the exact positions of characters such as carriage return and line feed, since they play a special role in the Wiki format.

Why not use CDATA partitions all the time? Because they make the document very difficult to read. This is especially annoying when they are not needed. So, use them and encourage users to use them in your XML files in situations where you expect the data to contain special characters and where you want to preserve the original formatting. But don't use CDATA in other situations.

Store optional data in a separate area

So far I've talked about rigidly formatted XML documents. I even recommended using a validation technology (such as XML Schema) that guarantees a rigid structure. Tom has good reason: Structured data is easier to analyze. What if you need some flexibility? I recommend placing optional data in a separate block in its own node. Take a look, for example, at .

Listing 5. Out-of-order record for user jack d herrington 8:00

This record contains all the expected user data. I agree with first, middle, last, but why is runningspace here? It's necessary? Will you have many of these fields? Will they be expandable? If the answer to all these questions is yes, I would recommend doing this (see):

Listing 6. Well-structured post for user jack d herrington 8:00

With this approach, you can have as many fields as you like without cluttering the parent element's namespace. You can even check the validity of this document and access a specific field using an XPath expression (//user/userdata/field[@name="runningpace").

Conclusion

Consider what I have said. I have recommended five things to do and five things to avoid. Not all of my advice will apply in all circumstances. Sometimes XML is just a format for storing data transmitted over the network and lasting only a few milliseconds. In this case, there is no need to worry about anything. But when using XML as a file format, you should take my advice and apply the recommendations presented here.

The standard defines two levels of correctness for an XML document:

  • Well-formed. A properly constructed document meets all general rules XML syntax applicable to any XML document. And if, for example, a start tag does not have a corresponding end tag, then this incorrectly constructed XML document. A document that is not properly constructed cannot be considered an XML document; The XML processor (parser) should not process it normally and should classify the situation as a fatal error.
  • Valid. A valid document additionally meets some semantic rules. This is a more stringent additional check of the document’s correctness for compliance with predetermined, but already external rules, in order to minimize the number of errors, for example, the structure and composition of a given, specific document or family of documents. These rules can be developed both by the user himself and third party developers, for example, developers of dictionaries or data exchange standards. Usually such rules are stored in special files- diagrams where the most in detail the structure of the document, all valid names of elements, attributes and much more are described. And if a document, for example, contains an element name that is not previously defined in the schemas, then the XML document is considered void; When checking for compliance with rules and schemas, the checking XML processor (validator) is obliged (at the user's choice) to report an error.

These two concepts do not have a well-established standardized translation into Russian, especially the concept valid, which can also be translated as valid, legitimate, reliable, fit, or even tested for compliance with rules, standards, laws. Some programmers use established tracing paper in everyday life " Valid».

XML syntax

This section only discusses correct construction XML documents, that is, their syntax.

XML is a hierarchical structure designed to store any data; visually the structure can be represented as a tree. The most important mandatory syntactic requirement is that the document has only one root element (alternatively called a document element). This means that the text or other data of the entire document must be located between the only one a start root tag and its corresponding end tag.

Next simplest example- a well-formed XML document: This is a book: "Book" The first line of an XML document is called an XML declaration - this is an optional line indicating the version of the XML standard (usually 1.0), character encoding and external dependencies can also be specified here. The specification requires XML processors to support Unicode encodings UTF-8 and UTF-16 (UTF-32 is optional). Other encodings based on the ISO/IEC 8859 standard are recognized as acceptable, supported and widely used (but not required); other encodings are also acceptable, for example, Russian Windows-1251, KOI-8.

A comment can be placed anywhere in the tree. XML comments are placed inside a pair of tags. Two hyphens (--) cannot be used anywhere within a comment.

Below is an example of a simple culinary recipe, marked up using XML:

Plain bread Flour Yeast Warm water Salt

Structure

The rest of this XML document consists of nested elements, some of which have attributes And content. An element typically consists of opening and closing tags that surround text and other elements. The opening tag consists of the element name in angle brackets, for example, " "; The closing tag consists of the same name in angle brackets, but a forward slash is added before the name, for example, " ". The content of an element is everything between the opening and closing tags, including text and other (nested) elements. Below is an example of an XML element that contains an opening tag, an end tag, and the content of the element:

Knead again, place on a baking sheet and put in the oven.

Flour

In the example above, the ingredient element has two attributes: amount, which has the value 3, and unit, which has the value glass. From the point of view of XML markup, the above attributes do not have any meaning, but are simply a set of characters.

In addition to text, an element can contain other elements:

Mix all ingredients and knead thoroughly. Cover with a cloth and leave for one hour in a warm room. Knead again, place on a baking sheet and put in the oven.

IN in this case the "Instructions" element contains three "step" elements. XML does not allow overlapping elements. For example, the following snippet is incorrect because the "em" and "strong" elements overlap.

Regular accented highlighted and accented highlighted

Each XML document must contain exactly one root element document element), so the following fragment cannot be considered a valid XML document.

Entity #1 Entity #2

To denote an element with no content, called an empty element, necessary use a special form of recording consisting of a single tag in which a slash is placed after the element name. If an element is not declared empty in the DTD, but it has no content in the document, for it allowed use this form of recording. For example:

XML defines two methods for writing special characters: entity reference and character reference. An entity in XML is named data, usually text, in particular special characters. Entity references are specified where the entity should be and consist of an ampersand (“&”), the entity name, and a semicolon (“;”). There are several predefined entities in XML, such as “lt” (you can refer to it by writing “< ») для левой угловой скобки и « amp » (ссылка - « & ») для амперсанда, возможно также определять собственные сущности. Помимо записи с помощью сущностей отдельных символов, их можно использовать для записи часто встречающихся текстовых блоков. Ниже приведён пример использования предопределённой сущности для избежания использования знака амперсанда в названии:

AT&T

The complete list of predefined entities consists of & (“&”),< (« («>""), "(""), and "("") - the latter two are useful for writing delimiters within attribute values. You can define your entities in a DTD document.

Sometimes it is necessary to determine non-breaking space, which is very often used in HTML and is denoted as there is no such predefined entity in XML, it is written, and its use causes an error. The absence of this very common entity often comes as a surprise to many programmers, and this creates some difficulties when migrating their HTML developments to XML.

A numeric character reference looks like an entity reference, but instead of the entity name, it uses the # character and a number (in decimal or hexadecimal notation) that is the Unicode character number. These are typically characters that cannot be encoded directly, such as an Arabic letter in an ASCII-encoded document. The ampersand can be represented as follows:

AT&T

There are many more rules regarding creating a valid XML document, but the purpose of this brief overview It was just to show the basics necessary to understand the structure of an XML document.

Story

The year of birth of XML can be considered 1996, at the end of which a draft version of the language specification appeared, or when this specification was approved. It all started with the appearance of the SGML language in 1986.

SGML (Standard Generalized Markup Language) has declared itself as a flexible, comprehensive and comprehensive meta-language for creating markup languages. Despite the fact that the concept of hypertext appeared in 1965 (and the underlying principles were formulated in 1945), SGML does not have a hypertext model. The creation of SGML can be confidently called an attempt to embrace the immensity, since it combines capabilities that are extremely rarely used all together. This is its main drawback - the complexity and, as a consequence, the high cost of this language limits its use only by large companies that can afford to buy the appropriate software and hire highly paid specialists. In addition, small companies rarely have problems that are complex enough to involve SGML in solving them.

SGML is most widely used to create other markup languages; it was with its help that the hypertext document markup language was created - HTML, the specification of which was approved in 1992. Its appearance was associated with the need to organize the rapidly increasing array of documents on the Internet. The rapid growth in the number of connections to the Internet and, accordingly, Web servers has resulted in such a need for coding electronic documents, which SGML could not cope with due to its high learning curve. The advent of HTML, a very simple markup language, quickly solved this problem: its ease of learning and wealth of document design tools made it the most popular language for Internet users. But as the number and quality of documents on the Web grew, so did the requirements placed on them, and the simplicity of HTML became its main drawback. The limited number of tags and complete indifference to the structure of the document prompted developers represented by the W3C consortium to create a markup language that would not be as complex as SGML and not as primitive as HTML. As a result, combining the simplicity of HTML with the markup logic of SGML and meeting the demands of the Internet, XML was born.

Strong and weak sides Advantages Flaws
  • Modeling ambiguity.
  • XML does not have data type support built into the language. It does not have strong typing, that is, the concepts of “integers”, “strings”, “dates”, “booleans”, etc.
  • The hierarchical data model offered by XML is limited compared to the relational model and object-oriented graphs and network model data.
Display XML in World Wide Web

The three most common ways to convert an XML document into a user-displayable form are:

  • Applying CSS styles;
  • Applying an XSLT transformation;
  • Writing an XML document handler in any programming language.

    • Without the use of CSS or XSL, the XML document appears as plain text in most Web browsers. Some browsers such as Internet Explorer, Mozilla and Mozilla Firefox display the document structure in a tree view, allowing you to collapse and expand nodes with mouse clicks.

    Application CSS styles

    The process is similar to applying CSS to an HTML document for display.

    To apply CSS when rendered in the browser, XML document must contain a specific link to the style sheet. For example:

    This is different from the HTML approach, which uses the .

    Applying an XSLT transformation

    XSL is a technology that describes how to format or transform XML document data. The document is transformed into a format suitable for display in a browser. The browser is the most common use of XSL, but don't forget that with XSL you can transform XML into any format, e.g.

    In order to automatically convert the contents of xml files into a human-readable form/format (html, rtf, pdf, txt, vrml, svg, java, etc.), you should use XSLT instead of trying to use CSS.

    Disadvantages of CSS:
    1. CSS cannot change the order of elements in an xml document. If you want to sort some elements or filter them by some property, then CSS will definitely not help you with this.
    2. CSS doesn't do calculations. If you want to calculate and display a value (for example, sum numeric values all elements in the xml document), CSS will not suit you.
    3. CSS cannot merge documents. If you want to combine a couple of dozen XML documents with purchase orders and print a summary of all the ordered products, then CSS again will not help you.

    A small example of using XSL

    There is some plugin settings xml file:


    The plugin controls the settings of AutoCAD drawing layers. Below is a table listing the items being checked.

    Checking the layer name
    true
    Checking the layer name for compliance with the naming rule

    Checking the Layer Color
    true
    Checking that the layer is assigned colors from the "Index Color" palette

    Line type check
    true
    Checking that layers are assigned linetypes only from a certain set

    Checking line thicknesses
    true
    Checking that layers are assigned line weights only from a certain set

    Checking for a note
    true
    Each layer must have a note deciphering its purpose

    Fixed layer set
    false
    Should users be prohibited from creating additional layers, according to the rules established in the Standard?

    The plugin must read the settings from it and work in accordance with them. At the same time, there must be some documentation that the user can read and understand. Moreover, the material presented in the documentation must correspond to the settings that are currently set. In order not to keep in mind that after you adjust the settings, you need to go and edit the documentation, you can present all this in the form of one xml file. The plugin will read the settings from it, and the user will open it in the browser and... see it in a “human” form... To do this, create a file styleSheet.xsl with the following content:

    Plugin settings

    Parameter Meaning Note

    Now, if a user opens our xml file in a browser, he will see not confusing (from his point of view), inconvenient xml text, but this:

    IN in this example I did not show selection, sorting, filtering, various types of operations and calculations (they were not needed here), but if necessary, all this can be done using XSLT.

    5 answers

    What your heart tells you is right. Although it is possible to use CSS for XML, XML itself has no semantics. CSS is for the web, for HTML, and for providing (good) semantic data.

    XML is more general than that. XSLT was invented to convert one data format to another (XSLT 1.0 XML only, XSLT 2.0 any Unicode data format), i.e. XML to HTML or XML to XSL-FO or other XML format or text. XSL-FO was invented to put XML on paper or screen and is much more verbose than CSS.

    Some Pros and Cons of CSS + XML

    Mostly cons, esp. in light of the use of XML in the browser. Skip the general advice below if you don't want all my ramblings; -)

    CSS minus 1: no CSS + XML for the web

    Con: This is highly context dependent, but if you want to use XML for web display, think again: don't use XML, convert it to HTML. Then use CSS + HTML to display your data. If you are using XML on the web, no search engine or seeker, do not understand the difference between and , but they will understand the difference between and .

    This in itself is reason enough to use XSLT to convert to HTML + CSS and exclude the XML yourself.

    CSS cons 2: CSS means a lot more work

    Other extremely important reason which you can use: XML + CSS means defining each element in CSS. Using HTML + CSS means that user agents already know the default layout properties for all elements. Using XML+ XSLT means you typically create HTML + CSS. You have to do this on the server side, since client-side XSLT is not very reliable or cross-browser compatible.

    CSS cons 3: accessibility

    (sorry, I can't find a pro). If the XML doesn't have semantics (SVG, as another user mentioned), there's no point in using CSS for the layout. If the layout is supposed to be semantically understood by the user agent, XML + CSS doesn't work. Text to speech reader has no idea what to do, WAI validity (availability) will be impossible, etc.

    CSS cons 4: maintainability, understandability, scripting, problems

    Using XML makes it difficult to do any client side scripting (yes, the DOM is accessible, but how do you tell the browser what the script -tag is? But maybe it will respond to , but hey, you need XSLT to get that tag there) and makes it difficult its cross-browser (some browsers have difficulty using XML as such). Anything HTML (eg meta, title, body, script) will not be available. There is no way to add title attributes or tell the browser what the image is (afaik).

    Without the script will only work for you for the XML page (prototype.js? jquery.js? ajax? no no and no).

    Anyone looking at your code should know what each tag means. Using XSLT to convert to HTML prevents this. This extra step is useful and should be applied every time you move from XML to browser display.

    Benefits of CSS 1: For Domain

    If your domain is SVG, SMIL, OD or something else, you probably already know this: CSS is an integral part of the specification and must be used. This is completely different from pure, possibly unstructured XML data.

    AJAX thought

    Just for comparison: any asynchronous AJAX call (should) return XML. But any library that works with it will either interpret it as HTML, or use XSLT or some other means to transform it before entering it into an existing page.

    Based on the note from the OP, we're looking at XML data(not SVG or OpenDocument) and needs to be rendered in browsers. Accessibility and indexability are not important. But that doesn't really matter: you shouldn't use only XML + CSS unless you're really going on some kind of adventure and want to know all the shortcomings of XML in browsers, want to come up with every one again HTML tag and define each and everything, only to give up time and fall back to HTML (XML + XSLT == HTML + CSS).

    Update: added cons 2
    Update: added cons 3 and pro 1
    Update: added cons 4, AJAX note and conclusion

    If your XML code is beautiful enough to individual elements layout, use CSS if you need more work adapting it for display, then use XSLT. Things like arbitrary reordering of content or collapsing multiple lists of values ​​into a table, etc. are not amenable to CSS. CSS really only works well if your general structure document is already the same one that you want to display.

    There's nothing inherently wrong with using CSS to style XML, it's just not very common (although I've done it in the past as an experiment).

    Source document

    A document to which one or more style sheets are applied. This is encoded in some language that represents the document as a tree of elements. Each element consists of a name that identifies the element's type, optionally a number of attributes, and (possibly empty) content. For example, the source document may be an XML or SGML instance.

    Document language

    The encoding language of the source document (such as HTML, XHTML or SVG). CSS is used to describe the presentation of document languages, and CSS does not change the underlying semantics of document languages.

    (My accent).

    The main features to consider when deciding whether to use CSS versus XSLT are as follows:

      Does it make sense to transform an XML document into another structure (such as XHTML) to better represent the semantics of the document?

      Is the document's semantic structure sufficient on its own so that only the presentational style needs to be applied?

    If you have fairly arbitrary and meaningless XML - something like 1foo - then the XSLT route makes sense. If, however, you have a document that has its own well-defined semantics (for example, an SVG file or any of several XML applications), and all you want to do is make the headings stand out and the font look nice, then CSS is great.

    In the end, the simplest thing, which could work. CSS - by at least, from version 2 onwards - was specifically designed to be language agnostic (i.e. not tied to HTML), so there's no reason not to use it when it makes sense.
    

    2024 gtavrl.ru.