" + data); _AN_Call_write('write', document, data); } else{ try{ var xsl = new ActiveXObject("Microsoft.XMLDOM") var myxml = new ActiveXObject("Microsoft.XMLDOM") myxml.async = false; myxml.loadXML(text); xsl.async = false xsl.load(xsl_url); x = xsl.documentElement.childNodes; for (i = 0 ; i < x.length; i++){ var attrs = x[i].attributes; if(x[i].namespaceURI == "http://www.w3.org/1999/XSL/Transform" && (x[i].baseName == "import" || x[i].baseName == "include")){ var attr = attrs.getNamedItem("href"); if(attr != null){ x.item(i).setAttribute("href", _AN_full_url(attr.nodeValue)); } } } // Transform var content = myxml.transformNode(xsl); _AN_Call_write('write', document, content); } catch(e){ alert(e.description); } } } _AN_Display_xml(); year and a half later, is it still a better choice?

Lea: Yes, I still think SVG is a better choice. It was created for this purpose, and it allows for many more things than even CSS3 does. However, it still doesn't have the adoption it deserves, which I mainly attribute to the following reasons:

  1. Difficult syntax. SVG allows us to do crazy things, but with most of the times just as crazy and complicated syntax. It makes sense once you understand how each feature works, but the learning curve is very steep. Especially since there's no debugging tool that helps you understand what you did wrong and very little information about browser support, so you might get stuck wondering if you misunderstood something or it's just not supported.
  2. Not enough resources. This is kind of a chicken and egg thing. If not enough people fiddle around with SVG, not enough people write tutorials, so not enough people are inspired to learn SVG. The few resources that exist are either very simple examples for beginners or academic stuff without much relevance to applied work (and both are usually ugly as f***, turning designers away).
  3. Hard to understand specifications. While CSS and HTML specs are reasonably easy to understand for the most part, a big part of the SVG specs requires university-level Computer Graphics and Linear Algebra knowledge. Even if you have that kind of knowledge, it's still hard. Given the lack of good SVG resources mentioned above, this hurts SVG adoption much more than meets the eye.
  4. Laziness. People like what's familiar, what they already know. If they can avoid learning something new, most will.
  5. Browser support issues. SVG brings its own set of browser bugs to the table, most of which are far less documented than CSS & HTML bugs. This is also a chicken and egg thing: The more developers use a certain technology, the highest priority its bugs get. Currently there are SVG bugs that are left unresolved for years, because not enough people use it.

I think however that there's lots of untapped potential in SVG, especially now that we can embed it in HTML5 documents. It's hidden there, waiting to be discovered. We just need more creative minds to start playing with it.

*Chris: What is your CSS wish? Something that you regularly wish you could accomplish with CSS but can't. Perhaps an existing feature with very limited browser support. Or something completely outside the current spec and discussions around the spec.

Lea: My favorite CSS3 feature that doesn't have enough implementations yet is the CSS3 generalization of attr(). In CSS2.1, we can use attr() in the content property, to use attribute values in generated content. In CSS3, we're supposed to be able to use attr() in every property, which will greatly reduce presentational JavaScript code. Unfortunately, only IE9 supports it, and not fully. If only developers realized how many use cases it simplifies and started pushing browser vendors for it!

But I also have lots of not yet existing features in my CSS wishlist:

and many, many more. When it comes to CSS, I'm a big dreamer :)

*Chris: Thanks, Lea!

Five Questions with Lea Verou is a post from CSS-Tricks

]]> http://css-tricks.com/14792-five-questions-with-lea-verou/feed/ 33 A Call for ::nth-everythinghttp://css-tricks.com/14771-a-call-for-nth-everything/ http://css-tricks.com/14771-a-call-for-nth-everything/#comments Mon, 31 Oct 2011 14:33:54 +0000 Chris Coyier http://css-tricks.com/?p=14771 We already have ::first-letter and ::first-line which are useful. Why not expand those out into a full set of selectors that follow the same pattern of the ::nth-child family? I attempt to make the case here.

A Call for ::nth-everything is a post from CSS-Tricks

]]>
With CSS3, we have positional pseudo class selectors to help us select specific elements when there are no other distinguishing characteristics other than where it is in the DOM in relation to it's siblings.

:first-child
//AN_Xml::last-child
//AN_Xml::nth-child
//AN_Xml::nth-last-child
//AN_Xml:
//AN_Xml::first-of-type
//AN_Xml::last-of-type
//AN_Xml::nth-of-type
//AN_Xml::nth-last-of-type
//AN_Xml:
//AN_Xml::only-child
//AN_Xml::only-of-type

We also get a couple of text-specific pseudo elements to help with our typography needs:

::first-letter
//AN_Xml:::first-line

That's a great start, but it really would be useful if we could extend the whole ":nth" concept to these typographic selectors. Let me convince you.

Please note that most of the code below is not valid. It's example code. Like "wouldn't it be cool if" code.

::nth-line() / ::last-line / ::nth-last-line()

We already have ::first-line, so to complete the set let's add ::nth-line(), ::last-line, and ::nth-last-line().

With these, we could select the first two lines of a poem to highlight.

article.poem p:first-child::nth-line(-n+2) {
//AN_Xml:  font-variant-caps: small-caps;
//AN_Xml:  color: red;
//AN_Xml:}

I don't know from poetry, Brendon.

Or perhaps we could fade out the end of a passage.

article.poem p:last-child::nth-last-line(3) {
//AN_Xml:   color: hsla(26, 5%, 25%, 1);
//AN_Xml:   font-size: 70%;
//AN_Xml:}
//AN_Xml:article.poem p:last-child::nth-last-line(2) {
//AN_Xml:   color: hsla(26, 5%, 50%, 1);
//AN_Xml:   font-size: 60%;
//AN_Xml:}
//AN_Xml:article.poem p:last-child::nth-last-line(1) {
//AN_Xml:   color: hsla(26, 5%, 75%, 1);
//AN_Xml:   font-size: 50%
//AN_Xml:}

If we were allowed to use generated content on these line pseudo elements, we could accomplish something like line numbering without having to resort to intrusive markup.

pre::nth-line(n)::before {
//AN_Xml:  content: counter(line) ". ";
//AN_Xml:  color: #999;
//AN_Xml:}

Look ma, easy practical multi-line code styling.

Relevant article by Adam Prescott.

::nth-word() / ::first-word / ::last-word / ::nth-last-word()

We currently don't have any word-based pseudo elements. We do have word-spacing though, which is notable.

One use case is similar to using ::first-letter for drop caps, only doing a whole word.

article p::first-word {
//AN_Xml:  float: left;
//AN_Xml:  font-size: 300%;
//AN_Xml:  margin: 0 10px 10px 0;
//AN_Xml:}

Also similar to the "fade out" of lines above, we could fade out a passage word-by-word using ::nth-last-word(n).

::nth-letter() / ::last-letter() / ::nth-last-letter()

We already have ::first-letter, which sees pretty decent usage, so why not complete the set?

Of all of these "new" selectors, ::nth-letter is likely the most useful. For instance, Lettering.js wraps letters in <span>s for us so that we can select individual letters. This would be entirely unnecessary with ::nth-letter.

Take this example:

h1.fancy::nth-letter(n) {
//AN_Xml:  display: inline-block;
//AN_Xml:  padding: 20px 10px;
//AN_Xml:}
//AN_Xml:h1.fancy::nth-letter(odd) {
//AN_Xml:  transform: skewY(15deg);
//AN_Xml:  background: url(light-red-pattern.png);
//AN_Xml:}
//AN_Xml:h1.fancy::nth-letter(even) {
//AN_Xml:  transform: skewY(-15deg);
//AN_Xml:  background: url(dark-red-pattern.png);
//AN_Xml:}
//AN_Xml:h1.fancy::nth-word(n) {
//AN_Xml:  margin-right: 20px;
//AN_Xml:}
//AN_Xml:h1.fancy::last-word {
//AN_Xml:  margin-right: 0;
//AN_Xml:}

Check out all the examples at Lettering.js -- all of those are good examples of the need for this.

Another word/letter combination example is a formal "letter", like:

<p>Dear Emily,</p>
//AN_Xml:<p>yadda yadda yadda.</p>
//AN_Xml:<p>Love, Chris.</p>

Perhaps this "letter" is generated by dynamic content from a database, but we want to ensure the proper capitalization and style of the opening and closing lines.

.letter p:first-child::nth-word(-n+2)::nth-letter(1),
//AN_Xml:.letter p:last-child:nth-word(-n+2):nth-letter(1) {
//AN_Xml:  text-transform: uppercase;
//AN_Xml:}

The Complete Set

So if we get all of this, the complete set would be:

:first-child        :first-of-type        :only-child
//AN_Xml::last-child         :last-of-type         :only-of-type
//AN_Xml::nth-child          :nth-of-type
//AN_Xml::nth-last-child     :nth-last-of-type
//AN_Xml:
//AN_Xml:::first-letter      ::first-line          ::first-word
//AN_Xml:::last-letter       ::last-line           ::last-word
//AN_Xml:::nth-letter        ::nth-line            ::nth-word
//AN_Xml:::nth-last-letter   ::nth-last-line       ::nth-last-word 

Again, just wishful thinking. If there is anyone I can put this in front of that can do something about it, I will. And I'll also keep this updated with the feedback on it, positive or negative.

For the record, this isn't a new request. Anne van Kesteren called for it in 2003.

A Call for ::nth-everything is a post from CSS-Tricks

]]>
http://css-tricks.com/14771-a-call-for-nth-everything/feed/ 67
//AN_Xml: