- 18 april 2015: Bulgaria Web Summit, Sofia, Bulgaria
- 5-7 may 2015: W3C Advisory Committee meeting, Paris, France
- 18-22 may 2015: CSS WG meeting, New York City, USA
Thursday 9 February 2012
By glazou on Thursday 9 February 2012, 09:39
Monday 30 January 2012
By glazou on Monday 30 January 2012, 18:05
Et y'aura pas de place pour tout le monde !!! L'inscription, c'est ici !
Friday 11 November 2011
By glazou on Friday 11 November 2011, 11:08
I am a bit sad. I'm a bit sad to see Flash is going away and Steve Jobs is not going to see it. Because that's his decision to have no Flash support in iOS that became the death knell for the Adobe technology. Flash became his weapon because:
So Flash will get security fixes on Android and RIM, will be stopped on all other mobile devices, and will continue to live on Desktop. As I told an interviewer last year in Sweden, HTML+CSS will eventually kill Flash but as a side-effect. By the way, it's ironical to read that at the same moment a rumor says Microsoft could stop Silverlight, its own -ms-Flash...
Speaking of Adobe, that's a big big change for them. They relied on proprietary tech they made ubiquitous, and they now have to rely on the browsers themselves. Since they can't implement themselves all the HTML, CSS and JS goodness they need to replace Flash, they will probably focus only on WebKit. And that's where it's interesting : since they have no impact on the other browsers, they cannot be sure all they need for Web Sites will be available in all browsers at a given time. They can only be sure - if they work themselves on WebKit - they can release a WebKit-based runtime for something like Adobe Air. Please note PDF.js is a threat of a similar magnitude to the Acrobat Reader plugin. So I think that Adobe will probably entirely leave the consumer-oriented plugin market at some point. Their acquisition of PhoneGap is another good indicator of that. They bet on WebKit as the biggest trend in the Web Browser market, thinking that other browsers will have to follow WebKit anyway if it implements new trendy stuff. Not a bad bet, in my humble opinion. That's also why we see a much more active participation of Adobe in the CSS Working Group for example.
Since WebKit is a lot in the hands of Apple, Adobe certainly asked itself the following question: "should we fork WebKit to be more in control?". I bet a box of cookies the answer was "no".
So my predictions, thinking out loud:
Saturday 5 November 2011
By glazou on Saturday 5 November 2011, 15:26
And all rejoiced because
<time> is back in HTML5... But one thing has to be said:
<time> is back not because it was a bad technical decision to remove it but because the HTML WG decision policy and process were not formally observed. In other terms, it's a loophole in the original action of removing
<time> that allowed it back. Good catch and well done Paul (sincerely), but everyone has to understand it does not say
<time> will be back forever.
More generally, I think (and I said it during TPAC) that too often basing HTML decisions on metrics or here "traction" is bad. When Unicode added some exotic charsets to the standard, some of them were proposed and supported by only one person, and no user of that writing script was in the consortium itself. Metrics ? Bah, the users of that writing script were not on the Web yet ! Traction ? One person. Let's discuss a11y too : just a fraction of web users need a11y features but these features are tremendously important to them. Among HTML spec developers, only a fraction really understand and propose a11y features, only a fraction of users need the features. Who said metrics, who said traction?
I have another example : the INS and DEL elements. They were introduced in HTML4 for visual modification marks. I was there, in the HTML WG. They can't cover all the cases Visual Modification Marks need, all editing environment authors know it. As a matter of fact, Microsoft Word is based on markup and CSS since the end of the 90's and AFAIK has never used INS and DEL because it's impossible. It uses attributes. So I proposed to make the current ins and del elements obsolete and switch to attributes. Rejected. Keeping a feature that does not work and will never work as intended is apparently better than making a better feature in the right way. Just so you know, this problem is now 20 years old. I clearly remember discussing Visual Modification Marks in markup-based editors with Jean Paoli and Vincent Quint in the first months of 1992 (yes, nineteen ninety two) and it was already clear that elements were not meeting the requirements. It was also discussed with Microsoft folks during the Web conference in Boston in 1995. The WHATWG/HTMLWG inability to deal with the accumulated experience in the marked-up world between 1986 (SGML release) and now is sometimes astonishing. Here, in the case of INS/DEL, metrics is zilch since nobody implements INS/DEL seriously. Traction? Right, implementors of Visual Modification Marks don't send feedback any more about that (I'm the only who still does it) because they have tried hard and dropped the case, relying on proprietary implementations. But now that WebApps offer more and more online cloud-based editing tools based on HTML, we need Visual Modification Marks in a standard way. It is highly time to have a workable solution here, and when I mean workable I don't mean INS and DEL.
For one reverted
<time> fiasco, how many unreverted ones below the radars or worse, above the radars (think longdesc)?
Monday 19 September 2011
By glazou on Monday 19 September 2011, 10:16
While we're (the Standards Community) now focusing on super-mega-hyper-useful stuff like an API to get the battery status (sic...), we're still unable to include in a web- or desktop app such widgets with a native look&feel. There are zillions of frameworks to ease the pain, but none of them is ready for desktop apps, and HTML+CSS+JS desktop apps need them to become mainstream AND cross-platform.I think then a new standardization effort between HTML and CSS is needed to make HTML UI appear. Let's look back at XUL and XAML a bit... Thoughts?
Thursday 1 September 2011
By glazou on Thursday 1 September 2011, 13:28
A W3C Multilingual Web workshop will be held in Limerick, Ireland, and co-located with the 16th LRC Conference and hosted by the University of Limerick. I'll give the KeyNote speech, titled "Babel 2012 on the Web", on the 21st of september. See you there!
Saturday 25 June 2011
By glazou on Saturday 25 June 2011, 12:26
I have said it multiple times here, in W3C mailing-lists or in public between 1998 and now but apparently it must be said again and again: the current HTML5 Last Call Working Draft - that does not reach at all the quality of other LCWD in the W3C and did not meet the basic requirements for a LCWD in the W3C Process - still has not worked on that erratum. So let me repeat it : html5
del elements suck and should be dropped in favor of a better solution.
delare, by definition, both inline-level and block-level elements. If in a Wysiwyg editor, you select the textual contents of a paragraph, turn on a "Visible Modification Marks" feature and hit the Delete or Backspace key, the editor has the option between
<p><del>...</del></p>. The user has no way to make a difference between the two but the two are NOT strictly equivalent. In the latter case, it is still theoritically possible to place the caret in the paragraph but BEFORE or AFTER the
delelement and insert new chars. In the former case, the whole paragraph is deleted and the user can't insert anything inside any more.
delelement, or at the beginning of the
delcannot cover one trivial case : since there is no equivalent to SGML inclusions (see for instance this link for a rather clean explanation) in XML, the following is impossible:
<ul><del><li>a</li></del><li>b</li></ul>. It is for instance totally impossible to mark an element as entirely deleted if the parent container's model does not allow the
The situation is unfortunately very clear: the
del elements as they exist now in the various html specs are unable to provide editing environments with a workable and predictable solution for Visible Modification Marks, the primary reason why the elements were originally introduced in HTML 4. As a matter of fact, almost no Wysiwyg editor implements them.
For the n-th time in 13 years, I strongly recommend to drop the
del elements in favor of the following attributes. All elements inside the
body element should be able to carry them.
changeattribute ; possible values:
deletedoptionnally followed by a whitespace and one of the keywords
review-byattribute ; an arbitrary value meaningful only when the
changeattribute contains the
to-be-reviewedvalue and meant to be displayed for human consumption ; can be for instance a name, a mail, a twitter id, etc.
reviewed-byattribute ; an arbitrary value meaningful only when the
changeattribute contains the
reviewedvalue and meant to be displayed for human consumption ; can be for instance a name, a mail, a twitter id, etc.
datetimeattributes as currently defined in the html5 spec
This is the minimum attributes set needed to resolve the issue. Another attribute "tagging" the potential reviews of the proposed change could also be added.
I really hope this change is going to happen. Again, the current
del html elements are totally hopeless.
Tuesday 21 June 2011
By glazou on Tuesday 21 June 2011, 05:36
@johnfoliot If browser vendors spent 1/10th the time trying to kill off #longdesc actually fixing the support, issue would be closed years ago
Tuesday 24 May 2011
By glazou on Tuesday 24 May 2011, 17:51
I am hesitating between hilarity and shock. IMHO, W3C's HTML WG died today. Again.
Saturday 19 February 2011
By glazou on Saturday 19 February 2011, 18:25
Our geek world is a world of trust. Just like in Antwerp at the Diamond Bourse, people belong only to two categories: trustable or not trustable. In Software, most of the people around us are trustable. Around me, almost everyone is trustable, almost everyone has always been trustable. It's so rare so find someone untrustable that it always hit me as a shock. I still remember marca's words about the three challenges a company faces "hire, hire and hire". A corollary of the hiring process is trust. Hire only people you trust. Hire only people you can respect. Hire only people who can do better than you if they're not already doing better than you.
So yesterday, I had a shock. Three shocks to be more precise. That's a bad beginning for 2011, since nobody shocked me to that level in the five last years. Grrr.
PS: in fact, there are two other categories at the Diamond Bourse: those who can speak yiddish and the others.
Wednesday 19 January 2011
By glazou on Wednesday 19 January 2011, 10:38
I discovered yesterday the HTML 5 "logo" and I find it completely missing its target. Except the name, nothing in the logo's design is clearly related to the Web. Change "HTML" in that logo to "Interstate" and it could well be a road sign...
I already had a chance to give my opinion about the "HTML 5 is everything" current buzz during the last Technical Plenary Meeting of the W3C in Lyon. I find it counter-productive and in fact harmful. Oh, that's the only acronym journalists use to describe "the Open Web Platform"? Since when journalists DO things instead of WRITING ABOUT THEM?
Being the co-chairman of the CSS Working Group, I am also puzzled by the "CSS 3 / Styling" thingy that goes with the "HTML 5 logo". See by yourself:
Hum, to say the least! I just don't understand this beast. What the hell is it supposed to tell me? CSS, Presentation, Style, Fonts? Really?!?
Speaking only for myself here, who can seriously think I am going to use such a meaningless horror (see below) anywhere? Hmmm?
Tuesday 28 December 2010
By glazou on Tuesday 28 December 2010, 12:40
(this article uses SVG and MathML, Safari has issues with it because of HTML mimetype ; please prefer Chrome or Firefox)
Let's take a given square box. Height and width are the same. We want to apply a red-to-black background at let's say alpha degrees and through the center C (50%, 50%) of the box. The W3C gradients draft says we find the start and end points of the gradient that way:
Let's suppose the size of the box is 100%*100%. In that case, finding the coordinates of the end point (for instance) is easy:
Of course, Gecko-based gradients use a start point and an angle to define a linear gradient while WebKit-based gradients use a start point and an end point.
But according to the above, we will get different absolute coordinates for our start and end points depending on the box's size even if the angle remains the same.
The above means that it's not possible, in the general case, to derive a -webkit-gradient(linear, ...) from a -moz-linear-gradient(...) - and vice-versa - without having access to the element's size.
Conclusion: sorry, BlueGriffon will not output WebKit-based
gradients outside of the trivial cases, it's just not possible.
Sunday 31 October 2010
By glazou on Sunday 31 October 2010, 14:06
Attending W3C Technical Plenary Meeting in Lyon. Back at the end of the week. Don't forget the W3C Meetup in Lyon, 04-nov-2010 7pm.
Saturday 25 September 2010
By glazou on Saturday 25 September 2010, 16:35
(this message is posted with my CSS WG Co-chair hat on)
Yes, we need you. CSS 2.1 is a complex specification, and it has roughly 20,000 HTML4 and XHTML1 tests in its Test Suite. To make the document move from Candidate Recommendation to Proposed Recommendation, we need to show that each and every test in that Test Suite is passed by at least two different implementations. And that's where you can help :
if you have a few spare cycles and are able to test a few hundreds or thousands of the tests in the Test Suite with the (see below) of Opera, Firefox4beta, IE or WebKit, please help us focusing on the least tested tests or the ones that have only 0 or 1 passing implementation.
The results are agregated into a database. Thanks a lot for your help!
Builds to be tested (and only those ones please):
Wednesday 22 September 2010
By glazou on Wednesday 22 September 2010, 08:59
Chris Wilson leaves Microsoft for Google.
Tuesday 22 June 2010
By glazou on Tuesday 22 June 2010, 21:42
Je viens d'être interviewé par ZDnet.fr sur le W3C, HTML et tout ça. Je mettrai l'intégralité de l'interview en ligne sur ce blog après leur publication (qui n'est pas pour tout de suite apparemment).
Thursday 3 June 2010
By glazou on Thursday 3 June 2010, 15:06
Interview of Wolfgang Kriesing about Mobile Web Apps during SWDC 2010.
By glazou on Thursday 3 June 2010, 12:41
Interview of Chris Heilmann from Yahoo! at SWDC 2010.
By glazou on Thursday 3 June 2010, 10:03
Interview of Rik Arends about Ajax.org during SWDC 2010.
By glazou on Thursday 3 June 2010, 09:38
Interview of Dylan Schiemann about Dojo during SWDC 2010.