CSS and style

Cascading Style Sheets and other exotic stylistic animals

Entries feed - Comments feed

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.

Tuesday 7 June 2011

CSS 2.1, CSS 3 Color and MathML for CSS Profile are RECs !!!

YAY !!!!

Tuesday 24 May 2011

CSS OM, issue #2

In the CSS Object Model, interfaces CSSStyleDeclaration, CSSRule and CSSValue have access to the attribute cssText. So basically, you can serialize a stylesheet using that. All of a stylesheet? Unfortunately not...

  1. first, nothing is said in the DOM about the character set used to serialize your stylesheet in cssText. Even if your stylesheet uses a @charset rule, it's likely your serialization through cssText will be utf-8 utf-16...
  2. then @namespace rules are not available through the DOM at this time. I should add there is no CSS OM extension for them in the CSS 3 Namespaces module because there was no consensus about that and it was left for the forthcoming CSS OM spec.
  3. because of the previous item, it's just impossible at this time to serialize a stylesheet using namespace prefixes unless your rendering engine has proprietary extensions to deal with @namespace rules. There are two options here: a new type for CSSRule and then a simple loop over all rules in the stylesheet is enough to serialize it (modulo the charset issue mentioned above), or a table of prefixes/URIs attached to the stylesheet itself and then you need two loops; one for @charset and @import rules, the serialization of @namespace rules and finally the second part of the loop over remaining stylesheet rules.
  4. cssText is not available on CSSStyleSheet. On that interface, cssText could do all we need above: deal with namespaces, convert to the correct charset, and whatever we need in the future.

Thursday 19 May 2011

CSS OM, issue #1

I am starting with this blog entry a list of CSS Object Model issues I am hitting working on my editor, BlueGriffon. Here's the first issue below, more to come later:

Interface CSSStyleSheet does not deal with rules but only with rule indexes. Just like CSSMediaRule. That has an immediate side effect for content editors willing to edit stylesheets: moving a single rule in the list of rules attached to a parent stylesheet or parent media rule will not preserve the reference to your rule! Given a valid index in a stylesheet sheet, the following code moving the rule down into the list of rules will return false:

var rule = sheet.cssRules.item(index);
var newIndex = sheet.insertRule(rule.cssText, index + 1);
var newRule = sheet.cssRules.item(newIndex);
alert(rule == newRule);

This is clearly suboptimal. CSSStyleSheet and CSSMediaRule should be able to deal directly with rules. I suggest adding the following to Anne van Kesteren's improvements to the CSS OM:

readonly CSSRule insertCSSRule(CSSRule rule, unsigned long index);
void deleteCSSRule(CSSRule rule);

That way, the code above could become:

var rule = sheet.cssRules.item(index);
sheet.insertCSSRule(rule, index + 1);

And that's all. insertCSSRule() would detect rule is already present in the list of rules of sheet and simply move the rule to its new position.

Wednesday 18 May 2011

Wysiwig is hard #4, editing StyleSheets...

Editing stylesheets in a wysiwyg editor can be hard. For multiple reasons:

  1. stylesheets are of three different kinds: embedded into the document through a <style> element, linked through a <link> element, or imported from another stylesheet (and nesting is possible) through an @import rule. In html5, the possibility to have embedded styles anywhere in the document adds another layer of complexity, in particular in the case of presence of the scoped attribute... I must admit BlueGriffon is not ready for that yet, I have not resolved all the technical issues related to scoping. In particular, the specificity of scoped styles is unchanged and I am not sure this is coherent with the spirit of the CSS Cascade. This may have deep implications on the wysiwyg editing side but an ID selector's specificity should probably be added to all scoped styles.

    Listing all stylesheets applied to a given document is simple using one single CSS OM call. Determining if a stylesheet is embedded, linked or imported is done through the parentStyleSheet and ownerNode attributes on CSSRule and StyleSheet interfaces.

    Serialization of a stylesheet is painful. I had to write thousands (yes, really) of lines of JS to handle that because unknown CSS rules are not preserved by the browsers' style engines. Even if they were, an editor just cannot consider a vendor-prefixed property has to be output unchanged. A style change by the user could affect vendor-prefixed styles stored as unknown rules in the CSS OM...

  2. adding a given style to a given element is hard; not only you must find all the style rules that apply to the element for the property you want to edit, but you also need the specificities of those rules. When you have the list of couples (rule, specificity of the rule), you must find the rule of highest specificity. If that rule is editable, i.e. if the stylesheet can be modified by the application, then you must create a style rule or a style attribute of a high enough specificity and/or importance overriding the current style. If the stylesheet is not editable (file not writable, remote resource), then you may have to create a new embedded or linked stylesheet (or use a style attribute) to apply the style you want. I don't even want to think about the scoped styles case for the time being, it's a nightmare.

  3. html5 defines a new presentational attribute on all elements: the hidden attribute... It is not entirely clear to me if a true value of that boolean attribute should map to the CSS display: none; style or use another mechanism to hide the element. In the case of the former choice, this will add another layer of complexity to the editing algo for the display property. Furthermore, in the case what's the position of the hidden attribute in the CSS cascade? I think the html5 author's spirit make it override all other styles. But that's not how the Cascade works, giving a very low specificity to presentational attributes. Should the hidden and the style attributes have the same specificities? Should hidden exist at all? I don't think it should. It's presentational and we have the display property anyway. The only reason why it should exist could be an accessibility reason, voice browsers often using the DOM and not the CSS OM. By the way, the spec says "When specified on an element, it indicates that the element is not yet, or is no longer, relevant". Does it imply that styles contained in a <style hidden> should not apply any more? In other terms, does it disable the stylesheet? This hidden attribute is a can of worms, underspecified, and it will raise tons of technical issues in the near future.

  4. editing an embedded stylesheet is a pain. I'm sure you thought this should be the easiest case. No external file or remote resource, everything is inside text nodes. Simple, eh? It's not. It's not if you want the dialog editing such a stylesheet to be non-modal... Let me explain: if the dialog is not modal, then all changes to the styles are immediately applied. Let's suppose my embedded stylesheet contains only p { color: red; } and that I want to change that color to blue. I have two choices depending on the frameworks I am using:
    1. first case, I have access to an abstraction layer allowing me to tweak directly the source of the stylesheet; then I can change the red into a blue, and replace the textual contents of the style element by the new stylesheet
    2. I have only access to the CSS OM; then I can change the property value in the CSS OM, serialize the stylesheet and then replace the textual contents of the style element
  5. But in both cases above, I have a serious problem: the stylesheet I was editing does not exist any more! The style rule I was editing does not exist any more! They were replaced by a new stylesheet and a new style rule after parsing of the new textual contents... So if I kept a reference to the stylesheet and style rule I edited, they suddenly get a null ownerNode, my whole UI still shows style objects that are now only references to objects unrelated any more to the document. That implies that every style change, I repeat every style change, in an embedded stylesheet from a non-modal UI should totally reflow the UI or at least, reassociate all UI to new style objects that did not exist before... Urgh, to say the least.

Editing styles in a wysiwyg editor is not, as I heard it during a chat a few months ago, "only a matter of a few calls to the CSS OM". It's painful, expensive both in terms of performance and footprint, sometimes tricky in terms of UX and requires stuff that the CSS OM does not implement . It can be really hard.

Wednesday 30 March 2011

CSS 2.1 !!!

plinss: I propose advancing 2.1 to PR
plinss: Any objections?
RESOLVED: Advance CSS2.1 to PR. 

Tuesday 29 March 2011

border-radius rant...

Sorry to be less technical than in general but something painful just happened to me while working on the CSS editor of BlueGriffon and I wanted to share that with the CSS community...

BlueGriffon is based on the source of Firefox 4. The border-radius property is then implemented unprefixed in the rendering engine. Even if BlueGriffon outputs styles for other rendering engines (using Peter Beverloo's excellent list and my JSCSSP parser/serializer), I considered that one version (the last public one) of each rendering engine is enough.

And I just got a mail from a user complaining that -moz-border-radius is missing...

From a user's perspective (hear web author's perspective), this is a perfectly fine request. From my software implementor's point of view, it's a nightmare.

If CSS vendor prefixes are useful for standardization and implementation of experimental features, they're harmful to the users' community and painful to software management. Our current situation wrt vendor prefixes is still suboptimal, to say the least.

I am not going to support in BlueGriffon prefixed versions of properties that are now unprefixed in the last public version of browsers. Example: I don't plan to support the WebKit gradients forever...

Friday 18 March 2011

CSS Avancées

CSS AvancéesRaphaël Goetter vient de publier chez Eyrolles son nouveau livre "CSS Avancées, vers HTML 5 et CSS 3" que je ne peux que chaleureusement vous recommander. Pour vous mettre un peu l'eau à la bouche, voici le texte de la préface rédigée par votre serviteur pour le livre:

Au début étaient la pierre, le bois, l'argile, le métal, le papyrus et finalement le papier. Des supports pour lesquels fonds et forme sont inextricablement mêlés. Séparer la lettrine de son enluminure ? Imaginer le Talmud sans son formatage si spécial permettant les commentaires ? Impossible ! Pire, les éléments de forme étaient fortement dépendants du support : la typographie ronde était difficile sur pierre et impossible dans l’écorce de bois, les barres supérieures de certaines graphies étaient là pour aider l’alignement.

La révolution technologique a non seulement séparé fonds et forme dès la naissance du télégramme, mais elle a également séparé fonds et format, les lettres et chiffres n’étant plus des lettres et chiffres mais des signaux morse transitant dans un fil métallique. Le Web, cette nouvelle révolution dont seuls nos descendants mesureront à sa juste valeur la portée, va encore plus loin et officialise enfin ce vieux leitmotiv des fanatiques de la documentation structurée : contenu et présentation sont deux notions quasi orthogonales. Un contenu donné peut être présenté de plusieurs manières différentes, une présentation peut être commune à plusieurs contenus sans rapport entre eux.

Lorsque le Web nait au CERN entre 1989 et 1991 sous l’impulsion de Tim Berners-Lee, rien de tout cela n’existe encore. Chaque élément de la lingua franca du Web, le langage HTML, véhicule intrinsèquement sa propre présentation et styler un contenu n’est pas encore une idée en vogue. On est encore bien loin de ce qu’offre la PAO…

C’est là qu’interviennent Håkon Lie, un norvégien qui travailla au CERN avec Tim Berners-Lee et fût l’un des premiers employés du World Wide Web Consortium, et Bert Bos, un néerlandais étudiant à l’Université de Groningen. Extrayant la substantifique moelle des technologies de style documentaire existantes et comprenant que le style peut se décliner en styles voulus par l’auteur du document, styles par défaut de l’outil de visualisation et enfin styles imposés par le lecteur, ils ont élaboré de 1993 à 1995 le concept de Feuilles de Styles en Cascade (CSS).

Les débuts furent difficiles. Les éditeurs de navigateurs Web se livraient une guerre acharnée et une solution standard, interopérable et surtout exigeant des changements fondamentaux dans leur code n’était pas nécessairement bienvenue. Il fallut donc attendre un très grand virage sur l’aile, celui de Microsoft vers l’Internet et le Web, pour voir enfin les CSS implémentées de façon sérieuse et extensive dans un navigateur Web. A titre de rappel, le premier navigateur à proposer le support intégral des CSS 1 fut Microsoft Internet Explorer pour Macintosh… Netscape finit par abandonner son idée de styles fondés sur du code JavaScript (JSSS) et bascula vers les CSS. L’heure du succès était venue et la seconde mouture du standard, les CSS 2, s’aventura dans des champs encore inexplorés sur le Web : les polices de caractères téléchargeables, l’impression, le positionnement fin, et encore beaucoup d’autres nouveautés.

Mais les hommes n’étant finalement que des hommes, CSS 2 alla trop loin pour eux et l’implémentation des CSS 2 dans les navigateurs ne fut jamais à la hauteur des espoirs initiés par la spécification elle-même. Certaines fonctionnalités étaient sous-spécifiées, certaines autres posaient problème, certaines étaient même tout simplement inimplémentables en l’état de l’art ou de la spécification…

Le World Wide Web Consortium (W3C) s’attacha donc à la révision des CSS 2 en même temps qu’il planchait sur la future mouture, CSS 3. Cela prit un certain temps, voire un temps certain. Malgré une certaine exaspération toute légitime du côté des éditeurs Web, cela eut un effet très positif en laissant aux éditeurs de navigateurs le temps de profiter de nombreuses améliorations hardware et software. Un navigateur Web de 2010 n’a plus rien à voir avec un navigateur Web de 2000, même si l’usager ne s’en rend pas toujours compte.

Aujourd’hui, CSS 2.1 est enfin en phase finale de standardisation. Les CSS 3 ne sont pas un rêve éthéré mais une réalité déjà utilisable dans tous les navigateurs du marché. Tous ? Oui, tous, y compris Internet Explorer 9.

Non seulement plus personne ne conteste le modèle et l’utilité des CSS, mais plus personne ne conteste plus non plus leur légitimité en tant que langage unique de Feuilles de Styles sur le Web. Les fonctions de formatage simples des CSS 1 ont été grandement étoffées, et les dégradés de couleurs, les transformations géométriques, le colonage, les polices de caractères téléchargeables, ou encore le texte vertical et l’internationalisation promettent de servir des sites Web encore plus modernes, plus réactifs, plus conformes aux standards, plus aisés à réaliser ou maintenir et tout simplement plus beaux à encore plus d’internautes dans le monde, sur ordinateur ou sur mobile.

Que vous soyez l’éditeur d’un grand site de presse ou celui d’un petit blog, la conception de votre site passe immanquablement par les CSS. Et continuera encore plus à l’avenir à passer par les CSS… Car l’histoire ne s’arrête pas là : le Groupe de Travail standardisant les CSS au W3C continue à avancer, à répondre de mieux en mieux aux demandes des Web Designers ou même des typographes. La convergence entre le Web et les autres métiers du design documentaire est en marche : grilles de design, modèle flexible de présentation, etc. Vous allez adorer ça autant que nous aimons le standardiser et l’implémenter.

Le livre de Raphaël Goetter est donc pour tout auteur de site ou rédacteur d’une newsletter à envoyer par mail un must qui lui permettra non seulement de tirer parti des nouvelles technologies du Web (CSS 2.1 et 3, HTML 5) mais également d’éviter les chausse-trapes.

Entre le hêtre (*bōkz en proto-germanique) et l’e-book, le mot n’a que peu varié. Et la maîtrise du second requiert toujours la lecture du premier. Bonne lecture, donc !

Daniel Glazman
W3C CSS Working Group, Co-chairman

Tuesday 8 March 2011

Beyond CSS 3 Selectors

I want a change in Selectors, my baby, for post-CSS 3. Section of the current provisional REC says:

The :root pseudo-class represents an element that is the root of the document. In HTML 4, this is always the HTML element.

This is clearly not enough and I have a use case:

  • imagine you have two nested tables. You want to count the number of cells in the tbodies of the outermost table. That outermost table has no ID, no class, nothing to differenciate it from another table in the document. Let's call that outermost table mytable. Then mytable.querySelectorAll("tbody > tr > th, tbody > tr > td").length is not what we are looking for to count the cells because it will count ALL cells, including the cells of the innermost table... :root does not help here because it does not represent the root of the current scope. The :not() functional pseudo does not help either. The count cannot be performed using querySelector or querySelectorAll even if it could be the easiest, the simplest way. (This is not an imaginary use case, I hit that issue in BlueGriffon...)
  • imagine you have a scoped stylesheet applying to a subtree with the root of the subtree being a totally arbitrary element. It has no ID, no class you can use, nothing. It's then NOT selectable in the scoped stylesheet at all, you cannot apply styles to that element through the scoped stylesheet...

So I want the following change for the next step of Selectors:

The :root pseudo-class represents an element that is the element root of the current scope. In the case of CSS, the current scope is determined by the following rules:

  • if :root is used inside the parameter of a call to a.querySelector or a.querySelectorAll where a is a Document, then the current scope is the whole document
  • if :root is used inside the parameter of a call to a.querySelector or a.querySelectorAll where a is an Element, then the current scope is the subtree of the document a is the root of
  • if :root is used inside a non-scoped stylesheet, the current scope is the whole document
  • if :root is used inside a scoped stylesheet, the current scope is the scope of the stylesheet

That way, my count above is mytable.querySelectorAll(":root > tbody > tr > th, :root > tbody > tr > td").length and it is possible to style the root of a scope using the trivial selector :root. In the current CSS 3 case and non-scoped stylesheets, :root still means the root of the document. In the case of calls to Element.querySelector or Element.querySelectorAll, these calls reply an empty list anyway if the argument contains a :root pseudo and if the element is not the root of the document. In other terms, it's not something web authors use because it's totally useless at this time.

Sunday 26 December 2010


J'aurai le plaisir et l'honneur de causer dans le poste à la conférence confoo.ca à Montréal entre le 9 et le 11 mars prochain ! J'y parlerai évidemment de CSS... J'ai hâte d'y être et de découvrir enfin Montréal !

Tuesday 2 November 2010

Meet the 2010 CSS Working Group

CSS Working Group 2010
Photo by Anthony Grasso, reproduced with permission

This is not the whole CSS Working Group but only the people present at our current face-to-face meeting at the end of today's morning session. From left to right: Sylvain Galineau (Microsoft), Håkon Lie (Opera), Alex Mogilevski (Microsoft), Tab Atkins (Google), David Baron (Mozilla), John Jansen (Microsoft), Elika Etemad (Invited Expert), Bert Bos (W3C), Daniel Glazman (Disruptive Innovations, Co-chair), Beth Dakin (Apple), Steve Zilles (Adobe), Peter Linss (HP, Co-chair), Richard Ishida (W3C), John Daggett (Mozilla), David Clarke (Invited Expert), Koji Ishii (Antenna House), Dave Singer (Apple), Soonbo Han (LG Electronics).

Oh, by the way, no we don't always wear aprons to standardize CSS :-)

Friday 8 October 2010

CSS WG specs

(with my CSS WG Co-chair hat on)

Some of you have noticed that some specs in the CSS Working Group (Selectors for instance) remain in Proposed Recommendation status and don't move to REC even if it seems there is no blocker. That is and will be the case also for some other CSS 3 modules that are near completion. These documents hold a normative reference to CSS 2.1 that is not itself in REC yet. Once CSS 2.1 reaches REC status - and that's on track wooohooo - all the documents that reached PR with a conditional move to REC will themselves move to REC. In other terms, we'll have a basket of documents all moving together to REC that day.

I hope it clarifies a bit a situation that is only triggered by the W3C Process. It's normal, nothing strange here, no weird blocker. Just stay tuned :-) Thanks.

Saturday 11 September 2010

CSS Revolution revisited

More than 5 years and a half ago, I was calling for a CSS revolution and listed 12 things that were in my opinion absolutely needed for the future of the Web. Let's see where we are now wrt those 12 things:

  1. authors need a new version of CSS
    CSS3 is on track and it percolates into author stylesheets every day. It's unfortunately not a "version" but still a "level"
  2. calc()
    standardized and implemented
  3. inline-blocks
    standardized and implemented
  4. position an element relatively to any other element
    not done yet despite some interest
  5. columns
    standardized and implemented
  6. vertically center an element w/o hack
    hmmm... no, still not that simple especially for an arbitrary height of the element
  7. flex box model
    proposal on the table
  8. scale image backgrounds and need to apply filters to images
    first part standardized and implemented, second part currently discussed
  9. better printing
    in progress
  10. constants
    not done yet
  11. better I18N
    in progress
  12. scoped stylesheets in CSS
    not done yet

Not bad, to say the least...

Tuesday 29 June 2010

An Update on CSS 2.1

So where are we (that "we" meaning the CSS Working Group) on CSS 2.1? In short, we're making fast and excellent progress:

  • we are currently resolving the last outstanding issues ; almost all our weekly conference calls are entirely dedicated to CSS 2.1
  • the Test Suite is near completion ; the Working Group has decided, given the size of the Test Suite, that it's not realistic to review individually all tests before saying the Test Suite is completed. We will declare the Test Suite ready for implementation reports and will fix individual bugs when reported buggy by testers, browser vendors, the community, whoever. On a more personal note, I think it's the only reasonable way of dealing with a Test Suite that contains thousands and thousands of tests, some of them rather complex not only to write but also to understand when you read them. Otherwise, the review and validation process of all these tests alone will take ages...
  • given the recent changes in the spec - we resolved a lot of issues some of them pretty complicated - we may have to go back to Last Call Working Draft and then back to CR again. That's not a problem and can be relatively fast.
  • the current CR exit criteria - that we don't plan to change - are very clear (see conditions 4 and 5). The CR period could be a bit long though; we'll see.
  • the Test Suite and the CR should be available at same time and that time should be, as planned by the WG, after the summer. That should leave us enough time to reach Proposed Recommendation before the end of the year, as expected.

To the people who could complain about the duration of this process and the time needed to make this spec appear as a REC, let me say that we have a lot, really a lot of work here. The WG focuses almost solely on CSS 2.1 at this time and that's not recent. 2.1 must be released as a Web Standard because that's one of the current cornerstones of the architecture of the World Wide Web. We cannot make the next steps, CSS 3 even module by module, happen without 2.1 before.

In summary, we're on track. As expected. No reason to worry.


Daniel Glazman, W3C CSS Working Group, Co-chair

Update: reposted on W3C blog.

Friday 14 May 2010

Congratulations Microsoft

Yes, sincere congrats. Well done. The second beta preview of IE9 implements all of CSS 3 Selectors. It even implements (without a -ms-* prefix :-( Microsoft has really a problem with vendor prefixes...) the ::selection pseudo-element. It passes all my own Selectors test. It's even said to pass 100% of the Selectors Test Suite (an Implementation Report would be useful here, please) ! Wooohooo !!! For the record, former versions of IE were so bad at that Test Suite that adding them to the Implementation Report was pointless.

This is not only good news for IE9, it's good news for the whole Web. Microsoft is putting so much energy and "new" features inside IE9 that it's going to be a major incentive to drop former versions of IE and move to v9.

One (big) nit though: IE9 is only available for Vista and 7... While zillions of users, and in particular corporations, still use XP and don't plan to drop it any time soon. The unavailability of IE9 on XP will be a (big) slowdown factor to the obsolescence of IE6, 7 and 8. And I don't like that. I don't care about the tech reasons for that (graphics hardware acceleration bla bla), I don't like that at all. Un rendez-vous manqué.

Thursday 6 May 2010

WebKit and CSS 3 Namespaces #2

In fact the bug was totally different, with a side-effect on @import and @namespaces : the tokenizer of WebKit did not accept at-rule identifiers nor "url(" with escaped characters... Test syntax-006.xml of the CSS 3 Namespaces Test Suite was then failing because the @namespace rule in the first line was thrown away (escaped char inside the url ident) and the @import rule on the second line was then valid instead of being invalid... So here's my first WebKit patch. It misses the bug URL in the Changelog and an automated test, but I did not have more time to give to WebKit today. If someone else wants to fix my patch for review, no problem.

With that fix in, WebKit fails only one last test in the CSS 3 Namespaces Test Suite while Safari 4.0.5 fails 6 tests...

Wednesday 5 May 2010

WebKit and CSS 3 Namespaces

The CSS 3 Namespaces specification has only one implementation passing all tests (Firefox at his time). WebKit appears to be near completion, failing only two tests (@namespace error handling and invalid ordering of @namespace and @import). I think I have a fix for the latter bug:


CSS 3 Selectors

A bit less than eleven years ago, I released the first public Working Draft of the Selectors specification but the very first editor's draft of the spec (apparently lost) is dated 22-jun-1998... Almost twelve years! I have the immense joy and pride to announce today that the W3C Director, sir Tim Berners-Lee, has approved its advancement to Recommendation but asked that it not be published before the two normative references, CSS 2.1 and CSS 3 Namespaces, are themselves Recommendations.

Friday 30 April 2010

Innovation, browsers, CSS (and chutzpah...)

The ineffable Chris Blizzard wrote a nice article about "Innovations in browsers". Let me give you my CSS WG point of view on innovations and browsers:

  • CSS 3 Selectors were proposed by Netscape (more specifically the author of the current prose) AND implemented by Microsoft in MacIE and Netscape
  • CSS 3 Columns were proposed AND implemented by Opera (also implemented now by Mozilla)
  • border-radius was introduced by Mozilla long before standardization
  • multiple border colors too
  • CSS 3 Transforms, Transitions and Animations were proposed AND implemented by Apple
  • Media Queries were proposed AND implemented by Opera (and others now)
  • Microsoft was instrumental in the birth and existence of CSS 3 Text
  • the volatile CSS 3 Variables was proposed by Apple and Disruptive Innovations AND implemented (even if later removed) by Apple
  • the CSS 3 content property applied to all element was proposed by the author of the current prose (very) long ago and implemented by Opera even if the spec is still not a REC
  • the list of properties that are already implemented, shipped and used by zillions of web authors is longer than my arm...

CSS won. It's the only stylesheet language available on the Web and it's here to stay. Since software vendors increasingly look at HTML/CSS/JS as a platform of choice for their internal data, rendering engines' implementors need to urgently fill a fewmany gaps. That's one of the reasons why Microsoft for instance introduced so many -mso-* properties in the past. That's why Mozilla added its own -moz-* properties. All these properties - and the features they represent - have a tendency to be compatible with general users' requests and they naturally end up on the standardization table at some point.

I think I see the point in Joe's message though : standardization can be slow. It can be slow because it's always a compromise. But it's not always slow... In the case of CSS, most browser vendors want to see CSS evolve at fast pace and be implemented and shipped interoperably. Users want, users need new features to make the Web evolve and the race to new declarative ways of doing cool presentation stuff is tough.

Joe, don't be afraid of standardization, it's still and only the topping on the cake: innovation still starts inside browsers, it's usually still implemented long before REC, users do pick the best features, users send us feedback and input, and it's still a browser war. The process you highlight in your tweet *is* what happens on a daily basis but only one thing changed between 1998 and now : browser vendors all know they cannot remain alone implementing the new cool kid on the block.

Thursday 1 April 2010

Selectors NG

Microsoft Corporation and Disruptive Innovations are very pleased to disclose the result of our recent three days meeting of the CSS WG in Cupertino, CA. These new selectors fill a gap in Selectors 3 and we clearly hope a fast and massive adoption by browser vendors.

- page 2 of 6 -