Tuesday 31 January 2017

Revenus salariaux bruts du couple Fillon en 2013

  • Société 2F Conseil : 282 508,00€ (source)
  • Député 2ème circonscription de Paris : 85 321,80€ (source)
  • Indemnité de frais de mandat parlementaire : 69 240,00€ (source)
  • Pénélope Fillon (Revue des Deux Mondes) :  60 000,00€ (source)
  • Pénélope Fillon (Assistante Parlementaire) : 60 000,00€ (estimation, source)

Total *estimé* : 557 069,80€, excusez du peu. MISE À JOUR : cette somme est brute, il ne faut pas oublier les charges sociales de l'emploi au sein de 2F Consei (une SARL unipersonnelle qui est probablement à l'IS) dont Fillon est le gérant majoritaire, donc non salarié. Je les estime à environ 50% du salaire versé, ce qui laisserait sur 2F Conseil un Net à Payer à Fillon d'environ 188 000€ sur cette année 2013, toujours d'après les liasse fiscale qui ne fait mention d'aucun autre employé que lui-même. 

Et sans oublier la gratuité SNCF et taxis parisiens, la dépense de l'état d'environ 80 000€ pour un ancien Premier Ministre, la potentielle indemnité en tant que conseiller communautaire de la communauté de communes de Sablé-sur-Sarthe, un potentiel salaire versé par l'UMP (de nombreux potentats UMP en avaient un), et les autres revenus d'autres sources ou encore inconnus à cette date.

Je crois que je vais dégueuler. Il est temps de revoir Le Président avec Jean Gabin, dans sa fameuse tirade à l'AN.

" Le Président " Jean Gabin par Radiopariman

Tuesday 17 January 2017


Long looooong ago, I wrote a deep review of the XHTML 2.0 spec that was one of the elements that led to the resuming of the HTML activity at the W3C and the final dismissal of XHTML 2.0. 

Long ago, I started a similar effort on EPUB that led to Dave Cramer's EPUB Zero. It's time (fr-FR) to draw some conclusions.

This document is maintained on GitHub and accepting contributions.

Daniel Glazman


  1. EPUB publications are not "just a zip". They are zips with special constraints. I question the "mimetype file in first uncompressed position" constraint since I think the vast majority of reading systems don't care (and can't care) because most of the people creating EPUB at least partially by hand don't know/care. The three last contraints (zip container fields) on the ZIP package described in section 4.2 of the spec are usually not implemented by Reading Systems.
  2. the container element of the META-INF/container.xml file has a version attribute that is always "1.0", whatever the EPUB version. That forces editors, filters and reading systems to dive into the default rendition to know the EPUB version and that's clearly one useless expensive step too much.
  3. having multiple renditions per publication reminds me of MIME multipart/alternative. When Borenstein and Freed added it to the draft of RFC 1341 some 25 years ago, Mail User Agents developers (yours truly counted) envisioned and experimented far more than alternatives between text/html and text/plain only. I am under the impression multiple renditions start from the same good will but fail to meet the goals for various reasons:
    1. each additional rendition drastically increases the size of the publication...
    2. most authoring systems, filters and converters on the market don't deal very well with multiple renditions
    3. EPUB 2 defined the default rendition as the first rendition with a application/oebps-package+xml  mimetype while the EPUB 3 family of specs defines it as the first rendition in the container
    4. while a MIME-compliant Mail User Agent will let you compose a message in text/html and output for you the multipart/alternative between that text/html and its text/plain serialization, each Publication rendition must be edited separately.
    5. in the case of multiple renditions, each rendition has its own metadata and it's then legitimate to think the publication needs its own metadata too. But the META-INF/metadata.xml file has always been quoted as "This version of the OCF specification does not define metadata for use in the metadata.xml file. Container-level metadata may be defined in future versions of this specification and in IDPF-defined EPUB extension specifications." by all EPUB specifications. The META-INF/metadata.xml should be dropped.
    6. encryption, rights and signatures are per-publication resources while they should be per-rendition resources.
  4. the full-path attribute on rootfile elements is the only path in a publication that is relative to the publication's directory. All other URIs (for instance in href attributes) are relative to the current document instance. I think full-path should be deprecated in favor of href here, and finally superseded by href for the next major version of EPUB.
  5. we don't need the mimetype attribute on rootfile elements since the prose of EPUB 3.1 says the target of a rootfile must be a Package Document, i.e. an OPF file... If EPUB 2 OCF could directly target for instance a PDF file, it's not the case any more for OCF 3.
  6. absolute URIs (for instance /files/xhtml/index.html with a leading slash, cf. path-absolute construct in RFC 3986) are harmful to EPUB+Web convergence
  7. if multiple renditions are dropped, the META-INF/container.xml file becomes useless and it can be dropped.
  8. the prose for the META-INF/manifest.xml makes me wonder why this still exists: "does not mandate a format", "MUST NOT be used". Don't even mention it! Just say that extra unspecified files inside META-INF directory must be ignored (Cf. OCF section 3.5.1) , and possibly reserve the metadata.xml file name, period. Oh, and a ZIP is also a manifest of files...
  9. I am not an expert of encryption, signatures, XML-ENC Core or XML DSIG Core, so I won't discuss encryption.xml and signatures.xml files
  10. the rights.xml file still has no specified format. Strange. Cf. item 8 above.
  11. Resource obfuscation is so weak and useless it's hilarious. Drop it. It is also painful in EPUB+Web convergence.
  12. RNG schemas are not enough in the OCF spec. Section about container.xml file for instance shouls have models and attribute lists for each element, similarly to the Packages spec.
  13. not sure I have ever seen links and link elements in a container.xml file... (Cf. issue #374). The way these links are processed is unspecified anyway. Why are these elements normatively specified since extra elements are allowed - and explicitely ignored by spec - in the container?


  1. a Package consists of one rendition only.
  2. I have never understood the need for a manifest of resources inside the package, probably because my own publications don't use Media Overlays or media fallbacks.
  3. fallbacks are an inner mechanism also similar to multipart/alternative for renditions. I would drop it.
  4. I think the whole package should have properties identifying the required technologies for the rendition of the Package (e.g. script), and avoid these properties on a per-item basis that makes no real sense. The feature is either present in the UA for all content documents or for none.
  5. the spine element represent the default reading order of the package. Basically, it's a list. We have lists in html, don't we? Why do we need a painful and complex proprietary xml format here?
  6. the name of the linear attribute, that discriminates between primary and supplementary content, is extremely badly chosen. I always forget what really is linear because of that.
  7. Reading Systems are free, per spec, to completely ignore the linear attribute, making it pointless from an author's point of view.
  8. I have never seen the collection element used and I don't really understand why it contains link elements and not itemref elements
  9. metadata fun, as always with every EPUB spec. Implementing refines in 3.0 was a bit of a hell (despite warnings to the EPUB WG...), and it's gone from 3.1, replaced by new attributes. So no forwards compatbility, no backwards compatibility. Yet another parser and serializer for EPUB-compliant user agents.
  10. the old OPF guide element is now a html landmarks list, proving it's feasible to move OPF features to html
  11. the Navigation Document, an html document, is mandatory... So all the logics mentioned above could be there.
  12. Fixed Layout delenda est. Let's use CSS Fragmentation to make sure there's no orphaned content in the document post-pagination, and if CSS Fragmentation is not enough, make extension contributions to the CSS WG.
  13. without 3.0 refines, there is absolutely nothing any more in 3.1 preventing Package's metadata to be expressed in html; in 3.0, the refines attribute was a blocker, implying an extension of the model of the meta html element or another ugly IDREF mechanism in html.
  14. the prefix attribute on the package element is a good thing and should be preserved
  15. the rendition-flow property is weird, its values being paginated, scrolled-continuous, scrolled-doc and auto. Where is paginated-doc, the simplest paginated mode to implement?
  16. no more NCX, finally...
  17. the Navigation Document is already a html document with nav elements having a special epub:type/role (see issue #941), that's easy to make it contain an equivalent to the spine or more.

Content Documents

  1. let's get rid of the epub namespace, please...

Media Overlays

  1. SMIL support across rendering engines is in very bad shape and the SMIL polyfill does not totally help. Drop Media Overlays for the time being and let's focus on visual content.

Alternate Style Tags

  1. terrible spec... Needed because of Reading Systems' limitations but still absolutely terrible spec...
  2. If we get rid of backwards compatibility, we can drop it. Submit extensions to Media Queries if needed.

On the fly conclusions

  1. backwards compatibility is an enormous burden on the EPUB ecosystem
  2. build a new generation of EPUB that is not backwards-compatible
  3. the mimetype file is useless
  4. file extension of the publication MUST be well-defined
  5. one rendition only per publication and no more links/link elements
  6. in that case, we don't need the container.xml file any more
  7. metadata.xml and manifest.xml files removed
  8. we may still need encryption.xml, signatures.xml and rights.xml inside a META-INF directory (or directly in the package's root after all) to please the industry.
  9. application/oebps-package+xml mimetype is not necessary
  10. the EPUB spec evolution model is/was "we must deal with all cases in the world, we move very fast and we fix the mistakes afterwards". I respectfully suggest a drastic change for a next generation: "let's start from a low-level common ground only and expand slowly but cleanly"
  11. the OPF file is not needed any more. The root of the unique rendition in a package should be the html Navigation Document.
  12. the metadata of the package should be inside the body element of the Navigation Document
  13. the spine of the package can be a new nav element inside the body of the Navigation Document
  14. intermediary summary: let's get rid of both META-INF/container.xml and the OPF file... Let's have the Navigation Document mandatorily named index.xhtml so a directory browsing of the uncompressed publication through http will render the Navigation Document.
  15. let's drop the Alternate Style Tags spec for now. Submission of new Media Queries to CSS WG if needed.
  16. let's drop Media Overlays spec for now.


EPUB is a monster, made to address very diverse markets and ecosystems, too many markets and ecosystems. It's weak, complex, a bit messy, disconnected from the reality of the Web it's supposed to be built upon and some claim (link in fr-FR) it's too close to real books to be disruptive and innovative.

I am then suggesting to severe backwards compatibility ties and restart almost from scratch, and entirely and purely from W3C Standards. Here's the proposed result:

1. E0 Publication

A E0 Publication is a ZIP container. Files in the ZIP must be stored as is (no compression) or use the Deflate algorithm. File and directory names must be encoded in UTF-8 and follow some restrictions (see EPUB 3.1 filename restrictions).

The file name of a E0 Publication MUST use the e0 file extension.

A E0 Publication MUST contain a Navigation Document. It MAY contain files encryption.xml, signatures.xml and rights.xml (see OCF 3.1 for more information). All these files must be placed directly inside the root of the E0 Publication.

A E0 Publication can also contain Content Documents and their resources.

Inside a E0 Publication, all internal references (links, anchors, references to replaced elements, etc) MUST be strictly relative. With respect to section 4.2 of RFC 3986, only path-noscheme and path-empty are allowed for IRIs' relative-part. External references are not restricted.

2. E0 Navigation Document

A E0 Navigation Document is a html document. Its file name MUST be index.xhtml if the document is a XML document and index.html if it it is not a XML document. A E0 Publication cannot contain both index.html and index.xhtml files.

A E0 Navigation Document contains at least one header element (for metadata) and at least two nav html elements (for spine and table of contents) in its body element.

2.1. E0 Metadata in the Navigation Document

E0 metadata are designed to be editable in any Wysiwyg html editor, and potentially rendered as regular html content by any Web browser.

E0 metadata are expressed inside a mandatory header html element inside the Navigation Document. That element must carry the "metadata" ID and the vocab attribute with value "http://www.idpf.org/2007/opf". All metadata inside that header element are then expressed using html+RDFa Lite 1.1. E0 metadata reuse EPUB 3.1 metadata and corresponding unicity rules, expressed in a different way.

Refinements of metadata are expressed through nesting of elements.


<header id="metadata"
<h1>Reading Order</h1> <ul> <li>Author: <span property="dc:creator">glazou
(<span property="file-as">Glazman, Daniel</span>)</span></li> <li>Title: <span property="dc:title">E0 Publications</span></li> </ul> </header>

The mandatory title element of the Navigation Document, contained in its head element, should have the same text contents than the first "dc:title" metadata inside that header element.

2.2. E0 Spine

The spine of a E0 Publication is expressed in its Navigation Document as a new nav element holding the "spine" ID. The spine nav element is mandatory.

See EPUB 3.1 Navigation Document.

2.3. E0 Table of Contents

The Table of Contents of a E0 Publication is expressed in its Navigation Document as a nav element carrying the "toc" ID. The Table of Contents nav element is mandatory.

See EPUB 3.1 Navigation Document.

2.4. E0 Landmarks

The Landmarks of a E0 Publication is expressed in its Navigation Document as a nav element carrying the "landmarks" ID. The Landmarks nav element is optional.

See EPUB 3.1 Navigation Document.

2.5. Other nav elements

The Navigation Document may include one or more nav elements. These additional nav elements should have an role attribute to provide a machine-readable semantic, and must have a human-readable heading as their first child.

IDs "metadata", "spine" , 'landmarks" and "toc" are reserved in the Navigation Document and must not be used by these extra nav elements.

2.6. Example of a Navigation Document

<!DOCTYPE html>
<html lang="en">
    <meta content="text/html; charset=UTF-8" http-equiv="content-type">
    <header id="metadata"
          <span property="dc:creator">Herman Melville
(<span property="file-as">Melville Herman</span>)</span></li> <li>Title: <span property="dc:title">Moby-Dick</span></li> <li>Identifier: <span property="dc:identifier">glazou.e0.samples.moby-dick</span></li> <li>Language: <span property="dc:language">en-US</span></li> <li>Last modification: <span property="dcterms:modified">2017-01-17T11:16:41Z</span></li> <li>Publisher: <span property="dc:publisher">Harper & Brothers, Publishers</span></li> <li>Contributor: <span property="dc:contributor">Daniel Glazman</span></li> </ul> </header> <nav id="spine"> <h1>Default reading order</h1> <ul> <li><a href="cover.html">Cover</a></li> <li><a href="titlepage.html">Title</a></li> <li><a href="toc-short.html">Brief Table of Contents</a></li> ... </ul> </nav> <nav id="toc" role="doc-toc"> <h1>Table of Contents</h1> <ol> <li><a href="titlepage.html">Moby-Dick</a></li> <li><a href="preface_001.html">Original Transcriber’s Notes:</a></li> <li><a href="introduction_001.html">ETYMOLOGY.</a></li> ... </ol> </nav> </body> </html>

3. Directories

A E0 Publication may contain any number of directories and nested directories.

4. E0 Content Documents

E0 Content Documents are referenced from the Navigation Document. E0 Content Documents are html documents.

E0 Content Documents should contain <link rel="prev"...> and <link rel="next"...> elements in their head element conformant to the reading order of the spine present in the Navigation Document. Content Documents not present in that spine don't need such elements.

The epub:type attribute is superseded by the role attribute and must not be used.

5. E0 Resources

E0 Publications can contain any number of extra resources (CSS stylesheets, images, videos, etc.) referenced from either the Navigation Document or Content Documents.

Monday 16 January 2017

Livre électronique, qu'est-ce qu'on a raté ?

Studio Walrus vient de poser une EXCELLENTE question sur twitter :

Je livre ci-dessous ma réponse, uniquement valable de mon point de vue, en quelques points :

  1. côté marché, le livre électronique est en général beaucoup, vraiment beaucoup, trop cher. Quand un livre papier est à 18€ et que sa version électronique, que l'on ne peut ni prêter, ni donner, ni léguer, ni partager, est à 14€, le client potentiel a l'impression (pun intended) qu'on se fout se sa gueule et il a totalement raison.
  2. côté technique, l'investissement R&D est bien trop maigre. Je pense en particulier à ce groupe majeur d'édition dont la page d'accueil Web est invisitable sans Flash... Comment espérer dans ces conditions que le Web et EPUB soient bien compris.
  3. EPUB est trop compliqué et les chaînes logicielles éditoriales sont du coup trop compliquées et surtout trop rares.
  4. je visite régulièrement des librairies où je flâne entre les rayons pour trouver mon bonheur. De temps en temps, j'aimerais pouvoir instantanément acheter en version ebook le livre que je tiens entre les mains mais c'est impossible... Les librairies sont faites pour vendre le papier, les sites Web et les devices le livre électronique. L'intégration n'est pas réalisée.
  5. je le répète, l'incapacité à gérer ses livres électroniques comme on gère ses livres papier (prêt, don, leg, partage) est un point bloquant majeur. Et je ne parle même pas de la sauvegarde définitive en local de ses livres électroniques...
  6. les liseuses de qualité restent très, très chères. Prenons l'exemple d'une Kindle Paperwhite. Entre 130 et 200€ si mes souvenirs sont bons. La Kindle Oasis commence à près de 300€ !!! C'est trop cher pour des livres électroniques dont le prix n'est pas très éloigné du prix papier. Il faudrait que les vendeurs de devices adoptent, par exemple, le modèle des imprimantes et de l'encre : machine très peu chère et consommables chers. Mais même comme cela, je crois que des ebooks non spécialisés au-delà de 10€ sont un modèle qui ne peut atteindre le plein succès.
  7. c'est aussi le vieux conflit entre le sustaining market et la disruptive innovation
  8. la lecture sur téléphone mobile est insupportable sur le long terme à cause du format d'écran, la lecture sur tablette est insupportable sur le long terme à cause du poids de la tablette d'une part et de l'autonomie batterie de la machine d'autre part. Seules les liseuses à encre électronique sont praticables.
  9. de nombreux ebooks ne se servent d'EPUB que comme packaging d'un formatage quasi-fixe, sans utiliser toute la puissance du Web. C'est parfois parce que les moteurs de restitution des liseuses sont mauvais, parfois parce que les éditeurs n'ont toujours pas compris comment réellement tirer parti de la technologie, parfois encore parce qu'ils ne veulent surtout pas tirer entièrement parti de la technologie...
  10. la qualité des ebooks n'atteint pas celle du papier. Sans parler des limites de la technologie, j'ai trop souvent vu des images de qualité réduite, des index manquants ou sans hyperliens (connerie sans nom !), j'en passe et des meilleures.
  11. et je n'oublie pas une espèce d'arrogance qui met une majuscule à « culture » quand elle est couchée sur papier

Sunday 8 January 2017

Thoughts on the royal Castle of Chambord #2

I feel the need to add context to the contents of my previous article about the architecture of the royal Castle of Chambord, probably one of the most beautiful castles in France. It's commonly accepted that the castle was built based on a grid layout, and the french version of Wikipedia has some details about that design:

Architecture of Chambord
Plan illustrant le concept initial du Château - Monsieur W, CC0

Unfortunately, this theory is really partial since it does not explain many, too many choices:

  • on the grid above, the dungeons seems carefully aligned with the grid, and the center of the towers should then be perfectly aligned with the sides of the main body of the castle. It is very clear from the map and de visu that it's not the case. The main body of the castle eats lets than a fourth of each tower and, again, it's extremely visible if you pay a real-life visit to the castle: the two angles between a tower's walls and the main body are less than 90°.
  • this does not explain how the size of the main body of the castle was chosen
  • the grid above works only if the center column and row are slightly larger than the other ones
  • it does not explain the obvious ratios between the castle itself and its enclosure
  • with my Standards freak's eye, there are too many things left unspecified

So I think the way the castle was designed is different and I think the WHOLE basis for it is the diameter of the towers/enclosure towers. Once that value is specified, the whole castle can be entirely derived from very basic operations that are so simple a rule and a compass are enough to draw the whole thing.

Before diving into the architecture of the main body of the castle itself, we must see that the enclosure of the castle (without towers) is very precisely a scale(3, 2) of the main body of the castle (without towers). So if we can show that the main body of the castle itself is determined solely from the diameter of the towers, it will imply the whole architecture, from enclosure to main body will rely on a single length only !

Let's do that here...

If you take the result of that experiment and overlay it over the map of the main body of the castle, it's a perfect and precise match. Since the enclosure is trivial to determine from here, the whole plan relies, as expected, on a single value : the diameter of the towers.

Chambord is a mathematical construct, with the computation of a square enclosing a pavement of 5 circles, a placement of 4 of the same circles around the square and then a trivial scaling of that construct to build the enclosure. I'm pretty sure we could also find a scale ratio between the height of the enclosure and the height of the main body of the castle.

All in all, the grid system quoted above seems to me approximative, and most probably mistaken.

Thoughts on the royal Castle of Chambord

I saw yesterday night a wonderful documentary about the Castle of Chambord on Arte channel. At some point, an old map of the castle was shown and it triggered immediately my interest because the dungeons are not centered on the corners of the castle. I wondered why, and more importantly how. I am not sure to completely buy the current explanation where the castle was designed on a grid because it does not explain the perfect ratio between the dungeons' diameter and the size of the main body of the castle. And then I saw something simple, really simple, that could explain how the plan of castle was designed. Here's my little experiment.

Tuesday 3 January 2017

One BlueGriffon

There are - there were - two BlueGriffons: the Web Editor (aka BlueGriffon) and the EPUB2/EPUB3 editor (aka BlueGriffon EPUB Edition). With forthcoming v2.2, these are going to merge into a single product so they will never be out of sync again. Technically, the merge is already achieved and the next days will be spent on testing/ironing. Licenses for each product will work with that v2.2. BlueGriffon licenses will, as before, enable the commercial features of the product while licenses of the EPUB Edition will enable the commercial features AND EPUB2/EPUB3 editing. We'll also add an upgrade at special cost from the former to the latter. Stay tuned!

BlueGriffon 2.2

Thursday 29 December 2016


  • les options politiques de Fillon commencent à foutre la trouille à son propre camp. Avec une telle rupture ultra-libérale, il risque fort de ne pas faire le plein de voix dans son propre camp, Les Républicains. Son considérable score de la primaire, c'est tout d'abord des CSP+ et retraités cathos et ensuite de l'anti-sarkozisme. C'est inextrapolable à l'élection générale.
  • l'aréopage de cathos plutôt réacs (anti-mariage pour tous, anti-avortement, anti-contraception, mais tout ça "à titre personnel" hein...) me fait penser à l'emprise du Tea Party sur les Republicans américains. On se croirait en 1955.
  • cela me fait également penser à la catastrophe induite par le même Tea Party... Décomposition des Republicans, attaques contre la Science, virage religieux et extrême-droitier, et finalement sélection et élection de Trump qui avait dit que s'il devait se présenter, il le ferait sous les couleurs Républicaines car les électeurs de ce parti sont les plus bêtes
  • je pense donc que faute de rassemblement, Fillon est assez loin d'être élu et il a raison de tempérer l'enthousiasme de ses troupes.
  • si Fillon perd, sa carrière sera terminée et les Républicains seront explosés. Ils seront mûrs pour une offensive des derniers Buissonistes, Wauquiez et autres djeunz à la limite de l'extrême-droite. Comme le Tea Party. Les Républicains se rendront également compte, trop tard, que Juppé était mieux placé pour le rassemblement. La Primaire aura du plomb dans l'aile.
  • en 2022, on aura alors deux extrême-droites présentes à l'élection présidentielle. L'une officielle, l'autre cachée.

Tuesday 27 December 2016

WAI-ARIA 1.1 and DPUB-ARIA 1.0 in BlueGriffon

I have just added support for WAI-ARIA 1.1 and DPUB-ARIA 1.0 to the trunk of BlueGriffon. The next public version (2.2) will include those changes. In the meantime, a OS X trial version is available from here. You'll find the changes implemented inside the new panel Panels > ARIA.

Monday 5 December 2016

MacBookPro 2016 with Touchbar

I spent a short while playing with a new MacBookPro 15" with Touchbar at the Apple Store. Conclusions:

  • I hate the keyboard that is too thin and has too little space between the keys. I made so many typing mistakes with it... This is a keyboard for people who don't use a lot their keyboard, not a keyboard for code developers
  • the Touchbar is a PITA and a strong disruption because it adds another layer of input/output between the keyboard and the screen. "Typing" on the Touchbar too often requires moving your eyes from the screen to the Touchbar and losing focus when you go back to the screen. For each app, you have to learn a new Touchbar design, and some apps have more than one. A mess. And it does not counter-balance the loss of the Escape and function keys.
  • the screen seems better and brighter than on my mid-2014 retina MacBook Pro.
  • Apple Store people themselves are extremely cautious with the USB-C-based power supply when they move a MBP. MagSafe, we all miss you.
  • Touch ID is cool but I noticed the Touch ID key does not seem to be oleophobic so the fingerprint of the person who unlocked the MBP can be very visible. Probably not too difficult to copy it.
  • I have doubts on the readability/usability of the TouchBar in high-light conditions
  • the price, the price, the price !!! The 15" model with Touchbar starts at $2,889.00 here in France (price converted from € to $ at today's exchange rate), urgh !!!

For the time being, I am more than happy with my mid-2014 model and I don't plan to change. This would probably feel like a downgrade to me.

Friday 2 December 2016

Bal tragique à Paris, plein de morts

Le PPF (paysage politique français) est bien secoué, dites donc :

  • un Président out (Hollande)
  • un ex-Président out (Sarkozy)
  • un ex-Premier Ministre out (Juppé)
  • un autre ex-Premier Ministre out (Raffarin, qui n'est plus dans l'organigramme de LR)
  • plein d'ex-Ministres juppéistes sur le carreau
  • plein de Ministres hollandistes sur le carreau en mai prochain

Je m'amuse, mais je m'amuse !

Thursday 1 December 2016

Eighteen years later

In December 1998, our comrade Bert Bos released a W3C Note: List of suggested extensions to CSS. I thought it could be interesting to see where we stand 18 years later...

Id Suggestion
active WD CR, PR or REC Comment
1 Columns
2 Swash letters and other glyph substitutions
3 Running headers and footers
4 Cross-references
5 Vertical text
6 Ruby
7 Diagonal text through Transforms
7 Text along a path
8 Style properties for embedded 2D graphics ➡️ ➡️ through filters
9 Hyphenation control
10 Image filters
11 Rendering objects for forms
12 :target
13 Floating boxes to top & bottom of page
14 Footnotes
15 Tooltips possible with existing properties
16 Maths there was no proposal, only an open question
17 Folding lists possible with existing properties
18 Page-transition effects
19 Timed styles Transitions & Animations
20 Leaders
21 Smart tabs not sure it belongs to CSS
22 Spreadsheet functions does not belong to CSS
23 Non-rectangular wrap-around Exclusions, Shapes
24 Gradients Backgrounds & Borders
25 Textures/images instead of fg colors
26 Transparency opacity
27 Expressions partly calc()
28 Symbolic constants Variables
29 Mixed mode rendering
30 Grids for TTY
31 Co-dependencies between rules Conditional Rules
32 High-level constraints
33 Float: gutter-side/fore-edge-side
34 Icons & minimization
35 Namespaces
36 Braille
37 Numbered floats GCPM
38 Visual top/bottom margins
39 TOCs, tables of figures, etc.
40 Indexes
41 Pseudo-element for first n lines
42 :first-word
43 Corners border-radius and border-image
44 Local and external anchors Selectors level 4
45 Access to attribute values ➡️ access to arbitrary attributes hosted by arbitrary elements theough a selector inside attr() was considered and dropped
46 Linked flows Regions
47 User states
48 List numberings Counter Styles
49 Substractive text-decoration
50 Styles for map/area ➡️ ➡️ never discussed AFAIK
51 Transliteration ➡️ ➡️ discussed and dropped
52 Regexps in selectors
53 Last-of... selectors
54 Control over progressive rendering
55 Inline-blocks
56 Non-breaking inlines white-space applies to all elements since CSS 2.0...
57 Word-spacing: none
58 HSV or HSL colors
59 Standardize X colors
60 Copy-fitting/auto-sizing/auto-spacing Flexbox
61 @page inside @media
62 Color profiles dropped from Colors level 3 but in level 4
63 Underline styles
64 BECSS ➡️ ➡️ BECSS, dropped
65 // comments
66 Replaced elements w/o intrinsic size object-fit
67 Fitting replaced elements object-fit

Wednesday 30 November 2016

Rest in peace, Opera...

I think we can now safely say Opera, the browser maker, is no more. My opinions about the acquisition of the browser by a chinese trust were recently confirmed and people are let go or fleeing en masse. Rest in Peace Opera, you brought good, very good things to the Web and we'll miss you.

In fact, I'd love to see two things appear:

  • Vivaldi is of course the new Opera, it was clear from day 1. Even the name was chosen for that. The transformation will be completed the day Vivaldi joins W3C and sends representatives to the Standardization tables.
  • Vivaldi and Brave should join forces, in my humble opinion.

Thursday 24 November 2016

Fillon au top depuis 72 heures, il merde déjà

Consternation... Fillon est au firmament depuis dimanche 22h et il a déjà lamentablement merdé. Hier matin, sur Europe 1, il a prononcé les propos suivants :

il faut combattre cet intégrisme, et il faut le combattre comme d’ailleurs dans le passé je le rappelle on a combattu une forme d’intégrisme catholique ou comme on a combattu la volonté des Juifs de vivre dans une communauté qui ne respectait pas toutes les règles de la république française.

Vu le déluge qui lui est logiquement tombé dessus, il a hier soir, via Facebook (qui est bien plus pratique de ce point de vue qu'un Bourdin ou un Aphatie qui l'auraient étrillé...), posté le communiqué suivant :

Depuis ce matin, certains essayent d’exploiter une phrase que j’ai prononcée sur Europe 1. Il n’a jamais été dans mon intention de remettre en cause l’attachement de la communauté juive de France à nos valeurs communes et au respect des règles de la République. Cet attachement est ancien et sincère, je le sais. Je déplore donc qu’en cette fin de campagne certains aient osé instrumentaliser mes propos.

Lamentable... Qu'il nous précise donc où, quand, comment depuis l'époque de la révolution les juifs de France n'ont pas respecté les règles de la république française. Il me semble que c'est plutôt la République qui n'a souvent pas respecté ses propres règles vis-à-vis de ses citoyens juifs. Fillon a merdé, et bien bas. Déjà. Commentaires coupés sur cet article.

Tuesday 18 October 2016

La Cyberdéfense française

Cash Investigation vient d'interviewer le Vice-Amiral Coustillière. Je passe sur le fait qu'il parle de « blackdoor » pour revenir sur ses propos expliquant son choix. Ce type est totalement à côté de la plaque et a démontré en vingt secondes son incompétence totale en la matière. Il a raconté n'importe quoi et ne mesure absolument pas la portée de ses propos, de ses choix, de ses faiblesses mais surtout des faiblesses qu'il vient d'introduire dans la Défense Nationale française. Monsieur Le Drian, vous êtes là ?

Monday 17 October 2016

Un dimanche soir presqu'ordinaire

Dimanche soir 18h45, je suis en voiture pour une course simple. A deux pas de chez moi, une voiture blanche s'apprête, de l'autre côté de la rue, à sortir du parking d'un immeuble. La suite m'a donné des sueurs froides...

  • Alors qu'un véhicule arrive dans le sens de circulation le plus proche de la sortie du dit-parking et que j'arrive dans le sens inverse, la voiture sort du parking à vitesse assez lente et passe devant moi. Le gars arrivant en face est obligé de piler net en klaxonnant, je suis obligé de piler net en klaxonnant.
  • La voiture fautive est un taxi local. Il n'est pas en service mais le bloc lumineux Taxi est bien posé sur le toit de cette Toyota hybride blanche.
  • Le conducteur commence immédiatement à conduire n'importe comment, incapable de garder une ligne droite. À 50 mètres de là, il fait une incursion brève sur la file inverse foutant la trouille à un vélo.
  • Le véhicule s'arrête au feu rouge et je vois la tête du conducteur dodeliner. Le feu passé au vert, le gars démarre tant bien que mal, incapable à nouveau de garder la ligne droite.
  • Cent mètres plus loin dans une forte descente devant l'entrée d'un gymnase, le véhicule fait une première embardée sur le trottoir...
  • Virage à droite lors d'un stop. La voiture s'est arrêtée au milieu de la chaussée, à moitié sur la file de gauche. Une autre voiture qui tournait dans cette rue a la frayeur de sa vie. Le taxi finit par tourner à droite, mord le trottoir sur sa droite, se repositionne en milieu de chaussée, évite une fourgonette puis finit par se stabiliser à peu près dans sa file.
  • Trois cent mètres plus loin, nouvelle embardée sur le trottoir dans un virage vers la droite en côte. Heureusement, aucun piéton.
  • Puis virage à gauche hallucinant, pris presque intégralement sur la file inverse avant de grimper carrément sur le trottoir de droite dans un superbe mouvement de zigzag. Heureusement, toujours pas de piéton, mais quelques sueurs froides dans les voitures arrivant en face...
  • Je vous passe la suite, du même acabit.

Bon clairement, le type était bourré comme une outre, incapable de conduire, terriblement dangereux. Et un taxi qui plus est... Comme il se dirigeait en plein centre-ville, j'ai prévenu la police municipale immédiatement qui m'a chaleureusement remercié. Et je ne suis pas prêt d'oublier l'immatriculation du taxi en question...

Tuesday 20 September 2016


J'ai toujours dit que la standardisation au W3C, c'est de l'hémoglobine sur les murs dans une ambiance feutrée. Je ne changerai pas un iota à cette affirmation. Mais le W3C c'est aussi l'histoire d'une industrie dès ses premières heures et des amitiés franches construites dans l'explosion d'une nouvelle ère. J'ai passé ce soir, en marge du Technical Plenary Meeting du W3C à Lisbonne, un dîne inoubliable avec mes vieux potes Yves et Olivier que je connais et apprécie depuis ohlala tellement longtemps. Un moment délicieux, sympa et drôle autour d'un repas fabuleux dans une gargote lisboète de rêve. Des éclats de rire, des confidences, une super-soirée bref un vrai moment de bonheur. Merci à eux pour cette géniale soirée et à Olivier pour l'adresse, en tous points extra. Je re-signe quand vous voulez, les gars, et c'est un honneur de vous avoir comme potes :-)

Thursday 15 September 2016

email in iOS 10

Disclaimer: I know a thing or two about an email client and another one and viewports and line wrapping and html-based email...

I updated iOS on my iPhone yesterday night and suddenly, one of the apps I am using every 2 minutes is severely broken. Since I don't understand how so severe UI bugs were let by QA into this release, I feel the need to give here my fedback.

First email I checked was a CSS WG message in a conversation of two messages. I did not tweak at all the Settings before looking at my email. Here's a screenshot of what appeared:

conversation iOS10

So many things are completely borked here I cannot count them all:

  • unreadable font size
  • Plus button overflowing the message's prose
  • "Se désabonner" ("Unsubscribe") taking far too much space and repeated
  • no idea how to enlarge one given email
  • at least two clicks required now to view a message in a conversation while only one was needed before the update
  • no idea if and how Settings can be changed about this view

Globally, the user experience is horrible. Then I tried to view another message, not in a conversation...

standalone email iOS10

Again, plenty of issues here:

  • totally unreadable font size...
  • 1/3 of vertical space eaten by navigation button and headers with enormous vertical margins around all headers
  • no reflow if I zoom in the message, forcing me to move the viewport a dozen of times to read the message

Worse, as far as I can tell, there is strictly nothing in the Mail Settings allowing me to change the current behaviour, increase the font size, avoid showing conversations. Some trivial richtext emails are correctly rendered, some other ones are not and I fail seeing what is the issue comparing the two markups.

All in all, it's a rather severe regression. Everything that used to require one click now requires several, the UI is a pile of crap and it really feels it was not reviewed nor tested correctly. Wow.

Update: Apple knows and is working on it.

Monday 12 September 2016

Code en primaire

On vient de me demander sur twitter ce que je pensais de l'initiative ministérielle d'introduire la programmation dès l'école primaire. Je vais vous expliquer ci-dessous pourquoi je suis assez mal placé pour répondre, malgré toutes les bonnes raisons que vous imaginez que je pourrais avoir :

  • quand j'ai moi-même commencé à coder, pas un seul autre élève de mon collège parisien n'avait jamais même vu un ordinateur. Je dis bien vu. Aujourd'hui, les enfants sont familiarisés avec les tablettes, les consoles et souvent les ordinateurs depuis leur plus jeune âge, et cela change tout.
  • j'étais très en avance et donc l'âge auquel j'ai moi-même commencé la programmation ne peut être significatif
  • je suis tombé dedans comme Obelix dans la marmite de potion magique, cela a été une vocation dès la première minute. Je ne peux donc être représentatif et mon opinion est forcément fortement biaisée.

Ceci dit, on sait désormais que :

  • même les très jeunes bébés sont capables de tout apprendre, y compris la langue des signes à six mois
  • que le cerveau enfantin, de TOUS les enfants, est une éponge d'une magnitude que l'on commence seulement à soupçonner
  • qu'un des frein majeurs à l'apprentissage des mathématiques est l'absence de construction logique

En théorie, je serais donc plutôt favorable à la mesure. MAIS il ne faut pas oublier le reste :

  • une proportion tout simplement hallucinante d'élèves sortent du primaire avec un niveau de français et de calcul TRÈS insuffisant pour le collège. Apprendre à programmer, c'est la cerise sur le gâteau. Or le gâteau est d'une qualité de plus en plus mauvaise et je crois qu'il faudrait focaliser sur la qualité du gâteau avant de penser à fignoler le glaçage.
  • un élève totalement infoutu de calculer de tête des choses simples aura du mal à visualiser une réflexion algorithmique même triviale
  • en plus pure théorie, je me demande bien qui va assurer ces cours de programmation. Les CAPES ne font pas le plein, les profs ne sont plus formés et on leur balance des nouveautés à assurer pratiquement sans qu'ils soient mis à niveau. On compte sur qui, là ? Des informaticiens débutants payés au SMIC mais sans expérience pédagogique ? Des profs de maths qu'on n'aura pas le temps de former ?

Donc toujours en théorie, je reste favorable à la mesure. En pratique, je crois que l'École a d'autres chantiers bien plus urgents que mettre en place une nouvelle usine à gaz. L'initiation à la programmation me semblerait bien plus pertinente en classe de 4ème.

Friday 9 September 2016

Les clopes françaises ont-elles empêché un attentat ?

Depuis des années, les cigarettes françaises s'éteignent si on ne tire pas dessus. Tout fumeur a déjà fait l'expérience d'une cigarette posée dans un cendrier qui s'éteint désormais alors qu'il y a quelques années, elle se consumait complètement. Or le Procureur de la République de Paris vient de déclarer que la voiture chargée de bouteilles de gaz à côté de Notre-Dame contenait une couverture légèrement imbibée d'essence sur laquelle se trouvait une cigarette à peine consumée. Il est donc probable que la cigarette se soit rapidement éteinte au lieu de continuer à brûler... Première fois qu'une clope sauve des gens, non ?

Monday 29 August 2016

« L'überisation du dernier kilomètre » ou « TNT, livraison en soirée »

Ayant eu besoin d'un disque dur 2,5" en urgence, je l'ai commandé sur Amazon jeudi soir avec une livraison garantie vendredi en soirée. Je ne connaissais pas ce type de livraison, que j'ai trouvé relativement pratique vu que j'étais certain d'être chez moi entre 19h00 et 22h00. Ce que j'ignorais par contre, c'est que le transporteur qui gère ce type de livraison, TNT, se repose sur des livreurs privés utilisant leurs propres véhicules et rémunérés à la pièce... L'überisation des derniers kilomètres de la livraison en horaire garanti, quoi...

Et bien ce n'est pas garanti que cela marche, justement :

  • pas de livraison vendredi soir
  • pas de contact
  • pas de SMS malgré la fourniture de mes coordonnées
  • découverte à 23h30 que le livreur a déclaré vers 21h30 un souci de véhicule
  • alors que j'espérais une re-livraison le samedi matin, que pouïc. Le livreur privé travaille en soirée donc cela sera un retard de 24h, avec livraison samedi entre 19h et 22h à nouveau...
  • toujours aucun contact avec TNT
  • toujours pas de livraison samedi entre 19h et 22, même Amazon qui réagit à merveille n'arrive pas à les joindre !!!
  • découverte à minuit que le livreur, le même, a déclaré vers 21h00 un "souci extérieur" (comme c'est un beau libellé n'est-ce pas ?) et que la livraison est reprogrammée pour le prochain jour ouvré, soit lundi, et évidemment de nouveau entre 19 et 22h. Au lieu de 24h de livraison garantie, on sera donc à 96... Amazon (dont le service client - qui était déjà très bien - a fait un énorme bond qualitatif et s'approche du parfait) me rembourse alors mes frais de livraison et m'offre un mois gratuit de je-ne-sais-plus-quoi.
  • alors que je ne m'y attends pas du tout, et qu'il est heureux que je sois dans mon salon, on sonne chez moi dimanche soir. TNT !!! Le chauffeur est dans une 508 noir, clairement son véhicule privé. Il a trois ou quatre colis à livrer et me dit immédiatement qu'il livre à la place d'un autre livreur, celui qui était initialement programmé et a préféré aller courir la pampa à la place... Il est vraiment très embêté quand je lui dis que je ne crois pas une seconde aux soucis de véhicule deux soirs de suite du livreur d'origine. Il est encore plus embêté quand je lui dis que j'ai déposé réclamation chez Amazon et que je vais faire de même chez TNT.
  • In fine, aucune excuse, aucune explication, aucun contact, aucune satisfaction.

Soyons clair, l'überisation du dernier kilomètre, ça va poser des problèmes sérieux aux gros cybervendeurs si à chaque livraison il faut faire la chasse aux branleurs qui rentrent se coucher ou partent draguer la pitchounette au lieu d'assurer leur mission de livraison en temps et heure. Le service fourni par TNT en la matière est nul, son contact client est totalement inexistant, la supervision des livreurs est inexistante, l'image de TNT est écornée, elle écorne l'image de son client Amazon par la même occasion, et il est clair que je n'ai aucune envie d'utiliser TNT pour les éventuelles livraisons de l'entreprise que je dirige.

La livraison en soirée garantie entre 19h et 22h, c'est pourtant une excellente idée. En tous cas en région parisienne, c'est une excellente idée vus les horaires de dingue qu'on effectue dans le coin. Mais comme ça, avec des livreurs autonomes à peine managés et gérant comme ils l'entendent ou presque leurs livraisons, cela ne peut aller qu'au fiasco. Il va clairement falloir que TNT révise sa copie, et à mon avis en urgence.

- page 2 of 287 -