<Glazblog/>

CSS and style

Cascading Style Sheets and other exotic stylistic animals

Entries feed - Comments feed

Wednesday 29 June 2016

Media Queries fun #1

So one of the painful bits when you have UI-based management of Media Queries is the computation of what to display in that UI. No, it's not as simple as browsing all your stylesheets and style rules to retrieve only the media attribute of the CSS OM objects... Let's take a very concrete example:

<style type="text/css" media="screen and (min-width: 200px)">
@import url("foo.css") screen and (max-width: 750px);
</style>

where file foo.css contains the following rules:

@media screen and (max-width: 500px) {
h1 { color: red; }
}

What are the exact media constraints triggering a red foreground color for h1 elements in such a document? Right, it's screen and (min-width: 200px) and (max-width: 500px)... And to compute that from the inner style rule (theh1 { color: red; } bit), you have to climb up the CSS OM up to the most enclosing stylesheet and intersect the various media queries between that stylesheet and the final style rule:

CSS OM objectapplicable mediumapplicable min-widthapplicable max-width
embedded stylesheetscreen200px-
imported stylesheetscreen200px750px
@media rulescreen200px750px
style rulescreen200px500px

It becomes seriously complicated when the various constraints you have to intersect are expressed in different units because, unless you're working with computed values, you really can't intersect. In BlueGriffon, I am working on specified values and it's then a huge burden. In short, dealing with a width Media Query that is not expressed in pixels is just a no-go.

I'd really love to have a CSS OM API doing the work described above for a given arbitrary rule and replying a MediaList. Maybe something for Houdini?

Thursday 23 June 2016

Implementing Media Queries in an editor

You're happy as a programmer ? You think you know the Web ? You're a browser implementor ? You think dealing with Media Queries is easy ? Do the following first:

Given a totally arbitrary html document with arbitrary stylesheets and arbitrary media constraints, write an algo that gives all h1 a red foreground color when the viewport size is between min and max, where min is a value in pixels (0 indicating no min-width in the media query...) , and max is a value in pixels or infinite (indicating no max-width in the media query).  You can't use inline styles, of course. !important can be used ONLY if it's the only way of adding that style to the document and it's impossible otherwise. Oh, and you have to handle the case where some stylesheets are remote so you're not allowed to modify them because you could not reserialize them :-)

What's hard? Eh:

  • media attributes on stylesheet owner node
  • badly ordered MQs
  • intersecting (but not contained) media queries
  • default styles between MQs
  • remote stylesheets
  • so funny to deal with the CSS OM where you can't insert a rule before or after another rule but have to deal with rule indices...
  • etc.

My implementation in BlueGriffon is almost ready. Have fun...

Saturday 18 June 2016

Pourquoi il n'aurait pas du arrêter d'utiliser CSS

Cet article est un commentaire sur celui-ci. Je l'ai trouvé via un tweet de Korben, évidemment. Il m'a un peu hérissé le poil, évidemment, et donc j'ai besoin de fournir une réponse à son auteur via ce blog.

Les sélecteurs

L'auteur de l'article fait les trois reproches suivants aux sélecteurs CSS :

  1. La définition d'un style associé à un sélecteur peut être redéfinie ailleurs
  2. Si on associe plusieurs styles à un sélecteur, les derniers définis dans le CSS auront toujours la priorité
  3. Quelqu'un peut péter les styles d'un composant pour peu qu'il ne sache pas qu'un sélecteur est utilisé ailleurs

Le moins que l'on puisse dire est j'ai halluciné en lisant cela. Quelques lignes au-dessus, l'auteur faisait une comparaison avec JavaScript. Reprenons donc ses trois griefs....

Pour le numéro 1, il râle parce que  if (foo) { a = 1; } ... if (foo) { a = 2;} est tout simplement possible. Bwarf.

Dans le cas numéro 2, il râle parce que dans if (foo) { a = 1; a = 2; ... } les ... verront la variable a avoir la valeur 2.

Dans le cas numéro 3, oui, certes, je ne connais pas de langage dans lequel quelqu'un qui modifie sans connaître le contexte ne fera aucune connerie...

La spécificité

Le « plein délire » de !important, et je suis le premier à reconnaître que cela ne m'a pas aidé dans l'implémentation de BlueGriffon, c'est quand même ce qui a permis à des tétraflopées de bookmarklets et de codes injectés dans des pages totalement arbitraires d'avoir un résultat visuel garanti. L'auteur ne râle pas seulement contre la spécificité et son calcul mais aussi sur la possibilité d'avoir une base contextuelle pour l'application d'une règle. Il a en partie raison, et j'avais moi-même il y a longtemps proposé un CSS Editing Profile limitant les sélecteurs utilisés dans un tel profil pour une plus grande facilité de manipulation. Mais là où il a tort, c'est que des zillions de sites professionnels utilisant des composants ont absolument besoin des sélecteurs complexes et de ce calcul de spécificité...

Les régressions

En lisant cette section, j'ai laché un sonore « il exagère tout de même »... Oui, dans tout langage interprété ou compilé, modifier un truc quelque part sans tenir compte du reste peut avoir des effets de bords négatifs. Son exemple est exactement conforme à celui d'une classe qu'on dériverait ; un ajout à la classe de base se retrouverait dans la classe dérivée. Oh bah c'est pas bien ça... Soyons sérieux une seconde svp.

Le choix de priorisation des styles

Là, clairement, l'auteur n'a pas compris un truc fondamental dans les navigateurs Web et le DOM et l'application des CSS. Il n'y a que deux choix possibles : soit on utilise l'ordre du document tree, soit on utilise des règles de cascade des feuilles de styles. Du point de vue du DOM, class="red blue" et class="blue red" sont strictement équivalents et il n'y a aucune, je répète aucune, garantie que les navigateurs préservent cet ordre dans leur DOMTokenList.

Le futur de CSS

Revenons à la comparaison JS de l'auteur. En gros, si on a en ligne 1 var a=1 en ligne 2 alert(a), l'auteur râle parce que si on insère var a = 2 entre les deux lignes on affichera la valeur 2 et pas 1... C'est clairement inadmissible (au sens de pas acceptable) comme argument.

La méthodologie BEM

Un pansement sur une jambe de bois... On ne change rien mais on fout des indentations qui augmentent la taille du fichier, gênent son édition et sa manipulation, et ne sont aucunement compréhensibles par une machine puisque tout cela n'est pas préservé par le CSS Object Model.

Sa proposition alternative

J'ai toussé à m'en éjecter les poumons du corps à la lecture de cette section. C'est une horreur non-maintenable, verbeuse et error-prone.

En conclusion...

Oui, CSS a des défauts de naissance. Je le reconnais bien volontiers. Et même des défauts d'adulte quand je vois certaines cochoncetés que le ShadowDOM veut nous faire mettre dans les Sélecteurs CSS. Mais ça, c'est un rouleau-compresseur pour écraser une mouche, une usine à gaz d'une magnitude rarement égalée.

Je ne suis globalement pas d'accord du tout avec bloodyowl, qui oublie trop facilement les immenses bénéfices que nous avons pu tirer de tout ce qu'il décrie dans son article. Des centaines de choses seraient impossibles sans tout ça. Alors oui, d'accord, la Cascade c'est un peu capillotracté. Mais on n'attrape pas des mouches avec du vinaigre et si le monde entier a adopté CSS (y compris le monde de l'édition qui vient pourtant de solutions assez radicalement différentes du Web), c'est bien parce que c'est bien et que ça marche.

En résumé, non CSS n'est pas « un langage horriblement dangereux ». Mais oui, si on laisse n'importe qui faire des ajouts n'importe comment dans un corpus existant, ça peut donner des catas. C'est pareil dans un langage de programmation, dans un livre, dans une thèse, dans de la mécanique, partout. Voilà voilà.

Saturday 16 January 2016

Ebook pagination and CSS

Let's suppose you have a rather long document, for instance a book chapter, and you want to render it in your browser à la iBooks/Kindle. That's rather easy with just a dash of CSS:

body {
height: calc(100vh - 24px);
column-width: 45vw;
overflow: hidden;
margin-left: calc(-50vw * attr(currentpage integer));
}

Yes, yes, I know that no browser implements that attr()extended syntax. So put an inline style on your body for margin-left: calc(-50vw * <n>) where <n> is the page number you want minus 1.

Then add the fixed positioned controls you need to let user change page, plus gesture detection. Add a transition on margin-left to make it nicer. Done. Works perfectly in Firefox, Safari, Chrome and Opera. I don't have a Windows box handy so I can't test on Edge.

Wednesday 13 January 2016

CSS Prefixed and unprefixed properties

I used to be quite a heavy user of Peter Beverloo's list of CSS properties, indicating all prefixed versions, but he stopped maintaining it a while ago, unfortunately. So I wrote my own, because I still need such data for BlueGriffon... In case you also need it, it's available from http://disruptive-innovations.com/zoo/cssproperties/ and is automatically refreshed from Gecko, WebKit and Blink sources on a daily basis.

Friday 4 September 2015

ParisWeb 2015

Les inscriptions à ParisWeb, la meilleure conf du secteur depuis 2006, c'est maintenant !

Thursday 30 July 2015

CSS Vendor Prefixes

I have read everything and its contrary about CSS vendor prefixes in the last 48 hours. Twitter, blogs, Facebook are full of messages or articles about what are or are supposed to be CSS vendor prefixes. These opinions are often given by people who were not members of the CSS Working Group when we decided to launch vendor prefixes. These opinions are too often partly or even entirely wrong so let me give you my own perspective (and history) about them. This article is with my CSS Co-chairman's hat off, I'm only an old CSS WG member in the following lines...

  • CSS Vendor Prefixes as we know them were proposed by Mike Wexler from Adobe in September 1998 to allow browser vendors to ship proprietary extensions to CSS.

    In order to allow vendors to add private properties using the CSS syntax and avoid collisions with future CSS versions, we need to define a convention for private properties. Here is my proposal (slightly different than was talked about at the meeting). Any vendors that defines a property that is not specified in this spec must put a prefix on it. That prefix must start with a '-', followed by a vendor specific abbreviation, and another '-'. All property names that DO NOT start with a '-' are RESERVED for using by the CSS working group.

  • One of the largest shippers of prefixed properties at that time was Microsoft that introduced literally dozens of such properties in Microsoft Office.
  • The CSS Working Group slowly evolved from that to « vendor prefixes indicate proprietary features OR experimental features under discussion in the CSS Working Group ». In the latter case, the vendor prefixes were supposed to be removed when the spec stabilized enough to allow it, i.e. reaching an official Call for Implementation.
  • Unfortunately, some prefixed « experimental features » were so immensely useful to CSS authors that they spread at fast pace on the Web, even if the CSS authors were instructed not to use them. CSS Gradients (a feature we originally rejected: « Gradients are an example. We don't want to have to do this in CSS. It's only a matter of time before someone wants three colors, or a radial gradient, etc. ») are the perfect example of that. At some point in the past, my own editor BlueGriffon had to output several different versions of CSS gradients to accomodate the various implementation states available in the wild (WebKit, I'm looking at you...).
  • Unfortunately, some of those prefixed properties took a lot, really a lot, of time to reach a stable state in a Standard and everyone started relying on prefixed properties in production web sites...
  • Unfortunately again, some vendors did not apply the rules they decided themselves: since the prefixed version of some properties was so widely used, they maintained them with their early implementation and syntax in parallel to a "more modern" implementation matching, or not, what was in the Working Draft at that time.
  • We ended up just a few years ago in a situation where prefixed proprerties were so widely used they started being harmful to the Web. The indredible growth of first WebKit and then Chrome triggered a massive adoption of prefixed properties by CSS authors, up to the point other vendors seriously considered implementing themselves the -webkit- prefix or at least simulating it.

Vendor prefixes were not a complete failure. They allowed the release to the masses of innovative products and the deep adoption of HTML and CSS in products that were not originally made for Web Standards (like Microsoft Office). They allowed to ship experimental features and gather priceless feedback from our users, CSS Authors. But they failed for two main reasons:

  1. The CSS Working Group - and the Group is really made only of its Members, the vendors - took faaaar too much time to standardize critical features that saw immediate massive adoption.
  2. Some vendors did not update nor "retire" experimental features when they had to do it, ditching themselves the rules they originally agreed on.

From that perspective, putting experimental features behind a flag that is by default "off" in browsers is a much better option. It's not perfect though. I'm still under the impression the standardization process becomes considerably harder when such a flag is "turned on" in a major browser before the spec becomes a Proposed Recommendation. A Standardization process is not a straight line, and even at the latest stages of standardization of a given specification, issues can arise and trigger more work and then a delay or even important technical changes. Even at PR stage, a spec can be formally objected or face an IPR issue delaying it. As CSS matures, we increasingly deal with more and more complex features and issues, and it's hard to predict when a feature will be ready for shipping. But we still need to gather feedback, we still need to "turn flags on" at some point to get real-life feedback from CSS Authors. Unfortunately, you can't easily remove things from the Web. Breaking millions of web sites to "retire" an experimental feature is still a difficult choice...

Flagged properties have another issue: they don't solve the problem of proprietary extensions to CSS that become mainstream. If a given vendor implements for its own usage a proprietary feature that is so important to them, internally, they have to "unflag" it, you can be sure some users will start using it if they can. The spread of such a feature remains a problem, because it changes the delicate balance of a World Wide Web that should be readable and usable from anywhere, with any platform, with any browser.

I think the solution is in the hands of browser vendors: they have to consider that experimental features are experimental whetever their spread in the wild. They don't have to care about the web sites they will break if they change, update or even ditch an experimental or proprietary feature. We have heard too many times the message « sorry, can't remove it, it spread too much ». It's a bad signal because it clearly tells CSS Authors experimental features are reliable because they will stay forever as they are. They also have to work faster and avoid letting an experimental feature alive for more than two years. That requires taking the following hard decisions:

  • if a feature does not stabilize in two years' time, that's probably because it's not ready or too hard to implement, or not strategic at that moment, or that the production of a Test Suite is a too large effort, or whatever. It has then to be dropped or postponed.
  • Tests are painful and time-consuming. But testing is one of the mandatory steps of our Standardization process. We should "postpone" specs that can't get a Test Suite to move along the REC track in a reasonable time. That implies removing the experimental feature from browsers, or at least turning the flag they live behind off again. It's a hard and painful decision, but it's a reasonable one given all I said above and the danger of letting an experimenal feature spread.

Monday 29 June 2015

CSS Working Group's future

Hello everyone.

Back in March 2008, I was extremely happy to announce my appointment as Co-chairman of the CSS Working Group. Seven years and a half later, it's time to move on. There are three main reasons to that change, that my co-chair Peter and I triggered ourselves with W3C Management's agreement:

  1. We never expected to stay in that role 7.5 years. Chris Lilley chaired the CSS Working Group 1712 days from January 1997 (IIRC) to 2001-oct-10 and that was at that time the longest continuous chairing in W3C's history. Bert Bos chaired it 2337 days from 2001-oct-11 to 2008-mar-05. Peter and I started co-chairing it on 2008-mar-06 and it will end at TPAC 2015. That's 2790 days so 7 years 7 months and 20 days! I'm not even sure those 2790 days hold a record, Steven Pemberton probably chaired longer. But it remains that our original mission to make the WG survive and flourish is accomplished, and we now need fresher blood. Stability is good, but smart evolution and innovation are better.
  2. Co-chairing a large, highly visible Working Group like the CSS Working Group is not a burden, far from it. But it's not a light task either. We start feeling the need for a break.
  3. There were good candidates for the role, unanimously respected in the Working Group.

So the time has come. The new co-chairs, Rossen Atanassov from Microsoft and Alan Stearns from Adobe, will take over during the Plenary Meeting of the W3C held in Sapporo, japan, at the end of October and that is A Good Thing™. You'll find below a copy of my message to W3C.

To all the people I've been in touch with while holding my co-chair's hat: thank you, sincerely and deeply. You, the community around CSS, made everything possible.

Yours truly.

Dear Tim, fellow ACs, fellow Chairs, W3C Staff, CSS WG Members,

After seven years and a half, it's time for me to pass the torch of the CSS Working Group's co-chairmanship. 7.5 years is a lot and fresh blood will bring fresh perspectives and new chairing habits. At a time the W3C revamps its activities and WGs, the CSS Working Group cannot stay entirely outside of that change even if its structure, scope and culture are retained. Peter and I decided it was time to move on and, with W3M's agreement, look for new co-chairs.

I am really happy to leave the Group in Alan's and Rossen's smart and talented hands, I'm sure they will be great co-chairs and I would like to congratulate and thank them for accepting to take over. I will of course help the new co-chairs on request for a smooth and easy transition, and I will stay in the CSS WG as a regular Member.

I'd like to deeply thank Tim for appointing me back in 2008, still one of the largest surprises of my career!

I also wish to warmly thank my good friends Chris Lilley, Bert Bos and Philippe Le Hégaret from W3C Staff for their crucial daily support during all these years. Thank you Ralph for the countless transition calls! I hope the CSS WG still holds the record for the shortest positive transition call!

And of course nothing would have been possible without all the members of the CSS Working Group, who tolerated me for so long and accepted the changes we implemented in 2008, and all our partners in the W3C (in particular the SVG WG) or even outside of it, so thank you all. The Membership of the CSS WG is a powerful engine and, as I often say, us co-chairs have only been a drop of lubricant allowing that engine to run a little bit better, smoother and without too much abrasion.

Last but not least, deep thanks to my co-chair and old friend Peter Linss for these great years; I accepted that co-chair's role to partner with Peter and enjoyed every minute of it. A long ride but such a good one!

I am confident the CSS Working Group is and will remain a strong and productive Group, with an important local culture. The CSS Working Group has both style and class (pun intended), and it has been an honour to co-chair it.

Thank you.

</Daniel>

Monday 2 March 2015

Adobe Edge Reflow anyone?

Edge ReflowI received this morning a message from the Adobe Edge Reflow prerelease forum that triggered my interest. I must admit I did not really follow what happened there during the last twelve months for many various reasons... But this morning, it was different. In short, the author had questions about the fate of Edge Reflow, in particular because of the deep silence of that forum...

Adobe announced Edge Reflow in Q3 2012 I think. It followed the announcement of Edge Code a while ago. Reflow was aimed at visual responsive design in a new, cool, interactive desktop application with mobile and photoshop links. The first public preview was announced in February 2013 and a small community of testers and contributors gathered around the Adobe prerelease fora. Between January 2013 and now, roughly 1300 messages were sent there.

Reflow is a html5/JS app turned into a desktop application through the magic of CEF. It has a very cool and powerful UI, superior management of simple Media Queries, excellent management of colors, backgrounds, layers, magnetic grids and more. All in all, a very promising application for Web Authoring.

But the last available build of Reflow, again through the prerelease web site, is only a 0.57.17154 and it is now 8 months old. After 2 years and a half, Reflow is still not here and there are reasons to worry.

First, the team (the About dialog lists more than 20 names...) seems to have vanished and almost nothing new has been contributed/posted to Reflow in the last six to eight months.

Second, the application still suffers from things I identified as rather severe issues early on: the whole box model of the application is based on CSS floats and is then not in line with what modern web designers are looking for. Eh, it's not even using absolute positioning... It also means it's going to be rather complicated to adapt it to grids and flexbox, not even mentioning Regions...

Reflow also made the choice to generate Web pages instead of editing Web pages... It means projects are saved in a proprietary format and only exported to html and CSS. It's impossible to take an existing Web page and open it in Reflow to edit it. In a world of Web Design that sees authors use heterogeneous environments, I considered that as a fatal mistake. I know - trust me, I perfectly know - that making html the pivot format of Reflow would have implied some major love and a lot, really a lot of work. But not doing it meant that Edge Reflow had to be at the very beginning of the editorial chain, and that seemed to me an unbearable market restriction.

Then there was the backwards compatibility issue. Simply put, how does one migrate Dreamweaver templates to Reflow? Short answer, you can't...

I suspect Edge Reflow is now at least on hold, more probably stopped. More than 2 years and still no 1.0 on such an application that should have seen a 1.0beta after six to eight months is not a good sign anyway. After Edge Code that became Brackets in november 2014, that raises a lot of question on the Edge concept and product line. Edge Animate seems to be still maintained at Adobe (there's our old Netscape friend Kin Blas in the list of credits) but I would not be surprised if the name is changed in the future.

Too bad. I was, in the beginning, really excited by Edge Reflow. I suspect we won't hear about it again.

Sunday 8 February 2015

CSS Parser and Tokenizer API

The first time I mentioned the need to reach the internal CSS parser of a rendering engine from JavaScript was 17 years ago during the CSS WG meeting I hosted at Électricité de France in 1998, during a corridor discussion. All the people around said it was out of question. Then I put it back on the table in 2002, with little success again. Today, I was actioned by the CSS WG and the TAG in the Houdini Task Force to start editing a new document (with Tab Atkins, Shane Stevens and Brian Kardell) called CSS Parser and Tokenizer API. It does not say it's going to be accepted or anything, but at least it went beyond the 5 minutes chat and rebuttal. I am extremely happy and proud :-) If we succeed making it happen, this is going to be a game-changer for a lot of web applications!!!

Thursday 18 December 2014

Bulgaria Web Summit

I will be speaking at the Bulgaria Web Summit 2015 in Sofia, Bulgaria, 18th of april.

Wednesday 19 March 2014

A better CSS OM for parsed values

A large part of the current CSS Object Model sucks. More specifically, the CSSValue, CSSPrimitiveValue, CSSValueList, RGBColor, Rect and Counter interfaces are so poorly designed they're not implemented. I just tried to implement them for a project of mine and I must say the model is so weak and incoherent it cannot be implemented as is.

I have then tried to refine what's in the 2000-nov-13 spec of DOM Level 2 Style to reach something workable. I am NOT saying this has to be done or implemented. Call it a mental exercise I did just for fun, w/o caring about performance.

Let's first look at what's wrong:

Interface CSSValue

      interface CSSValue {
      
        // UnitTypes
        const unsigned short      CSS_INHERIT                    = 0;
        const unsigned short      CSS_PRIMITIVE_VALUE            = 1;
        const unsigned short      CSS_VALUE_LIST                 = 2;
        const unsigned short      CSS_CUSTOM                     = 3;
      
                 attribute DOMString        cssText;
                                              // raises(DOMException) on setting
      
        readonly attribute unsigned short   cssValueType;
      };

"inherit" is here considered as a special identifier despite of the fact a CSSPrimitiveValue can be a CSS_IDENT. There is no UnitType for "initial". A CSS_CUSTOM is, according to the spec, a "custom value"; but a custom value still has to be valid per CSS syntax so it should be representable with CSS_VALUE_LISTs and CSS_VALUEs.

Interface CSSValueList

interface CSSValueList : CSSValue {
  readonly attribute unsigned long    length;
  CSSValue           item(in unsigned long index);
};

All in all, this one is simple and should be quite ok. But one thing is missing: a property can accept a comma-separated list of whitespace-separated values. The current CSSValueList cannot express if the serialization of a CSSValueList should be whitespace- or comma-separated.

Interface CSSPrimitiveValue

interface CSSPrimitiveValue : CSSValue {

  // UnitTypes
  const unsigned short      CSS_UNKNOWN                    = 0;
  const unsigned short      CSS_NUMBER                     = 1;
  const unsigned short      CSS_PERCENTAGE                 = 2;
  const unsigned short      CSS_EMS                        = 3;
  const unsigned short      CSS_EXS                        = 4;
  const unsigned short      CSS_PX                         = 5;
  const unsigned short      CSS_CM                         = 6;
  const unsigned short      CSS_MM                         = 7;
  const unsigned short      CSS_IN                         = 8;
  const unsigned short      CSS_PT                         = 9;
  const unsigned short      CSS_PC                         = 10;
  const unsigned short      CSS_DEG                        = 11;
  const unsigned short      CSS_RAD                        = 12;
  const unsigned short      CSS_GRAD                       = 13;
  const unsigned short      CSS_MS                         = 14;
  const unsigned short      CSS_S                          = 15;
  const unsigned short      CSS_HZ                         = 16;
  const unsigned short      CSS_KHZ                        = 17;
  const unsigned short      CSS_DIMENSION                  = 18;
  const unsigned short      CSS_STRING                     = 19;
  const unsigned short      CSS_URI                        = 20;
  const unsigned short      CSS_IDENT                      = 21;
  const unsigned short      CSS_ATTR                       = 22;
  const unsigned short      CSS_COUNTER                    = 23;
  const unsigned short      CSS_RECT                       = 24;
  const unsigned short      CSS_RGBCOLOR                   = 25;

  readonly attribute unsigned short   primitiveType;
  void               setFloatValue(in unsigned short unitType, 
                                   in float floatValue)
                                        raises(DOMException);
  float              getFloatValue(in unsigned short unitType)
                                        raises(DOMException);
  void               setStringValue(in unsigned short stringType, 
                                    in DOMString stringValue)
                                        raises(DOMException);
  DOMString          getStringValue()
                                        raises(DOMException);
  Counter            getCounterValue()
                                        raises(DOMException);
  Rect               getRectValue()
                                        raises(DOMException);
  RGBColor           getRGBColorValue()
                                        raises(DOMException);
};

This is so completely crazy I don't know where to start...

  • CSS_UNKNOWN is supposed to represent a "value that is not a recognized CSS2 value". Then it should be thrown away by the parser as invalid and never reach the OM, right?
  • the list of units is long and not easily extensible
  • attr(), counter(), counters(), rect() and the more recent gradients or var() calls are all functions; adding a new setter and a new getter for each new type is overkill
  • attr() was extended by recent specs and can now take more than one argument. The above does not allow to individually modify those arguments.
  • "initial" and "inherit" are, as I already said above, covered by both CSSValue and CSS_IDENT here
  • let's suppose we have a CSSValue that is a CSSPrimitiveValue. Setting its cssText to "10px 10px" will then trigger an exception since a CSSPrimitiveValue cannot transmute magically into a CSSValueList...
  • I love how the spec prose says setStringValue() has "No Parameters"...

Interface Rect

interface Rect {
  readonly attribute CSSPrimitiveValue  top;
  readonly attribute CSSPrimitiveValue  right;
  readonly attribute CSSPrimitiveValue  bottom;
  readonly attribute CSSPrimitiveValue  left;
};

This looks and smells like a CSSValueList far too much.

Interface RGBColor

interface RGBColor {
  readonly attribute CSSPrimitiveValue  red;
  readonly attribute CSSPrimitiveValue  green;
  readonly attribute CSSPrimitiveValue  blue;
};

This cannot represent rgba(), hsl() and hsla() colors. We also have to use three CSSPrimitiveValue for the three color components because they can be a percentage or an integer...

Interface Counter

interface Counter {
  readonly attribute DOMString        identifier;
  readonly attribute DOMString        listStyle;
  readonly attribute DOMString        separator;
};

Again, something is missing here: nothing says if it's supposed to be a counter() or a counters() value. And no, the separator could not do the trick since it can be the empty string.

Requirements

To have a better OM for Values, i.e. an extensible OM that allows an application to deal with parsed values of all kinds, we need to change of perspective. First, the list of reserved idents, the list of units and the list of functions are not extensible. Secondly, we have cast issues between PrimitiveValues and ValueLists and we need a single interface. We can deal with all the issues with a single CSSValue interface:

New interface CSSValue

interface CSSValue {

  // ValueTypes
  const unsigned short      CSS_SYMBOL                     = 0;
  const unsigned short      CSS_NUMBER                     = 1;
  const unsigned short      CSS_UNIT                       = 2;
  const unsigned short      CSS_STRING                     = 3;
  const unsigned short      CSS_URI                        = 4;
  const unsigned short      CSS_IDENT                      = 5;
const unsigned short CSS_VALUE_LIST = 6; readonly attribute unsigned short type; attribute boolean commaSeparated;
readonly attribute unsigned long length;
CSSValue item(in unsigned long index);
raises(DOMException);

void setFloatValue(in float floatValue) raises(DOMException); float getFloatValue() raises(DOMException);
void setStringValue(in DOMString stringValue) raises(DOMException); DOMString getStringValue() raises(DOMException); };

Definition group ValueTypes

An integer indicating the type of the Value

CSS_SYMBOL
The value is a single character than cannot be interpreted otherwise. For instance the / character in the font shorthand property. The value can be obtained by the getStringValue() and set by the setStringValue() method.
CSS_NUMBER
The value is a simple number. The value can be obtained by using the getFloatValue() method and set through by setFloatValue() method.
CSS_UNIT
The value is a number followed by a unit. The number part of the value can be obtained by using the getFloatValue() method and set through by setFloatValue() method. The unit part of the value can be obtained by using the getUnit() method and set through by setUnit() method
CSS_STRING
The value is a string. The value can be obtained by the getStringValue() and set by the setStringValue() method.
CSS_URI
The value is a URI. The parameter of the url() function can be obtained by the getStringValue() and set by the setStringValue() method.
CSS_IDENT
The value is a CSS identifier. The value can be obtained by the getStringValue() and set by the setStringValue() method.
CSS_VALUE_LIST
The value is a list of values or a function. It is a function if the getStringValue() method does not reply the empty string. The list of values is whitespace-separated if the commaSeparated attribute is false and comma-separated otherwise.

Attributes

type of type unsigned short, readonly
The type of the value as defined by the constants specified above.
commaSeparated of type boolean
The separation type of the list of values. Meaningful only if the type attribute is CSS_VALUE_LIST. The list is whitespace-separated if the attribute is false and comma-separated otherwise.
length of type unsigned long, readonly
The number of CSSValue in the list. The range of valid values of the indices is 0 to length-1 inclusive.
Exceptions
INVALID_ACCESS_ERR: Raised if the CSS value is a not a CSS_VALUE_LIST.

Methods

getFloatValue
Retrieves the value of a CSS_NUMBER or the number part of the value of a CSS_UNIT. If this CSS value is not a CSS_NUMBER or a CSS_UNIT, a DOMException is raised.
Return Value
float The float value of this CSS_NUMBER or CSS_UNIT
Exceptions
INVALID_ACCESS_ERR: Raised if the CSS value isn't a CSS_NUMBER nor a CSS_UNIT.
getStringValue
For a CSS_SYMBOL, retrieves the single character used as a symbol.
For a CSS_STRING, retrieves the string. Enclosing quotes or double-quotes are NOT included.
For a CSS_UNIT, retrieves the unit of the value.
For a CSS_URI, retrieves the argument of the url(...) notation. Enclosing quotes or double-quotes are NOT includedt.
For a CSS_IDENT, retrieves the identifier.
For a CSS_VALUE_LIST and if that list of values is passed as the parameters of a function, retrieves the function name. Retrieves the empty string otherwise.
For a CSS_NUMBER and CSS_UNIT, a DOMException is raised.
No Parameters
Return Value
DOMString The float value of this CSS_NUMBER or CSS_UNIT
Exceptions
INVALID_ACCESS_ERR: Raised if the CSS value is a CSS_NUMBER or a CSS_UNIT.
item
For a CSS_VALUE_LIST, Used to retrieve a CSSValue by ordinal index. The order in this collection represents the order of thevalues in the CSS style property. If index is greater than or equal to the number of values in the list, this returnsnull.
For all other value types, a DOMException is raised.
Parameter
index of type unsigned long: index into the collection.
Return value
CSSValue The CSSValue at the index position in the CSSValueList, or null if that is not a valid index.
Exceptions
INVALID_ACCESS_ERR: Raised if the CSS value is a not a CSS_VALUE_LIST.
setFloatValue
Sets the value of a CSS_NUMBER or the number part of the value of a CSS_UNIT. If this CSS value is not a CSS_NUMBER or a CSS_UNIT, a DOMException is raised.
Parameter
floatValue of type float;
No Return Value
Exceptions
INVALID_ACCESS_ERR: Raised if the CSS value isn't a CSS_NUMBER nor a CSS_UNIT or if the attached property doesn't support the float value or the unit type.
NO_MODIFICATION_ALLOWED_ERR: Raised if this property is readonly.
setStringValue
For a CSS_SYMBOL, sets the single character used as a symbol.
For a CSS_STRING, sets the string.
For a CSS_UNIT, sets the unit of the value.
For a CSS_URI, sets the argument of the url(...) notation.
For a CSS_IDENT, sets the identifier.
For a CSS_VALUE_LIST and if the parameter is not the empty string, make the list of values become a function and sets the function name. Make the list become a plain list of values if the parameter is the empty string.
For a CSS_NUMBER and CSS_UNIT, a DOMException is raised.
Parameter
stringValue of type DOMString
No Return Value
Exceptions
INVALID_ACCESS_ERR: Raised if the CSS value is a CSS_NUMBER or a CSS_UNIT, if the type of the value is CSS_SYMBOL and the string can be parsed as an other type of value, if the type of the value is CSS_UNIT and the string is not a valid CSS unit, if the type of the value is CSS_URI and the string is not a valid URI, if the type of the value is CSS_IDENT and the string is not a valid CSS identifier, if the type of the value is CSS_VALUE_LIST and the string is not a valid CSS identifier or the empty string.
NO_MODIFICATION_ALLOWED_ERR: Raised if this property is readonly.

Conclusion

The above should be enough to describe any CSS value, specified or computed. The model will become a bit complex for complex values but it ensures any web application can have access to parsed values, deal with their types and modify them. Let's take an example:

background-image: linear-gradient(to bottom, yellow 0%, blue 100%), url(foo.png);

This will result in the following OM (click on the image to enlarge it):

OM example

Again, I'm not saying the above is the thing to do or implement. It can certainly be improved, for instance for colors. A totally different perspective is also perfectly possible. I am only saying that making a better CSS OM allowing a full representation of parsed values in stylesheets and computed values is feasible. I hope the CSS OM will offer such power in the future.

UPDATE: the new CSSValue interface above lacks one thing, the ubiquitous cssText for parsing and serialization. Sorry for that.

Friday 31 January 2014

CSS Regions

If there is one and only article you should read about CSS Regions, that's this one. And the conclusion is quite clear and I agree with it:

CSS Regions give us the ability to do a lot of things that are otherwise not possible without them

Sunday 13 January 2013

CSS Paged Media and GCPM

I wrote a quite long article about the current CSS Paged Media and Generated Content for Paged Media specs/proposals and why they're outdated and are not enough. You can find it here,  on www-style.

Friday 17 August 2012

CSS Variables, why we drop the $foo notation

CSS Variables... A major request from the Web Authors' community since 1998...

Dave Hyatt and I shaped the first concrete public proposal in 2008 but the CSS Working Group could not reach an agreement about it. Variables, constants, mutable constants, OM or no OM, we had endless "religious" discussions about that and Hyatt finally removed his implementation from WebKit.

Then Tab Atkins made a breakthrough last february proposing a much better CSS integration, a model that fits nicely with what we already have. But then we had a problem with the $foo syntax everyone was asking for. Let me explain...

First, the proposed spec is NOT about variables and I seriously wonder if we should not change the title of the document. You may call the feature it introduces "variables" but at the deeper level, that's not about variables. That about Inherited User-Defined Properties. Don't take that as some political correctness or a blurb hiding the reality of the feature. The spec is really about letting you define your own properties and reaching their cascaded values. For instance:

div > p {
var-myprop: 1;
}

p {
var-myprop: 2;
}

In the above case, what will be the value of var(myprop) in a p contained into a div? Right, it will be 1 because the first rule has a higher specificity than the second one... Clearly, these beasts are not variables in the usual acceptance of the term.

Second, how are we going to use the values specified that way? We considered data(myprop), var(myprop) and $myprop. And despite of all the arguments expressed by the community in favor of the latter, the CSS WG decided during its recent San Diego face-to-face meeting to not follow the $foo path: $foo for the getter is too similar to a programming language, leading to confusion. The $ notation is used by preprocessors and script-based toolkits all over the place, it deeply conveys a notion of "programming language variable" or "preprocessor macro". And that's not what this spec is about since the feature introduced by the current spec shows important restrictions a variable or macro would not show:

  1. the value must be a set of valid CSS tokens; don't think of a preprocessor, don't dream of a partial string replacement. I repeat: a set of valid CSS tokens.
  2. you can't use the getter anywhere in CSS Stylesheets. You can use it only on the right-hand side of declarations (in other tems, after the colon in a '<property> : <values>' style declaration).
  3. we need an optional second argument to the getter giving a fallback value if the user-defined property is not set at all on the element.

Before shouting, don't misunderstand us: we clearly see the simplicity, readability and maintainability of the $foo syntax and we perfectly understand why the community prefers it. Being ourselves coders and implementors, we're used to manipulate $-based notations. But running that path implies too much confusion about our feature, will then lead to errors in live stylesheets, impacts existing CSS preprocessors that will have to change their own syntax to avoid collisions with ours, and will block us if we decide in the future to add real $-based macros to CSS. Again, we do understand why Web Authors prefer a compact and simple notation like $foo but we have decided it comes at a too expensive cost right now. We may reconsider this decision in the future (don't forget the spec is only a Working Draft at this time) but this will require solving all the issues detailed just above. Thanks.

Tuesday 19 June 2012

Media Queries and the 'view-mode' Media Feature are REC

Both Media Queries and the 'view-mode' Media Feature became officially a W3C Recommendation today. Yay !

Media Queries: http://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/

The 'view-mode' Meda Feature: http://www.w3.org/TR/2012/REC-view-mode-20120619/

Wednesday 6 June 2012

Transforms, Transitions and Animations

The CSS WG just resolved during its weekly conf call to allow browsers vendors to unprefix CSS 3 Transforms, Transitions and Animations immediately.

Wednesday 25 April 2012

The Open Web and CSS prefixes

Remember what I said a while ago here? I was not lying, here we are. :-(

Friday 3 February 2012

Wysiwyg is hard #5, CSS 3 Animations...

CSS 3 Animations are super powerful. I can't wait until they finally kill our JS-based animations. But they raise an issue that is well known by editor vendors: they're extremely difficult to manipulate in a wysiwyg environment, I already talked about it. As a matter of fact, none of the existing Animations editor on the market is able to edit a CSS 3 Animation wherever it comes from.

Here's the stylesheet I want us to look at today:

@keyframes bgchange {
  0%   { background-color: white; }
 100% { background-color: #b0b0b0; }
}

a { animation-name: bgchange; }

.dynamic { animation-duration: 1s }

What should a visual editor of Animations do with that ? It's totally impossible to infer from that stylesheet only that the dynamic class can apply in our document to anchors, so it's impossible to know the duration of the bgchange animation when it is applied.

An editor could present the bgchange keyframes rule, but only in a 0%-100% scale, not in a timeline since no duration is specified here. Even if you look for style rules specifying an animation-name, you won't be able to find an animation-duration...

In fact, we have this problem because we are mixing in CSS 3 Animations two notions: the animation itself and assigning an animation to an element. Authors of CSS 3 Animations chose to decorrelate the animation from time, and we have only percentages in the @keyframes rule. But that means such a rule cannot be presented as a timeline. They also chose to implement the assignment in a way the keyframes assignment and timing assignments can be independent; so they can't be presented as a timeline either...

Since Animations are a major feature of CSS 3 that will inevitably trigger more standalone and web-based apps to edit them, I think we have a rather serious design issue here. Some solutions are possible, they all have upsides and downsides:

  1. change the default value of animation-duration; it's currently 0 and it could become for instance 1s. In that case, presenting a timeline is always possible. Harm to existing web pages is low, most of the animations are set specifying name and duration in the same style rule and are usually triggered by a class or attribute.
  2. stop having individual properties for animation name, duration, delay and timing-function. One property only setting the four. That way, one the CSS rules in our example above must become .dynamic { animation: bgchange 1s; } and we don't have editability problems any more. That change will require roughly two thirds of existing web pages to update their code since they often set the individual properties.
  3. modify the @keyframes syntax to include mandatory default timeline metadata for that keyframes set. For instance something like:
    @keyframes bgchange 1s 3s ease-out {
     0%   { background-color: white; }
     100% { background-color: #b0b0b0; }
    }

    Since the animation shorthand property still sets animation-duration to 0, and since as said earlier most of the animations are set specifying name and duration in the same style rule, the effect on existing web pages will probably be minimal. If the web author does not use the shorthand but individual properties, unspecified properties (except animation-name of course) get their default value from the @keyframes rule. We also need to extend CSSKeyframesRule to be able to reach these default timeline values through the Object Model. I even suggest extending CSSKeyframeRule to be able to get the time corresponding to the percentage of that frame for the default timeline metadata of the current keyframes set. I must say this solution has my preference.

This list is not exhaustive at all and I'm all ears if you have something else on your mind. But we do have an editability problem here and that's one I would really like to see resolved, for once in CSS, or we will have only standalone and web-based editors able to edit only a very restricted set of Animations, and not all of them.

Please try to post your comments into www-style and not here. I started a thread here about this article and the problem it raises.

Monday 28 November 2011

One pseudo-class, one document, two layouts

It's possible at super-minimal cost to have for the same document liquid AND fixed-width layout, thanks to ZE POWA of CSS...

In a fixed-width document named index.html, you usually have a rule setting the width or max-width of the main element. Something like

#main750 {
  max-width: 750px;
}

Right? Now think :target pseudo-class and tweak your style rule as followed:

#main750:target {
  max-width: 750px;
}

Do you understand the trick?

Yeah, your document now has liquid layout if called by URL index.html and fixed-width layout if called by index.html#main750 :-) TADA !

- page 1 of 6