Your search for stts returned 9 results.

Friday 30 September 2011

Selectors 3 and CSS Namespaces Module are RECs

At the end of 1998, a while after the release of CSS 2, I took an action item in the CSS Working Group to become the author/editor of a new beast in our Group, a module... CSS 2 was already a big big change from CSS 1. And when I say 'big', it means the spec switched from the 15 printed pages of CSS 1 to the hundreds of CSS2. So we decided to 'modularize' CSS 3. Since I already worked a lot on Selectors and even implemented them before, this was a natural choice for me.

At the beginning of january 1999, my first draft was ready. It's unfortunately not public and the original document was lost when I left my employer a year later (Electricité de France, fwiw). The second draft though is still available, although in a web space restricted to CSS WG Members, sorry for that... The first public draft, dated 03-aug-1999 is available here. You can see that in that document, the :subject pseudo-class, corresponding to the $ descriptor present in the current Selectors 4 draft, was present... Alas, it was later removed because of browser vendors expressing implementation concerns. That pseudo, a top request from the Web Authors' community, originally came from something I specified and implemented myself in my transformation language based on the CSS syntax/grammar: STTS3.

Despite of what I could call a poor support from implementors at that time, I also decided to add major new stuff to Selectors:

  • the :nth-child() and friends pseudos, captured from an early draft of XSL/XPath I found impressive. I really wanted them to be able to style table rows, columns and cells. For the record, the an+b syntax of the argument was proposed by Tantek Çelik's father.
  • the :target pseudo, proposed by Håkon Lie. Håkon did not suspect the power of that pseudo at that time, until I found a super-interesting use case for that pseudo... See the demo (in a browser implementing :target, of course...).
  • the indirect adjacent combinator ~, that was really missing.

Then namespaces and the negation pseudo :not() arrived, and the spec changed only a little bit between 2000 and now, waiting for browser implementations, a completed Test Suite and interoperability.

Today, after more than 12 years, I am happy. Really happy and a bit proud too I must say. Older, but happy :-) My baby just became a W3C Recommendation, after the hard work of many people who caught the flag and became editors of the document and/or the Test Suite... Yay!

Similarly, the original CSS Namespaces proposal, authored by my co-chair Peter Linss during the Netscape era (gosh, time flies...) became a REC yesterday after too many years of wait. Yay again !

All in all, the CSS Working Group released 5 new W3C Recommendations between the beginning of june 2011 and now ! Wooohooo !

So where are we now? Selectors 4 start emerging, and I would like to issue here a clear and loud warning with my CSS WG Co-chair hat on: this is an early stage draft and the presence of a feature in that document does not imply IN ANY WAY that the final specification will contain it and that browser vendors will offer support for it. In particular, I already noticed the major response of the community to the presence of the subject selector and the matches-any functional pseudo-class. Guys, please cool down... These two features still represent a real implementation challenge for browsers and I just cannot tell if they will remain in the spec or disappear from it. Please note, this is not the first time - as I wrote above - such features are included into a Selectors draft... Been there, done that.

Don't misunderstand me ! I am not saying these features will never ever reach a browser near you ! I am only saying standardization is a complex process also based on implementability of the features we design AND browser vendors' strategies. Be optimistic, but also be realistic. Thanks.

Thursday 27 March 2008

Ten years...

Almost ten years ago, I submitted a Note to the Consortium called STTS 3. That Note was about a very simple transformation language reusing the CSS general syntax and the selectors. Since some of the basic transformations you need to apply to a document to move from Tag Soup to something usables needed to select elements based on descendants or successors, I introduced the :subject simple selector to describe the subject of the current selector.

In other words, div > p selects p element inside a div while div:subject > p selects divs containing a p. So many people in the web designers community ask for it there's no question it's one of the top enhancement requests for CSS.

This simple selector was always rejected based on implementation and performance but today, we have this line in the CSS WG meeting agenda :

Selectors: Changing the Subject (":subject")

Well. I implemented it back in 1998 in a tool entirely compliant with the CSS general syntax :-) Eheh :-) Not sure it's going to be discussed today because we have a lot of important things on our radar but still, please allow me to consider it as a big victory...

Wednesday 25 July 2007

about JQuery

I have read with great interest John Resig's post about JQuery. I must admit I could not help but say "D'OH!" when I saw his JQuery example because the syntax seems to me totally ugly. I also think mixing that way selectors and JS is not nice, from both a practical and theoretical approach. I would a thousand times prefer something like:

div.section ul {
  add-class: sectionlist;
  hide: normal;

div.section.header h1 {
  font-size: 20pt;
  onclick: { ul.sectionlist {
               show: normal;

Basically, JQuery seems to me a successor to the pair Action Sheets + STTS. I definitely agree on JQuery's interest, but I think a CSS-based general syntax would have been much more readable, more practical, more expandable, and of course more integrable with CSS.

John, if you ever read this article and are willing to discuss this, feel free to ping me.

Thursday 29 March 2007


Olivier just made us a few minutes ago his first demo of his STTS processor ! YAY !!!! Stay tuned !

Wednesday 7 March 2007


Just FYI, we're working on an STTS processor in cross-browser JavaScript (for the record, STTS is basic but powerful transformation language based on the CSS general syntax ; see this old and obsolete document) that could be embedded in web pages. No preview yet, but the thing is already very mature. Stay tuned :-)

Tuesday 24 October 2006

Composer progress

work in progress
  • "save" feature
  • 356951 new serializer "à la tidy"
  • we are very seriously pondering an STTS implementation for Composer

Monday 27 March 2006


The best cross-platform implementation of document.getElementsBySelector(), cross-platform, and implementing all of CSS 3 selectors but dynamic pseudo-classes and pseudo-elements + a few enhancements coming from STTS.

It's made by Olivier Gambier, it's cool, it's a new implementation report for the Selectors spec on its way, it's here.

Congrats Olivier !

Thursday 2 March 2006

WOW !!!!

People, something major just happened in the CSS Working Group today. And I just cannot believe it happened :-)

Back in **1997**, I submitted a proposal to the W3C. That proposal, STTS 2 later updated into STTS 3, was about a simple transformation language based on the CSS general syntax. For the record, STTS 2 was the first document submitted to W3C in more than one language (french and english) and language negociation will serve you the doc in french if your locale is french and english otherwise. I proposed STTS during a now famous CSS meeting held at Electricité de France's R&D site in Clamart. Transformations in CSS were "proposal number 19" on a list of suggested extensions to CSS. At that time, we were probably 20 people in the Working Group. ALL (but me of course) rejected the idea. "Proposal number 19" became a big joke but I am proud to keep in my mailbox a personal email from Håkon saying (IIRC) "Daniel, I must congratulate you for the submission of STTS. This is a use of CSS that we never thought of in the beginning."

But the proposal 19 was trashed, and only a japanese company and I ever implemented STTS. Only two things really survived : first the definitions of what is a condition, a chain of selectors, a simple selector in the current CSS 3 Selectors spec come from my work on STTS. Then the idea of using selectors on the right hand side of CSS declarations also comes from STTS.

I got a lot, really a lot, of feedback from web authors asking me to implement STTS inside Mozilla. I never found the time to do it.

And today, STTS came back officially on the CSS WG's table. Håkon even showed us a proposal equivalent to my STTS baby. We have now an Action Item to sit together in the near future and work on that, and possibly and FINALLY come up with a proposal allowing to declaratively insert a table of contents in a document, reorder elements, sort elements. Something HIGHLY readable and understandable that does not require the presence of an XSLT expert to decipher things.

People, it took NINE BLOODY YEARS but this is VERY exciting. I am excited. Wow !!!

Long ago, in this very same CSS WG, I told a new and now famous member of the Group, Tantek Çelik, that you always have to bring a proposal three times on the table. The first time, it's immediately rejected ; the second time, it's rejected but discussed ; the third time, it's accepted.

" First they will laugh at you, then they will fight you. Then you win. " -- Gandhi

Sunday 28 December 2003


How did I miss that?!? I have always been a strong supporter (and most certainly the first one) of the presence of selectors on the right hand side of CSS declarations (a CSS declaration is made of a property name followed by a colon followed itself by argument(s) and an optional semi-colon being the separator with the next declaration; of course, whitespace is allowed almost everywhere). I have myself used selectors there in my STTS language. And I only discover now that selectors on the right hand side of CSS declaration absolutely need, for parsing reasons, to be contained into a functional notation (like url(...) or attr(...)) unless the selector is the sole argument of the property. If this is not the case, you can't make the difference between "a b", "selector(a) b", "a selector(b)" and "selector(a) selector(b)" if both a and b are IDENTs. So it means that we need a general functional notation to encapsulate selectors on the right hand side of declarations in all cases, including the proposed new attr() notation.

I therefore propose two new functional notations. I don't think they can be gathered.

  1. condition(selector), represents a condition on the elements or pseudo-elements of a tree, exactly like the current usage of selectors in CSS
  2. fragment(selector), represents the complete flat description of a tree fragment, exactly like in STTS

PS: you win my deep consideration if you are not a former or present W3C Working Group member and if you can guess right what means the title...