<Glazblog/>

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.

Tuesday 17 January 2017

E0

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

OCF

  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 3.5.2.1 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?

Packages

  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.

CONCLUSION

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.

Example:

<header id="metadata"
        vocab="http://www.idpf.org/2007/opf">
<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">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="content-type">
    <title>Moby-Dick</title>
  </head>
  <body>
    <header id="metadata"
            vocab="http://www.idpf.org/2007/opf">
      <ul>
        <li>Author:
          <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.

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.

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.

Tuesday 20 September 2016

W3C

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

Wednesday 30 March 2016

Something ridiculous in ES6

ES6 introduced a change in Gecko that remained under my radar for a looong time. Testing BlueGriffon 2.0 features, I discovered a feature that was completely borked and I was unable to explain it... Everything in my code looked fine. After some debugging, I nailed it into a codepen. Gecko and Chrome show the behaviour I dislike (window.bar is undefined if bar is a constant) while Safari does not.

I find this, mandatory per ES6 spec, completely ridiculous. It's not understandable from a JS author's perspective and apparently broke "a ton of stuff". This is clearly the kind of things where gurus and purists should have thought of users (JS authors) and did not.

Please TC39, change that. It's ugly and painful.

Wednesday 3 June 2015

In praise of Rick Boykin and its Bulldozer editor

Twenty years ago this year, Rick Boykin started a side project while working at NASA. That project, presented a few months later as a poster session at the 4th International Web Conference in Boston (look in section II. Infrastructure), was Bulldozer, one of the first Wysiwyg editors natively made for the Web. I still remember his Poster session at the conference as the most surprising and amazing short demo of the conference. His work on Bulldozer was a masterpiece and I sincerely regretted he stopped working on it, or so it seemed, when he left NASA the next year.

I thanked you twenty years ago, Rick, and let me thank you again today. Happy 20th birthday, Bulldozer. You paved the way and I remember you.

Friday 9 January 2015

No comment

HTTP headers
Screenshot by Robin Berjon following a message of mine

Monday 15 September 2014

Molly needs you, again!

There are bad mondays. This is a bad monday. And this is a bad monday because I just discovered two messages - among others - posted by our friend Molly Holzschlag (ANC is Absolute Neutrophil Count):

First message

Second message

If you care about our friend Molly and value all what she gave to Web Standards and CSS across all these years, please consider donating again to the fund some of her friends set up a while ago to support her health and daily life expenses. There are no little donations, there are only love messages. Send Molly a love message. Please.

Thank you.

Friday 20 June 2014

Leaving Samsung

This is my last day at Samsung. I am open to job opportunities. I'll continue co-chairing the CSS Working Group, but under my Disruptive Innovations' wings, starting immediately.

Thursday 20 March 2014

Samsung Web Tech Talk on JavaScript trends

SRA-SV LogoSamsung Research America will host a meetup about JavaScript trends in its San Jose R&D center on the 7th of april. This is a free event and anyone can attend.

Date: 07-apr-2014
Time: 5pm - 8pm
Location: 95 Plumeria Drive, San Jose, CA

Agenda:

  • 4:30pm - 5:00pm Welcome
  • 5:00pm - 5:30pm "Web Technologies on Mobile - Opportunities and Challenges", Andreas Gal, VP Mobile at Mozilla
  • 5:35pm - 6:00pm "Supersonic JavaScript", Ariya Hidayat, Shape Security
  • 6:20pm - 6:45pm "JavaScript in the Small", Satish Chandra, Samsung
  • 6:45pm - 8:00pm Open Discussion
  • 8:00pm - 9:00pm Networking

Feel free to attend using the link at the top of this article!

Thursday 6 February 2014

Next Game Frontier, The conference dedicated to Web Gaming

Last October, I was attending the famous Paris Web conference in Paris, France. In the main lobby of the venue, two Microsoftees (David Catuhe and David Rousset) were demo'ing a game based on their own framework Open Source babylon.js. Yes, Microsoftee and an Open Source JS framework over WebGL... I was looking at their booth, the people queuing to try the game and started explaining them there are conferences about Gaming, there are conferences about Web technologies in general and html5 in particular but there are no conference dedicated to Gaming based on Web technologies...

To my surprise, the two Davids reacted very positively to my proposal and we started immediately discussing a plan for such a conference.

Next Game Frontier LogoPeople, I am immensely happy to announce the First Edition of the Next Game Frontier conference, the conference dedicated to Web Gaming, co-organized this year by Microsoft and Samsung Electronics.

Web site: Next Game Frontier

Location: Microsoft France campus, Issy-les-moulineaux, France

Date: 13th of March 2014

Next Game Frontier on Lanyrd

Free registration but number of seats limited so register ASAP!

Schedule:

9:00 - 9:30 Breakfast

9:30 - 9:45 Opening Keynote (D. Glazman, D. Catuhe & D. Rousset)
9:45 - 10:45 Microsoft session - Create a 3D game with WebGL and Babylon.js (D. Catuhe & D. Rousset)

10:45 - 11:00 Break

11:00 - 12:00 Mozilla session - Le Web en tant que plateforme pour les jeux, de WebGL à AsmJS (T. Nitot)

12:00 - 13:15 Lunch

13:15 - 14:15 Create 3D assets for the mobile world & the Web, the point of view of a 3D designer (M. Rousseau)
14:15 - 15:15 Samsung session - Enhancing HTML5 gaming using WebCL (Samsung) & Turbulenz (Partner)

15:15 - 15:30 Break

15:30 - 16:30 Three.js (J. Etienne from http://learningthreejs.com)
16:30 - 17:30 Minko.io (Jean-Marc Le Roux from http://aerys.in)

17:30 - 18:30 Roundtable - Open discussions about Web Gaming - Microsoft, Mozilla, Samsung, Ubisoft moderated by a journalist

Save the date, and register now but please, don't register if you don't plan to come. Thanks!

Tuesday 24 September 2013

META Seal of Recognition

META Seal of RecognitionI am extremely happy and proud to let you know BlueGriffon received last thursday in Berlin, Germany, the « META Seal of Recognition » Award from the Multilingual Europe Technology Alliance for being the very first editor to implement the three main data categories of the W3C Internationalization Tag Set 2.0 (ITS 2.0) :-)

That implementation was done under a contract from DFKI and funding from the European Commission (project LT-Web), 7th Framework Programme (FP7), grant agreement n° 287815. The code is Open Source and will be available with forthcoming version 1.8 of BlueGriffon.

Here is the press release about it:

At the fourth annual META-FORUM conference in Berlin on September 19/20, it was announced that Disruptive Innovations was awarded the META Seal of Recognition for BlueGriffon. The META Seal of Recognition recognises excellence in software, products, and services which actively contribute to the European Multilingual Information Society. The META Technology Council, a panel of 30 experts drawn from the European Language Technology landscape, recognises the contribution BlueGriffon makes to the European Multilingual Information Society.

META, the Multilingual Europe Technology Alliance brings together researchers, commercial technology providers, private and corporate language technology users, language professionals and other information society stakeholders. META is preparing the necessary ambitious joint effort towards furthering language technologies as a means towards realising the vision of a Europe united as one single digital market and information space.

The META Seal of Recognition is awarded annually to select products and services which actively contribute to the initiative’s goals. This year is the third time the META Seal of Recognition has been awarded at a special ceremony as part of META-FORUM 2013 held in Berlin, Germany.

For more information see http://www.meta-net.eu/meta-seal

Wednesday 17 July 2013

Internationalization Tag Set (ITS) 2.0 in BlueGriffon

I have been contracted by german company DFKI under a European contract to implement a part of the Internationalization Tag Set (ITS) 2.0 specification into BlueGriffon and I now have a first runnable prototype. So there is a new floating panel in BlueGriffon:

Local ITS state Global ITS rules

Features:

  • The "Locally" tab shows the ITS state of the container element of the selection. The ITS state is computed from the local ITS attributes, the global ITS rules applying to the element and potentially the ITS state inherited from the ancestors of the element (the inheritance rules of ITS 2.0 are fully implemented). That tab of course allows to override that local state and apply local attributes.
  • Three data categories are implemented under the current contract: Translate, Localization Note and Terminology
  • The "Global" tab allows to create and manipulate global ITS rulesets attached to the document, either inline (through a <script type="application/its+xml"> element) or external (through a link element). The order of rulesets attached to the document can be modified. Parameters and ITS rules can be added to the rulesets or moved into the rulesets. During a creation of a ruleset, both XPath and CSS query languages are available. The rule creation/modification dialog has a magic button computing automatically an Xpath or CSS selector for the currently selected element. All global properties defined by the spec are editable with respect to the cardinality defined by the spec. For XPath, the code looks for an already defined HTML namespace in the ITS rules and adds one (that is reported to the user) if that namespace is not present.
  • Parameters are correctly expanded in XPath and CSS selectors during global rules' application.
  • All operations are undoable.
  • The code was architectured with extensibility in mind and it will be pretty easy to add new ITS 2.0 data categories in the future.

All the above will be available in forthcoming BlueGriffon 1.8 to all users for free, thanks to the European Commission!

Monday 10 June 2013

CSS Flexible Box is Best New Web Technology 2013!

I am extremely pleased to announce that a work done by the W3C CSS Working Group received last week a Net Award as Best New Web Technology 2013 from .net magazine for the CSS Flexible Box Layout Module. This is a bit of an achievement for the CSS Working Group itself, the authors/contributors/editors of the specification, and the W3C. Mucho congrats to all the members of the CSS Working Group and contributors to www-style, you guys rock!

Net Award Best New Web Technology 2013 for CSS Flexible Box Layout Module

Thursday 30 May 2013

Where is Daniel

Tuesday 5 March 2013

Five years..

Peter Linss and I were appointed co-chairs of the CSS Working Group exactly five years ago :-)

Tuesday 26 February 2013

EPUB NG

Following the W3C Workshop on electronic books in NYC two weeks ago, Dave Cramer (Hachette), Hadrien Gardeur (Feedbooks) and myself (Disruptive Innovations) have started a new Google Group called EPUB NG. Don't misunderstand us, it's called EPUB New Generation only because we needed a name and we start from what's available on the market right now, EPUB3. We're not forking, we're not doing a secret thing, we only needed a space where we could start discussions about the largest issues I found in current specs and what Dave recently called EPUB Zero.

So if you're interested in throwing ideas about a new, simpler, lighter format for electronic books more in line with W3C standards and Web habits, start reading us and ping one of us to request an invite. Please detail your affiliation and background in the electronic books' space? Thanks!

Wednesday 20 February 2013

20...

Twenty years ago, while working at Grif, I was ironing the very first implementation of CALS tables (that eventually gave us HTML tables) in a Wysiwyg editor. Time flies, and I'm still working on content editors :-)

Thursday 14 February 2013

Ahem...

I just read Daring Fireball's short so-called « analysis » of the Opera switch to WebKit. Even I perfectly know that guy is almost only an Apple PR guy, I'm again surprised by his limited ability to analyse a situation. The only question that is worth it is the following one: whatever is the strategic rationale that led to that choice, it's obvious Opera had the choice between open-sourcing Presto to build a larger community around it and ditching it in favor of an already open-sourced rendering engine. So why did they choose the latter?

And in terms of WebKit better than Presto, well, Opera has always been a better player with respect to standards than Apple. As many people have already said, a test failing in Presto was often the sign the test was wrong or the spec had a problem, given their extreme adherence to specifications.

So as usual, you can avoid reading Daring Fireball. No hyperlink from here. Nothing to see there.

- page 1 of 13