# <Glazblog/>

## Standards

Monday 6 August 2012

## EPUB3 fun #1

According to the section 3.4.6 of the EPUB Publications 3.0 spec, only one `<dc:source>` element is allowed in the OPF file for an EPUB3 package; it specifies a primary metadata expression. But according to section 3.4.7, it's also possible to use a `<meta>` element (in the `http://www.idpf.org/2007/opf` namespace, not the html one...) to specify a primary expression for the same source of the package. So

`<dc:source>urn:isbn:9780375704024</dc:source><dc:source>urn:isbn:9780375704025</dc:source>`

is not valid per spec but since nothing appears to be said in the spec about uniqueness of definition for primary expressions in the spec

`<dc:source>urn:isbn:9780375704024</dc:source><meta property="dcterms:source">urn:isbn:9780375704025</meta>`

is then perfectly valid... Of course, the behaviour of EPUB3 browsing or editing environments in that case is undefined

And guess what? I have in front of me right now a "EPUB3" book having both`<dc:source>` and `<meta property="dcterms:source">` elements. Lovely...

Tuesday 19 June 2012

## Printing a web page #2

So the issue I described yesterday does not seem to hit all platforms. But it's still painful to me on my Mac so, as usual, I spent a few minutes hacking a Firefox add-on. It adds a new menu item to the File menu to print "as on screen" and it does exactly what it says.

It's a 0.9 but I tested on a dozen of web sites having very specific` @media print` styles and it works as expected. Auto-update is not enabled yet, I'll enable it for 1.0. Enjoy!

Monday 18 June 2012

## Printing a web page

I hit a problem printing two well-known (in my personal environment) web pages this morning. I needed to print the W3C's FAQ and the home page of ERCIM, the european foot of the W3C. Because both have `@media print` stylesheets, you can see in the following screenshots a comparison between the screen rendering of the web pages and the corresponding print results:

Oops, I really needed the logo and a better presentation but the print stylesheet hides it (I checked the print option to have it printed)

Wow, that's a bit of a minimal print stylesheet

So I needed a print of the web pages "as on the screen". But the print dialog of my browsers (I tested Firefox, Safari and Chromium on my Mac) has no such option:

Yeah, yeah, I know, I can still make a screenshot of the pages, open them in my browser and ask the browser to print the screenshot. But if *I* can do it, that's overkill for the average non-geeky user. The web page could also have alternate print stylesheets but we hit a similar problem: there's no way to select them and such a UI would be certainly too complex to many users... A "Print as on screen" option is clearly missing here and I wish Microsoft, Apple and Linux distros could add it to their respective system print dialog browser vendors could add such a new menu entry living next to the existing "Print" menu item.

Tuesday 10 April 2012

Update: v1.1 is here. Next updates will be automatic.

Friday 10 February 2012

## Blaming CSS WG is too easy, Brendan

Brendan, I have the highest respect for you and you do know it. But I cannot let you affirm in public the current situation about prefixes was caused first by the CSS Working Group.

1. the CSS Working Group gathers you guys, browsers vendors. The Working Group decides nothing "by itself", it's an empty shell where browser vendors discuss, sometimes fight, and reach consensus. If a consensus was reached about introducing vendor prefixes in the past, the MEMBERSHIP of the Group is fully responsible for it and that DOES include Mozilla, or more probably Netscape at that time but eh we were all there at that time.
2. even the W3C Process is decided by the W3C Members. The CSS WG is totally out of scope here. It's like saying you blame an airport because you don't like showing an ID at the airport, the airport being bound by national and international regulations. Nothing it can do about it. Have someone at the W3C Advisory Board (you used to have Arun) or call for Process changes in a constructive way. But please, tell Mozilla reps to stop asking for Process changes in the CSS WG when the bits to change are NOT in our hands. That too sucks our time.
3. the CSS Working group kept drafts under its wings too often not because of pains caused by the W3C Process but because of the perfectionism of the WG Members. And they include Mozilla. People who criticize W3C say it lacks pragmatism, but trust me on that please, I too often said "perfectionism on CSS 2.1 sucks our time for CSS 3". CSS 2.1 took too many years to emerge also because you browser vendors wanted the most perfect spec and could never end the loop.
4. let's take CSS Variables, a top request by the whole CSS Community since 1997. Dave Hyatt and I had a complete, simple, nice, understandable, easily implementable proposal, Dave even implemented it in WebKit and shipped it. Finally removed it because other browser vendors ended up in endless discussions on the feature itself. The CSS WG is not guilty here. The browser vendors are. They argued and argued and argued ad nauseum, for something that could have hit browsers FOUR YEARS AGO and we still don't even have an alternative. Don't blame the CSS WG, blame your representatives to the CSS WG. Where is the lack of pragmatism and the lack of speed?
5. when the whole mobile Web is full of a feature implemented by WebKit, documented by Apple in two lines only on their developer's web site, protected by IPRs owned by Apple, never submitted by any browser vendor to the Working Group, and when Microsoft, Mozilla and Opera want to implement that super feature because lack of it harms their market share, don't blame the CSS WG. Fight the legal issue about IPR, implement a counter-measure legally feasible we could rapidly standardize or get Apple to submit their feature to the WG. But you just cannot tell the WG is guilty in any way here.
6. I have said dozens and dozens of times in the CSS WG that prefixes are a terrible burden on Web Authors' shoulders. It's only recently (relatively to the age of the WG) that we adopted a rule allowing us to get rid of prefixes when we think a feature is stable enough. But this rule comes, again, from CONSENSUS AMONG BROWSER VENDORS. The Working Group here is nothing more but a meeting room. Each time a new proposal to simplify (or get rid of) prefixes was submitted in the past, one browser vendor at least objected. So what should we do? Break consensus? On what basis? My chair's hat?!? Playing Heads or Tails? Even with the new rule, discussions about the stabilization of a given feature and removal of prefixes always lead to one browser vendor objecting to the proposal supported by the others. And it's not always the same browser vendor. How can you say here the WG is first guilty?
7. as far as I know, the list of prefixed (and even sometimes unprefixed while they should be prefixed!) properties implemented by WebKit is the following one:
```-epub-caption-side
-epub-hyphens
-epub-text-combine
-epub-text-emphasis
-epub-text-emphasis-color
-epub-text-emphasis-style
-epub-text-orientation
-epub-text-transform
-epub-word-break
-epub-writing-mode
-webkit-animation
-webkit-animation-delay
-webkit-animation-direction
-webkit-animation-duration
-webkit-animation-fill-mode
-webkit-animation-iteration-count
-webkit-animation-name
-webkit-animation-play-state
-webkit-animation-timing-function
-webkit-appearance
-webkit-aspect-ratio
-webkit-backface-visibility
-webkit-background-clip
-webkit-background-composite
-webkit-background-origin
-webkit-background-size
-webkit-border-after
-webkit-border-after-color
-webkit-border-after-style
-webkit-border-after-width
-webkit-border-before
-webkit-border-before-color
-webkit-border-before-style
-webkit-border-before-width
-webkit-border-end
-webkit-border-end-color
-webkit-border-end-style
-webkit-border-end-width
-webkit-border-fit
-webkit-border-horizontal-spacing
-webkit-border-image
-webkit-border-start
-webkit-border-start-color
-webkit-border-start-style
-webkit-border-start-width
-webkit-border-vertical-spacing
-webkit-box-align
-webkit-box-direction
-webkit-box-flex
-webkit-box-flex-group
-webkit-box-lines
-webkit-box-ordinal-group
-webkit-box-orient
-webkit-box-pack
-webkit-box-reflect
-webkit-box-sizing
-webkit-color-correction
-webkit-column-axis
-webkit-column-break-after
-webkit-column-break-before
-webkit-column-break-inside
-webkit-column-count
-webkit-column-gap
-webkit-column-rule
-webkit-column-rule-color
-webkit-column-rule-style
-webkit-column-rule-width
-webkit-column-span
-webkit-column-width
-webkit-columns
-webkit-dashboard-region
-webkit-filter
-webkit-flex-align
-webkit-flex-direction
-webkit-flex-flow
-webkit-flex-item-align
-webkit-flex-order
-webkit-flex-pack
-webkit-flex-wrap
-webkit-flow-from
-webkit-flow-into
-webkit-font-feature-settings
-webkit-font-kerning
-webkit-font-size-delta
-webkit-font-smoothing
-webkit-font-variant-ligatures
-webkit-grid-columns
-webkit-grid-rows
-webkit-highlight
-webkit-hyphenate-character
-webkit-hyphenate-limit-after
-webkit-hyphenate-limit-before
-webkit-hyphenate-limit-lines
-webkit-line-box-contain
-webkit-line-break
-webkit-line-clamp
-webkit-line-grid
-webkit-line-grid-snap
-webkit-locale
-webkit-logical-height
-webkit-logical-width
-webkit-margin-after
-webkit-margin-after-collapse
-webkit-margin-before
-webkit-margin-before-collapse
-webkit-margin-bottom-collapse
-webkit-margin-collapse
-webkit-margin-end
-webkit-margin-start
-webkit-margin-top-collapse
-webkit-marquee
-webkit-marquee-direction
-webkit-marquee-increment
-webkit-marquee-repetition
-webkit-marquee-speed
-webkit-marquee-style
-webkit-match-nearest-mail-blockquote-color
-webkit-max-logical-height
-webkit-max-logical-width
-webkit-min-logical-height
-webkit-min-logical-width
-webkit-nbsp-mode
-webkit-opacity
-webkit-perspective
-webkit-perspective-origin
-webkit-perspective-origin-x
-webkit-perspective-origin-y
-webkit-region-break-after
-webkit-region-break-before
-webkit-region-break-inside
-webkit-region-overflow
-webkit-rtl-ordering
-webkit-tap-highlight-color
-webkit-text-decorations-in-effect
-webkit-text-emphasis-position
-webkit-text-fill-color
-webkit-text-security
-webkit-text-stroke
-webkit-text-stroke-color
-webkit-text-stroke-width
-webkit-touch-callout
-webkit-transform
-webkit-transform-origin
-webkit-transform-origin-x
-webkit-transform-origin-y
-webkit-transform-origin-z
-webkit-transform-style
-webkit-transition
-webkit-transition-delay
-webkit-transition-duration
-webkit-transition-property
-webkit-transition-timing-function
-webkit-user-drag
-webkit-user-modify
-webkit-user-select
-webkit-wrap
-webkit-wrap-flow
-webkit-wrap-margin
-webkit-wrap-shape-inside
-webkit-wrap-shape-outside
-webkit-wrap-through
background-position-x
background-position-y
border-image-outset
border-image-repeat
border-image-slice
border-image-source
border-image-width
overflow-x
overflow-y
text-overflow
word-wrap
zoom
```

many of them being "documented" by Apple. Some are well known, come from a CSS WG spec/draft/document, and have their counterparts in Gecko, Presto and Trident. Some are totally unknown to us and were never submitted for standardization. So again, don't blame the CSS WG for prefixed properties that NEVER reached us. They are going to hit the market and spread because of a company, not because of a standards body. For the ones you implement and people don't use, well, Apple has nice editing tools, nice IDEs. I told you a loooong time ago that a browser is only the top of the ecosystem's iceberg and that editing is still a major part of it.

8. we already have an existing case with extremely ugly de facto standardization coming from WebKit mobile market dominance, and that's the infamous meta viewport tag. I heard myself some Apple engineers acknowledge it was a rather big mistake. We have CSS equivalents for this on our radar, submitted by Opera. We could have moved towards a de jure solution faster here but apparently there is little interest shown by browser vendors if you except of course Opera. Blame again the CSS WG for that? Not you, Brendan, please. You know too well standardization for that.
9. all of that said, please tell me how you are going to get rid of the `-webkit-*` prefix (or even implement the prefixed version in Moz) for `-webkit-text-size-adjust` given the IPRs?

It is too easy to always beat the CSS WG or the W3C. If you recall correctly, I have been one of the first ones to shout at the W3C in the XHTML2 fiasco. It was so early that Netscape still existed. I am still the first one to say it when they mess things up. But here, that's just unfair. I only agree that the CSS Working Group could have done better but hey, the Working Group members - hear YOU BROWSER VENDORS - decided there. So putting that organization at the top of your recriminations just carries a false message and hides an inconvenient truth.

Mozilla and Opera gave hand to Apple to create the WHAT-WG. You guys can speak together, for instance when your high-level representatives had a private secret meeting at Apple while the CSS WG was by pure coincidence in the meeting room on the other side of the corridor, was it november 2010. Meet again and let Apple know it must submit to the corresponding WGs technical proposals for the features that hit the Web and spread too wide to remain proprietary. Apple too must preserve the Open Web. So it says for HTML and APIs, so why not for CSS?

Thursday 9 February 2012

## Some clarifications

My recent article triggered a massive response on twitter and in the Web Authors' community, and that's exactly what I think was needed. Let me clarify a few things:

• Some say it won't be enough. That's entirely possible. Read it again: that's entirely possible. But at least I tried. And I did it because someone had to do it. I am accepting the fact some browser vendors could call me a painful asshole if it could help the Open Web. I'm not here to secure the market share of browser vendors. But I do care for the Architecture of the Web, its maintainability over time and even more for its coherence. I find non-WebKit-based browsers adopting -webkit-* properties a nightmare, and I will fight that as much as I can. Only then, if everything else fails, I'll accept to consider the last resort and terrible solution proposed by Microsoft, Mozilla and Opera.
• I think Microsoft, Mozilla and Opera have, like Microsoft did in the past, underestimated the negative PR impact or decided to live with it. That's where you can help. Show them they can't live with it. Force them to find another solution.
• Yes, I know that browser vendors have tried evangelizing web sites. Well... Opera has a large evangelization team dedicated to mobile. Mozilla has only a little one and not sure it's dedicated to mobile in any way. I have no idea for MS but they certainly have one. Now, all that evangelization happened far from public's eye. My goal with my article was to put it back under public scrutiny and request public's help to reach a stronger impact. That's why I wrote that your voice does matter. And it really does.
• Some say it's because of W3C's Process that slows things down. No it's not. When a browser vendor has Intellectual Property Rights on a feature, when that browser vendor does not submit a technical proposal for that feature to W3C and when that feature hits the whole Web, there's nothing the W3C - or even other browser vendors - can do without facing legal action on one hand, potential incompatibilities with the protected feature on the other. Blame that browser vendor, not W3C or its Process.
• Some say forget about the problem and use frameworks on the server-side. Oh come on. That's curing a severe wound with a plaster and Tylenol... And that's not always possible.

## CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*

The CSS Working Group, the W3C, the browser vendors and the Open Web need you, and I really mean you ALL. The following article is written by Daniel Glazman, co-chairman of the CSS Working Group; the part until "This must not happen" represents an official discussion of the CSS Working Group. Members of the Group behind that discussion include Adobe, Apple, Disruptive Innovations, Google, HP, Microsoft, Mozilla, Opera and the World Wide Web Consortium (W3C). The second part of the article is strictly mine.

Not so long ago, IE6 was the over-dominant browser on the Web. Technically, the Web was full of works-only-in-IE6 web sites and the other browsers, the users were crying. IE6 is dead, this time is gone, and all browsers vendors including Microsoft itself rejoice. Gone? Not entirely... IE6 is gone, the problem is back.

WebKit, the rendering engine at the heart of Safari and Chrome, living in iPhones, iPads and Android devices, is now the over-dominant browser on the mobile Web and technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying. Many sites are sniffing the browser's User-Agent string and filtering out non-WebKit browsers. As in the past with IE6, it's not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only "experimental" CSS properties prefixed with `-webkit-*` and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers...

In many if not most cases, the `-webkit-*` properties WebKit-specific web sites are using do have `-moz-*`, `-ms-*`, `-o-*` equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.

Without your help, without a strong reaction, this can lead to one thing only and we're dangerously not far from there: other browsers will start supporting/implementing themselves the `-webkit-*` prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That's not a question of if, that's a question of when.

Let me be very clear: this is NOT hypothetical and I'm not discussing here something that could happen. All browser vendors let us officially know it WILL happen, and rather sooner than later because they have, I quote,  "no other option". Let me also state very clearly that is NOT a lack of innovation on these browser vendors' side, in particular when they DO support a feature but with their own prefix, following here the Working Group's rules.

## THIS MUST NOT HAPPEN.

This situation happened in the past with IE6, when browsers were desktop-only, and it took ten long years to recover. With billions of mobile browsers today, the Web may not recover at all.

Vendor prefixes have not failed. They are a bit suboptimal but they also very clearly preserved Web Authors from chaos. We can certainly make vendor prefixes work better but we can only do that if vendor prefixes remain VENDOR prefixes.

I am asking all the Web Authors community to stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.

I am asking all the Web Authors community to remove immediately and stop implementing WebKit-based browser sniffing in web sites. You own such a web site? Show your support for the Open Web and remove that browser sniffing immediately after you finish reading this call for action.

I am asking the Web Design and Web Users community to stop recommending web sites that require one single browser while they could be open to multiple ones. Don't link them, mention them only to let the community know they fail serving the Open Web. Don't feed the trolls; blacklist them, whatever is the coolness of the service they provide.

I am asking the Web Authors community to update their online services to support the other browsers if these other browsers offer a level of CSS support they did not offer in the past. Do that NOW! Very little effort, big effect.

I am asking the whole Web community, all Users, to ping Web Authors and complain if their web sites work only for one rendering engine while it could work for many. Help us evangelize these Web sites to make sure the Architecture of the Web remains safe for all, remains based on consensual and open Web Standards, because browser vendors implementing the prefix(es) of other browser vendor(s) can only lead to a chaos of the IE6 magnitude. We did it in the past for works-only-in-IE6 web sites and we did it well, now is the time to do it again for works-only-in-WebKit web sites.

I am also asking the browser vendors behind WebKit, namely Apple and Google, to submit as soon as possible to the CSS Working Group complete technical proposals for the proprietary CSS-like properties they have let the whole world use in iOS and Android devices, harming the Open Web. An example of such a property is `-webkit-text-size-adjust`. Please note the Apple representative to the CSS WG said he'll look at the possibility to have proposals submitted for a list of such properties. If these properties are so well implemented and so useful to the mobile Web, they became de facto standards ; let's turn them as soon as possible into de jure standards through W3C standardization. I am also calling Apple and Google to remove support for the "experimental" versions of a property when the final one is implemented and shipped. We, and that we represents the whole Web Industry, cannot let the architecture of the Web become unsafe and unreliable keeping forever vendor prefixes that should be gone. That is harmful and this is your responsibility, because you could provide mandatory software updates to your users. The Open Web does not have to suffer of such a decision.

So please all express your opinion, help the Open Web and tweet or blog that you don't want to see this happen. Some of you already started, after reading the minutes of the CSS Working Group face-to-face meeting in Paris. Let Microsoft, Mozilla and Opera know this is the wrong way to go even if we understand perfectly both the diagnosis and their proposed solution. If browser vendors standardize the Web, it's really owned by Users and Authors and now is the time to let browser vendors remember it better. YOUR VOICE DOES MATTER.

Jeffrey, Eric, Molly, Lea and all our friends of the Web Designers' community and/or Web Standards' community: please help us. Now.

If you're a journalist, I'm immediately open to interviews on this topic (please note I'm based in Europe).

Thank you.

Monday 30 January 2012

## Le CSS WG à La Cantine le 8 février

Et y'aura pas de place pour tout le monde !!! L'inscription, c'est ici !

Friday 11 November 2011

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:

• Apple does not like third-party technologies that become a gordian knot,
• it's a question of good taste and I suppose Jobs has (almost) always considered Flash as bad taste.

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:

• death of Flash and Silverlight, all platforms, as soon as possible.
• death of Acrobat Reader as a plugin, all platforms, as soon as possible. Adobe should even help PDF.js.
• stronger and stronger involvement of Adobe in WebKit ; following the acquisition in Bucharest, more hiring of SW engineers with good knowledge of the guts of WebKit.
• Adobe Air will eventually drop Flash entirely and switch to Web Standards. Or Air as we know it will go away and PhoneGap will be the new Air.
• Dreamweaver's future is probably a strong subject of discussion internally at Adobe. It has grown in circles, is hardly maintainable any more, focuses a lot on Flash-in-the-Web-page and is probably not adapted to what Adobe is currently creating.

Saturday 5 November 2011

## The <time> fiasco

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

## HTML UI

I had an interesting online chat with a friend in the US this morning (well, this night for him...). The topic was HTML and the recent Microsoft announcements. While we see HTML reach a next level with desktop apps, the lingua franca of the web is still far, really far away from having all what's needed for desktop apps or even web-based desktop-alike apps. If form controls improved a lot between html4 and html5, a wide range of UI elements are still out of reach. Well. Let me explain before shouting : they are codable but each and every site has to reinvent the wheel with lots of UI theming and JavaScript-based controls. That's bad because that's incoherent and expensive. HTML+CSS still lacks major, really major stuff like:

• tabboxes
• pop-ins and more powerful tooltips
• trees (and when I mean trees, I mean tree-like widgets like the XUL <tree> able to render tens of thousands of lines w/o making the user experience awful)
• better integration with the OS/WindowManager
• etc.

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

## W3C Workshop Program: A Local Focus for the Multilingual Web

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

## Why html5 elements INS and DEL suck

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 `ins` and `del` elements suck and should be dropped in favor of a better solution.

• `ins` and `del` are, 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 `<del><p>....</p></del>` and `<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 `del` element and insert new chars. In the former case, the whole paragraph is deleted and the user can't insert anything inside any more.
• In the latter case just above, it's impossible for the user to know if a caret placed at the beginning of the paragraph is before the paragraph, inside the paragraph but before the `del` element, or at the beginning of the `del` element.
• much more importantly, `ins` and `del` cannot 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 `del` element...

The situation is unfortunately very clear: the `ins` and `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 `ins` and `del` elements in favor of the following attributes. All elements inside the `body` element should be able to carry them.

• `change` attribute ; possible values: `inserted`, `deleted` optionnally followed by a whitespace and one of the keywords `reviewed` or `to-be-reviewed`.
• `review-by` attribute ; an arbitrary value meaningful only when the `change` attribute contains the `to-be-reviewed` value and meant to be displayed for human consumption ; can be for instance a name, a mail, a twitter id, etc.
• `reviewed-by` attribute ; an arbitrary value meaningful only when the `change` attribute contains the `reviewed` value and meant to be displayed for human consumption ; can be for instance a name, a mail, a twitter id, etc.
• the `cite` and `datetime` attributes 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 `ins` and `del` html elements are totally hopeless.

Tuesday 21 June 2011

## QOTD

@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

## HTML 5 LCWD

I am hesitating between hilarity and shock. IMHO, W3C's HTML WG died today. Again.

Saturday 19 February 2011

## A world of trust

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

## The HTML... hum... logo

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

## The current CSS Gradients mess...

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

• α is our user-chosen angle
• let β be the angle between the horizontal and the line between the C and D; we have
$tan\beta =\frac{{C}_{y}-{D}_{y}}{{D}_{x}-{C}_{x}}$
• the distance between C and D is of course $l=\sqrt{{\left({c}_{y}-{d}_{y}\right)}^{2}+{\left({c}_{x}-{d}_{x}\right)}^{2}}$
• the distance between C and the end point is then $l\text{'}=l\cdot cos\left(\beta -\alpha \right)$
• and the coordinates of our end point are then $\left({C}_{x}+l\text{'}cos\left(\alpha \right),{C}_{y}-l\text{'}sin\left(\alpha \right)\right)$

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

## Where is Daniel

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

## the CSS Working Group needs you

(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 latest version (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):

- page 3 of 13 -