<Glazblog/>

CSS and style

Cascading Style Sheets and other exotic stylistic animals

Entries feed - Comments feed

Tuesday 8 March 2011

Beyond CSS 3 Selectors

I want a change in Selectors, my baby, for post-CSS 3. Section 6.6.5.1 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

confoo.ca

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.

Thanks.

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:

Nevermind.

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.

Monday 22 March 2010

JSCSSP, CSS Variables

I have improved my JSCSSP parser with partial support for CSS Variables. Only nit, you can't use a var() value with shorthand properties yet.

Thursday 11 March 2010

JSCSSP, 1st simple demo

The title says it all and it's here.

Tuesday 15 December 2009

Selectors Level 3

I have the intense pleasure to let you know that the specification Selectors Level 3 just became officially a Proposed Recommendation !!! YAY !!!

Friday 9 October 2009

Glazou's rule of CSS for Web Agencies

The specificity of selectors in a web page's stylesheet(s) increases until the stylesheet is so fucked up someone starts using !important.

Tuesday 7 April 2009

The fullsize attribute...

So there is a proposal floating around for a fullsize attribute in HTML5... I am not in favor of it, because the effect the author of that proposal is trying to achieve MUST be controlled from A to Z by the web designer. So not only the animations, but also the closing button, the legend and its position, everything. I certainly don't want HTML and CSS to dive into that level of details. But wait, I said HTML and CSS? Hey, guys, look at the following. It took me exactly ten seconds to write it....

CSS chunk:

#full {
  display: none;
  position: relative;
}

#full:target {
  display: inline;
}

#full > img {
  position: absolute;
  z-index: 10000;
}

HTML chunk:

<a href="#full">
  <a id="full" href="#thumbnail">
    <img src="foo_full.jpg"/>
  </a>
  <img id="thumbnail" src="foo.jpg"/>
</a>

I know, I know, an anchor is not supposed to contain another anchor. Now, please, forget one second you're a web standards freak and look at my solution above. It just works...

Update: ROFL !!! I left a post on the fullsize attr's google group with a link to my post and the owner of the group has deleted my post ! Wow. That guy is apparently open to discussion, standardization and consensus....

Wednesday 4 March 2009

CssHackz

I got this morning an interesting email. In substance, the fallback mechanism is not enough to Web Designers because there is for instance no way you can specify - in clean CSS w/o hacks - display: table-cell for browsers that support it and something else for those that don't support it w/o having major interactions between the two style sets... The question asked by the sender was "why can't we have something like the following ?"

if (display table-cell)
CSS stuff here
else
CSS stuff here
endif

My first reply was of course "nah, that not CSS's role to fix browsers' holes".

Thinking a bit more about it, I took it as a mental exercise:

  1. add some controls to CSS that can filter in/out based on the availability in the current rendering engine of a (property, value(s)) pair
  2. do that of course in a cross-browser JS chunk
  3. make sure that a stylesheet containing such a beast is still parsable from a CSS point of view

I took an hour to write it and I must say that even if this is probably not the kind of things one will ever use in a production environment, it's a funny exercise.

See the test document, the test "stylesheet" and the JS code. View the result here. Warning, it's a 0.1 I wrote in an hour. Still successfully tested on IE6, IE7, IE8, FF3, Safari 4 and Opera 9.

Friday 6 February 2009

Time Breakdown of Modern Web Design

Spot on. Including CSS and tables.

Friday 23 January 2009

CSS in IE8

According to Wired,

  • The target for CSS support in IE8 is full and complete support for CSS2.1.
  • The only CSS3 module in IE8 is writing-mode (for vertical text support). IE has supported this since version 5.x, so it will continue to do so.
  • IE8 will not support CSS' border-radius, which is often used to make rounded corners without images. Microsoft's Chris Wilson confirms that border-radius support is "high on the wish list," though, and should make its way into the next release after IE8.

Full CSS 2.1 complete support is cool but it must be said that "full CSS 2.1 support" does not mean anything yet. CSS 2.1 is not yet a W3C Recommendation and it does not have an approved full Test Suite yet. Microsoft has submitted a rough 7,000 CSS 2.1 tests to the CSS WG but these tests need review before becoming official.

I am a bit surprised that Selectors are not fully or almost fully implemented in IE8. IE8 will then be far from Gecko, Opera and Webkit in terms of Selectors. Keeping a too low level on Selectors is a door open to CSS hacks based on selectors' sniffing, and that's a true disappointment to me.

- page 2 of 5 -