Monday 15 May 2017

W3C Advisory Board elections

The W3C Advisory Board (AB) election 2017 just started, and I am not running this time. I have said multiple times the way people are elected is far too conservative, giving a high premium to "big names" or representatives of "big companies" on one hand, tending to preserve a status-quo in terms of AB membership on the other. Newcomers and/or representative of smaller companies have almost zero chance to be elected. Even with the recent voting system changes, the problem remains.

Let me repeat here my proposal for both AB and TAG: two consecutive mandates only; after two consecutive mandates, elected members cannot run again for re-election at least during at least one year.

But let's focus on current candidates. Or to be more precise, on their electoral program:

  1. Mike Champion (Microsoft), who has been on the AB for years, has a clear program that takes 2/3rds of his AB nominee statement.
    1. increase speed on standards
    2. bridge the gap existing between "fast" implementors and "slow" standards
    3. better position W3C internally
    4. better position W3C externally
    5. help the Web community
  2. Rick Johnson (VitalSource Technologies | Ingram Content Group) does not have a detailed program. He wants to help the Publishing side of W3C.
  3. Charles McCathie Nevile (Yandex) wants
    1. more pragmatism
    2. to take "into account the broad diversity of its membership both in areas of interest and in size and power" but he has "been on the AB longer than any current participant, including the staff", which does not promote diversity at all
  4. Natasha Rooney (GSMA) has a short statement with no program at all.
  5. Chris Wilson (Google Inc.), who has also been elected to the AB twice already, wants :
    1. to engage better developers and vendors
    2. to focus better W3C resources, with more agility and efficiency
    3. to streamline process and policies to let us increase speed and quality
  6. Zhang Yan (China Mobile Communications Corporation) does not really have a clear program besides "focus on WEB technology for 5G, AI and the Internet of things and so on"
  7. Judy Zhu (Alibaba (China) Co., Ltd.) wants:
    1. to make W3C more globalized (good luck on that one...)
    2. to make W3C Process more usable/effective/efficient
    3. increase W3C/industries collaboration (but isn't it a industrial consortium already?)
    4. increase agility
    5. focus more on security and privacy

If I except the mentions of agility and Process, let me express a gut feeling: this is terribly depressing. Candidacy statements from ten years ago look exactly the same. They quote the same goals. They're even phrased the same way... But in the meantime, we have major topics on the meta-radar (non-exhaustive list):

  • the way the W3C Process is discussed, shaped and amended is so incredibly long it's ridiculous. Every single major topic Members raised in the last ten years took at least 2 years (if not six years) to solve, leaving Groups in a shameful mess. The Process is NOT a Technical Report that requires time, stability and implementations. It's our Law, that impacts our daily life as Members. When an issue is raised, it's because it's a problem right now and people raising the issue expect to see the issue solved in less than "years", far less than years.
  • no mention at all of finances! The finances of the W3C are almost a taboo, that only a few well-known zealots like yours truly discuss, but they feed all W3C activities. After years of instability, and even danger, can the W3C afford keeping its current width without cutting some activities and limiting its scope? Can the W3C avoid new revenue streams? Which ones?
  • similarly, no mention of transparency! I am not speaking of openness of our technical processes here, I am very clearly and specifically speaking of the transparency of the management of the Consortium itself. The way W3C is managed is far too vertical and it starts being a real problem, and a real burden. We need changes there. Now.
  • the role of the Director, another taboo inside W3C, must be discussed. It is time to acknowledge the fact the Director is not at the W3C any more. It's time to stop signing all emails "in the name of the Director', handle all transition conference calls "in the name of the Director" but almost never "with the Director". I'm not even sure we need another Director. It's time to acknowledge the fact Tim should become Honorary Director - with or without veto right - and distribute his duties to others.
  • we need a feedback loop and very serious evaluation of the recent reorganization of the W3C. My opinion is as follows: nobody knows who to contact and it's a mess of epic magnitude. The Functional leaders centralize input and then re-dispatch it to others, de facto resurrecting Activities and adding delays to everything. The reorg is IMHO a failure, and a rather expensive one in terms of effectiveness.
  • W3C is still not a legal entity, and it does not start being a burden... it's been a burden for eons. The whole architecture of W3C, with regional feet and a too powerful MIT, is a scandalous reminiscence of the past.
  • our election system for AB and TAG is too conservative. People stay there for ages, while all our technical world seems to be reshaped every twelve months. My conclusion is simple, and more or less matches what Mike Champion said : the Consortium is not tailored any more to match its technical requirements. Where we diverge: I understand Mike prefers evolution to revolution, I think evolution is not enough any more and revolution is not avoidable any more. We probably need to rethink the W3C from the ground up.
  • Incubation has been added to W3C Process in a way that is perceived by some as a true scandal. I am not opposed at all to Incubation, but W3C has shown a lack of caution, wisdom, consensus and obedience to its own Process that is flabbergasting. W3M acts fast when it need to remind a Member about the Process, but W3M itself seems to work around the Process all the time. The way Charters under review are modified during the Charter Review itself is the blatant example of that situation.

Given how far the candidacy statements are from what I think are the real and urgent issues of the W3C, I'm not even sure I am willing to vote... I will eventually cast a ballot, sure, but I stand by my opinion above: this is depressing.

I am now 50 years old, I have been contributing to W3C for, er, almost 22 years and that's why I will not run any more. We need younger people, we need different perspectives, we need different ways of doing, we need different futures. We need a Consortium of 2017, we still have a Consortium of 2000, we still have the people of 2000. If I was 20 today, born with the Web as a daily fact, how would I react looking at W3C? I think I would say « oh that old-school organization... » and that alone explains this whole article.

Conclusion for all W3C AB candidates: if you want my vote, you'll have to explain better, much better, where you stand in front of these issues. What do you propose, how do you suggest to implement it, what's your vision for W3C 2020. Thanks.

Thursday 6 April 2017

OS X Touchbar: your help needed

Still playing with OS X Touchbar, I am hitting a thick wall: the 10.2.1 Release Notes read:

NSTouchBar supports a text-related item identifier, NSTouchBarItemIdentifierCharacterPicker, and returns an NSPopoverTouchBarItem configured to show the system character picker from -itemForIdentifier:.

That Character Picker (that is more an Emoji Picker) is easily visible for instance with a Compose Window of Apple Mail:

Touchbar for Apple Mail's compose window

You can see there, from right to left, a scrubber with the most frequently used emojis, a label, and a popover button that allows access to the various categories of emojis and their contents. All in all, it's very well done.

But if I try to programmatically add a NSTouchBarItemIdentifierCharacterPicker to a touchbar that is not linked to a NSTextView or a NSTextField, I end up with a horked, partial, result. The popover button is correct but when you click on it...

Horked touchbar when created programatically

As you can see, there is only the list of favorites emojis (in fact the last used emojis), it does not scroll and its width/height seems wrong, the label is gone, and the emoji picker is completely gone... And whatever I do, I end up with the same result. Through lldb, I have dived into the touchbar: the CharacterPicker popover has the correct PopoverButtonItem and its associated popoverTouchBar only contains one element that has the NSTouchBarItemIdentifierCharacterPicker identifier.

Seen from here, there are only two possibilities:

  1. I am missing a parameter, an attribute, a whatever somewhere. That's not surprising given how superficial (to remain polite) the documentation is about this. The paragraph quoted above is the ONLY thing you can find about the CharacterPicker...
  2. there is a bug somewhere in Apple's code and Apple's own code works around it but it's totally impossible for me to find out what's going on here...

If you work at Apple or are a Touchbar expert and think you can help, please leave a comment here. This is true blocker to me and all the various approaches I tried to create the touchbar (manually created, dynamic, creating items, using only identifiers) lead to exactly the same horked result above. Thanks!

Addendum: OS X 10.12.4, Xcode 8.3 (8E162).

Tuesday 4 April 2017

XUL-based OS X TouchBar #2

Done. I have added XUL-based support for OS X Touchbar to Postbox and that will certainly ship soon. It's then probably the first Gecko-based application with OS X Touchbar support... All in all, it was quite easy. I only regretted some very strange or sometimes inconsistent design choices on Apple's side. But let's get back to the results... In the code, we have for instance:

code in Postbox's main window

And the result is:

Postbox's main window and touchbar

All in all, quite cool, simple to understand, manipulate, and even extend (on both the XUL and Cocoa side). Was fun to implement :-)

Friday 10 March 2017

OS X TouchBar

Currently adding OS X TouchBar support to XUL :-) So far so good. Should be trivial to add multiple touchbars to a given XUL window when it's done.

Monday 27 February 2017

From Swift2 to Swift 3

I am migrating a rough ~9000 lines of Swift 2 code to Swift 3. So really a small thing. And this is a mess of epic magnitude; the time needed to do that is not counted in hours but in days. Even if Swift is beyond 1.0, nothing seems stabilized. Some naming choices are totally ridiculous, unintuitive, painful to remember. Worse, they sometimes drastically change between two versions of Swift.

The whole naming thing of parameters is totally crazy. Let's take the example of some removeAtIndex() in Obj-C. The prototype for that in Swift 3 would be remove(at: index). That's über-cool when you read the prototype. But in your code, you have very little chance to have your parameter named 'index'. For instance remove(at: currentEntryRef). And bam, you've lost the connection to the Obj-C function. Most of my own functions end up with a leading underscore in front of each parameter...

Suppose you have 65 and you want "A". You need to convert your 65 into a UnicodeScalar. Until then, acceptable. Then from your UnicodeScalar to a String. But String(UnicodeScalar(65)) won't work, you need String(describing: UnicodeScalar(65)) but hey, that's an Optional("A") so you really need String(describing: UnicodeScalar(65)!)... Urgh. Oh and in Swift 2, it was String(UnicodeScalar(65)) and that's all. I miss JS's String.fromCharCode() so much. I miss JS so much.

Interestingly, the mobile team of Mozilla explained what it took to migrate Firefox for iOS from Swift2 to Swift 3. And we're now counting **in weeks**. This is clearly awful, Swift is not stable enough. While it should be very simple for a JS author to move from JS to Swift, it's not the case any more. It's also far too expensive to move from one version of Swift to the next one.

Instead of adding super-useful stuff like throwing computed properties (that are really, really useful to implement W3C DOM/CSS OM interfaces), Apple changed things that implied hours and hours of code tweaking just to build again even the first file of my repo in Swift3... Woooof.

I find this so depressing. Awful.

Monday 6 February 2017

Dual View in BlueGriffon

Long, long ago, one of the dreams of the manager of the Editor's Team at Netscape, Beth Epperson aka beppe, was a dual Source+Wysiwyg view, with Source and Wysiwyg kept in sync. And to do that, a few on the team (beppe, cmanskey and myself) were hoping to use the following:

  • in full theory, the CSS Object Model was made to allow different Views on each document. That's the reason why we have a getDefaultView() when we query a computed style... Unfortunately, rendering engines never really allowed that.
  • we hoped to use that mechanism to create a Stylesheet that would precisely and exactly render the source of a document. We missed a few things, of course: a value for the content property serializing the start tag of an element with all its attributes, another one for the end tag, possibly a property to control entity output and we had of course a problem with all the stuff a CSS rule cannot select (comments, PIs, prolog, cdata sections)

It never worked that way, unfortunately. We tried and had to declare failure. We also briefly tried another approach, classic, of keeping in sync a real source view and a real Wysiwyg view. Unfortunately, Gecko was rather slow on slow computers at that time and the performance hit was too high. But modern engines with super-fast JS and much better CPUs changed all of that.

I'm then glad to report a Gecko-based Wysiwyg editor finally has a sync'd Dual View: BlueGriffon. It will ship with forthcoming version 2.3.

Dual View

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.

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

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.

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 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.

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);

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...

Tuesday 14 June 2016

Synology meets Sony Vaio in my Hall of Worst

All in all, I am quite satisfied of all the hardware I bought across all these years. Computers, disks, memory, etc. All that geekery is reasonably good and the epic failures are rare. And even when an epic failure happens, the manufacturer is usually smart enough to issue a recall and free replacement even if the 2 years period after purchase is over. (e.g. Apple with the graphics card failure that hit so many older MBPs a while ago). In two occasions only, the manufacturer did show a pretty bad behaviour:

  1. the first case was years ago, when my Sony Vaio laptop was hit by the infamous "inverted trackpad" bug. In short, Sony avoided a 3 cents' expense isolating the trackpad electrical system from the metal case of its Vaio line and the trackpad was inverting the x axis, sometimes the y axis, sometimes both... Totally unusable of course. Millions of Sony laptops were hit by the issue. I had to shout on the phone to obtain, a few months after purchase of the most expensive Vaio at that time, a replacement of my computer. Cured me from Sony computers forever.

  2. and the most recent case, happening right now, is my Synology DS412+ NAS server. In short, it's been plagued by a zillion of issues, all severe since let's say day 50. But every time I was ready to send back the NAS to Synology, the support was asking me to try something (or giving that hint on their fora) that led to a normal reboot of the unit despite of motherboard warnings. On reboot, the warnings were going away... A few days ago, my DS412+ stopped working, with a forever-blinking blue led light. Motherboard failure, again and again and again.
    The Web is full of people explaining how bad the DS*12 series is, and the reports of motherboard failures are absolutely everywhere. They even issued a press release but never contacted customers, eh.
    Unlike Apple, Synology refused today to change my motherboard. And it took a week, and tweets added to my email, to eventually obtain that response from them. To someone else, they proposed to buy a new motherboard for $395, so 80% of the unit's price (yes, expensive!). They can rot in hell, of course.
    So Synology, it's a crappy support for buggy motherboards sold for an extremely high price. If you're lucky with your motherboard, you will never see a problem. If like me you bought a buggy unit shipped buggy, Synology will refuse responsibility after the end of the guarantee period. And during it, you'll need to ship the unit at your own expense.
    Synology's DSM is cool, their units are cool. But they're not reliable enough and the way Synology considers customers who paid a premium price is just a total shame and not in line with 2016 industry's standards, and most probably the French law here.
    Conclusion: avoid Synology as much as you can. You've been warned.

Wednesday 1 June 2016

BlueGriffon 2.0 released

I am happy to announce that BlueGriffon 2.0 is now available from http://www.bluegriffon.org

Screenshot of BlueGriffon 2.0

Sunday 22 May 2016

CSS Variables in BlueGriffon

I guess the title says it all :-) Click on the thumbnail to enlarge it.

CSS Variables in BlueGriffon

Thursday 12 May 2016

BlueGriffon 2.0 approaching...

BlueGriffon 2.0 is approaching, a major revamp of my cross-platform Wysiwyg Gecko-based editor. You can find previews here for OSX, Windows and Ubuntu 16.04 (64 bits).

BlueGriffon 2.0


  • it's HIGHLY recommended to NOT overwrite your existing 1.7 or 1.8 version ; install it for instance in /tmp instead of /Applications
  • it's VERY HIGHLY recommended to start it creating a dedicated profile
    • open BlueGriffon.app --args -profilemanager (on OSX)
    • bluegriffon.exe -profilemanager (on Windows)
  • add-ons will NOT work with it, don't even try to install them in your test profile
  • it's a work in progress, expect bugs, issues and more


- major revamp, you won't even recognize the app :-)
- based on a very recent version of Gecko, that was a HUGE work.
- no more floating panels, too hacky and expensive to maintain
- rendering engine support added for Blink, Servo, Vivliostyle and
- tons of debugging in *all* areas of the app
- BlueGriffon now uses the native colorpicker on OSX. Yay!!!
The native colorpicker of Windows is so weak and ugly we just can't
use it (it can't even deal with opacity...) and decided to stick
to our own implementation. On Linux, the situation is more
complicated, the colorpicker is not as ugly as the Windows' one,
but it's unfortunately too weak compared to what our own offers.
- more CSS properties handled
- helper link from each CSS property in the UI to MDN
- better templates handling
- auto-reload of html documents if modified outside of BlueGriffon
- better Markdown support
- zoom in Source View
- tech changes for future improvements: support for :active and
other dynamic pseudo-classes, support for ::before and ::after
pseudo-elements in CSS Properties; rely on Gecko's CSS lexer
instead of our own. We're also working on cool new features on
the CSS side like CSS Variables and even much cooler than that :-)

- page 1 of 121