"So Twitter just joined W3C. Should we cut our specs into modules < 140 chars?"
- 9-11 may-2012, CSS WG meeting, Hamburg, Germany
- 29 oct-2 nov 2012, W3C Technical Plenary Meeting, Lyon, France
Thursday 23 August 2012
By glazou on Thursday 23 August 2012, 17:12
"So Twitter just joined W3C. Should we cut our specs into modules < 140 chars?"
Tuesday 21 August 2012
By glazou on Tuesday 21 August 2012, 15:17
EPUB3 is based on the xml serialization of HTML5. When I say HTML5, I really mean the W3C version. But there is a problem ; that also happens with many other specs normatively referenced by EPUB3 but let's focus on HTML5 right now: the link to the HTML5 normative reference has for href
http://www.w3.org/TR/html5/ . In other terms, the last version (WD, LCWD, CR, PR, REC) published by W3C.
What's the version to consider for the implementation of an EPUB3 reader or editor? I have no idea. What has changed between the time the HTML5 WD was normatively referenced and now? I have no idea. What if for instance an "at-risk" feature is dropped in a future WD of the spec? I have no idea.
This is not only a theoretical issue, it has a deep and immediate practical impact: validation of the Content Documents inside an EPUB3 ebook is impossible. More globally, full validation of an EPUB3 package is then impossible.
By glazou on Tuesday 21 August 2012, 15:02
Hum, yet another bug in an EPUB3 spec... Excerpt (verbatim, nothing added or removed) from section 18.104.22.168.3 of EPUB Content Documents 3.0:
prefixattribute definition is unchanged, but the attribute is defined to be in the namespace
http://www.idpf.org/2007/opswhen used in Content Documents.
Unchanged from what?!?
Friday 10 August 2012
By glazou on Friday 10 August 2012, 11:56
In the EPUB ebook world, there's one sentence I heard so many times from so various sources I did not even feel the need to verify it:
"Validation of EPUB is extremely important and we heavily rely on the EPUB Validator"
First thought: "excellent!". People need to distribute validated packages because they don't want to suffer big issues on the some of the many ebook readers on the market. Excellent.
Unfortunately, after a closer look, the situation seems to me a bit different from that idealistic (I could even say utopian) view... Let me explain (please note I have spent time carefully reading the epubcheck source code for instance):
*.epubEPUB3 file, you'll find a few dozens of them. And again, only the major ones, the ones a serious industrial validator must absolutely validate against.
signatures.xmlwill involve much more than just a RNG-based validation of the XML instance... Validation of external property vocabularies can be extremely tricky or painful/expensive to implement.
epub30-ocfspec has a few very technical requirements there. I sincerely doubt all of them are validated, I sincerely doubt EPUB3 packages all around the world currently pass or will pass all the conformance requirements there.
EPUB3 is probably too complex as a spec. In EPUB2, most people did not understand the difference between spine, ncx and guide. Most common question was "why do we have multiple table of contents and which one is the good one?". In EPUB3, it's a bit better but only a bit. We have landmarks, multiple table of contents and still a spine. Personally I still wonder why there is a manifest of files; probably only because of the MIME types. Hey, even OSes rely on file extensions to infer a MIME type!!!
I'd love to see appear an EPUB4 strictly xhtml5/svg/mathml-based. No other XML namespace allowed. No more OCF, OPF, NCX. Manifest of files coming from the ZIP list of entries. Direct inclusion of non-conflicting property vocabularies. No need to have an OCF, we can have a nice
index.xhtml. Rely on a vocabulary of classes/IDs/roles (not the ARIA role...) expressing extra constraints/behaviours on existing html5 elements. Would be enough for most ebook authors and publishers and would drastically decrease the complexity of the publishing chain, IMHO.
Wednesday 8 August 2012
By glazou on Wednesday 8 August 2012, 15:24
Dates and time... Dates and time are painful, dates and time are complex, "dates and time are the most complex objects we use on a daily basis" used to say Reuters' Misha Wolf in the HTML WG in the good ol'days.
Excerpt from section 2.2.7 of OPF 2.01:
dateelement has one optional OPF
eventattribute. The set of values for
eventare not defined by this specification; possible values may include:
Excerpt from section 3.4.6 of EPUB Publications 3.0:
dateelement must only be used to define the publication date of the EPUB Publication.
dateelement is allowed.
Ahem... So EPUB3 allows only two dates for a package: the publication date and the last-modification date (through a
<meta property="dcterms:modified"> element). It's impossible to preserve the date of creation or various modification dates. Is it only me or this change from EPUB2 to EPUB3 is weird?
Please note that to insert a publication date into an OPF document ready for distribution, you must modify it and rezip the whole package. So if an OPF document does have a
<dc:date> publication element, its content value must be equal to the last-modified date!!! In other terms, this is totally useless. Wow.
Tuesday 7 August 2012
By glazou on Tuesday 7 August 2012, 17:59
Excerpt from section 4.2.4 from EPUB Publications 3.0:
<package … prefix="foaf: http://xmlns.com/foaf/spec/ dbp: http://dbpedia.org/ontology/"> … </package>
Excerpt from an unnumbered (sic) section of EPUB3 Fixed Layout Documents:
Implementors should note that future revisions of [Publications30] may establish the vocabulary represented by the URI
http://www.idpf.org/vocab/rendition/#as a reserved vocabulary. In this case, the result will be that a) explicit mapping declaration using the prefix attribute will no longer be applicable, and b) the prefix ‘
rendition’ will be reserved for this vocabulary. Future revisions of [Publications30] may also integrate the properties defined here into the Package Document default vocabulary. In this case the properties defined herein will be allowed to occur in Package Documents without a prefix.
In other terms, an attribute
prefix="foobar: http://www.idpf.org/vocab/rendition/#" is needed on the package element for the time being to be able to parse
<meta property="foobar:orientation">. But we're already warned that that
foobar may become
rendition w/o the need to declare the corresponding prefix on the
package element. And well, even
rendition could be itself dropped in the future. So in the long run, it will probably be
<meta property="orientation"> w/o property prefix or prefix declaration.
<troll>I think it is not complex enough. Prefixes should be declared by extra
meta elements themselves using a prefixed property, just to be able to have a few circular references...</troll>
Hey guys, why don't you finish shaking the shaker and get rid of the
rendition prefix for good right now? Just for the record, I have in front of me here two EPUB3 documents, the first one uses the
rendition property prefix without prefix declaration, the second uses the
rendering property prefix instead of
rendition but since the URI is ok, this is valid. In other terms, it's a mess already... I'm sure many epub3 Readers will look for
rendition and only
rendition, failing to correctly catch and resolve the prefix at all. Of course, the situation will get worse if the prefix becomes reserved or even integrated ! Pfff....
Monday 6 August 2012
By glazou on Monday 6 August 2012, 17:47
Clearly, Wysiwyg-editability was, as too often in W3C specs, the last concern on EPUB3 spec editors' mind... EPUB3 is not a W3C spec but an IDPF spec, but the result is the same, unfortunately. I have a concrete example here: in EPUB2, here's how an author is specified in the OPF metadata of the package:
<dc:creator opf:file-as="Murakami, Haruki" opf:role="aut">Haruki Murakami</dc:creator>
That is quite easy to map into a simple and efficient UI.
But in EPUB3, that's pretty different since the properties refining the
<dc:creator> element are expressed in standalone
<meta> elements using an ID/IREF reference mechanism:
<dc:creator id="mainauthor">Haruki Murakami</dc:creator> <meta refines="#mainauthor" property="role" scheme="marc:relators" id="role">aut</meta> <meta refines="#mainauthor" property="alternate-script" xml:lang="ja">村上 春樹</meta> <meta refines="#mainauthor" property="file-as">Murakami, Haruki</meta>
<meta refines="#mainauthor" property="display-seq">1</meta>
Please note the
alternate-script property that was not expressable at all in EPUB2. Please also note the
display-seq property that allows to specify an rendering order for the element (in the list of creators). These are cool features but...
mainauthor" here)... Asking a non-techie user to provide an ID is clearly suboptimal in terms of UX. That means the editing environment should pick one ID for the author, at the risk of using a human language not understood by the package's author or even a meaningless random ID.
alternate-scriptproperties and that is really, really tricky to offer in a simple and clean UI.
display-seqproperty is absolutely suboptimal: since
<dc:creator>elements can be refined by a role property, the display sequence should apply for all elements of the same localName having the same role and not only all elements of the same localName; having the display sequence's value in PCDATA instead of inside an attribute on the
<dc:creator>itself seems to me a design error. Even worse, the spec says in section 4.3.2 that "When the display-seq property is attached to some, but not all, of the members in a set, only the elements identified as having a sequence should be included in any rendering". Weird!
<dc:creator>found, you have to look for all
<meta>elements refining it. Please note the spec does not say what happens to a
<meta>element when the IRI in the
refinesattributes has no target (I think such element should be made invalid).
All in all, EPUB3 creator/contributor metadata are painful to deal with and edit, using ID/IDREF mechanisms in a specification (also) made for authoring environments while we have the full power of XML to avoid them seems to me a strategic error.
Don't get me wrong, I do understand why the
<meta> and its
refines attribute were introduced. But I think the cost to pay for that is too high.
alternate-scriptproperty. I think a monovalued
<dc:contributor>was probably enough.
rolewere perfect as attributes in EPUB2. Having the possibility to declare a
roleseems to me useless, most package authors will use marc roles anyway for compatibility reasons with EPUB2.
file-asmeta property is, compared to the
file-asattribute of EPUB2, useless bloat in terms of footprint, speed of access, editability and maintainability.
display-seqproperty seems to me far from meeting package authors' expectations. Its specification makes it painful to deal with since creators/contributors can become hidden if they have no display sequence while others have one. This property seems to me useless and the ordering of similar elements inside the
<metadata>element is most certainly enough. I even bet that this feature will be drastically underused.
<meta>element of EPUB3 is a suboptimal solution for problems touching only an extreme minority of package authors. The complexity it induces is, in my humble opinion, counter-productive and EPUB2 metadata were better designed and specified.
By glazou on Monday 6 August 2012, 15:24
Aaaaah, forward compatibility... Here are two interesting excerpts from the EPUB Publications 3.0 specification.
In section 3.4.14: Authors may include the
guideelement in the Package Document for EPUB 2 Reading System forwards compatibility purposes
In section 3.4.1: The (
version) attribute (of the
packageelement) must have the value
3.0to indicate compliance with this version of the specification.
Let's look now at two bits coming from the Open Packaging Format (OPF) 2.0.1 specification:
In section 1.4.12: the
versionattribute of the
packageelement is specified with a value of
In section 1.3.2: In addition, to be processed as an OPF 2.0 package, a
versionattribute with a value of
2.0must be specified on the
packageelement. A package element that omits the version attribute must be processed as an OEBPS 1.2 package
<package version="3.0"> is absolutely needed for an EPUB to be parsed as EPUB3 and EPUB2 absolutely requires
<package version="2.0"> since the absence of the
version attribute defaults to OEBPS 1.2!!! Conclusion, "EPUB 2 Reading System forwards compatibility" described in the first quote above is absolutely illusory. Even worse, compatibility can be achieved if and only if EPUB Reading Systems deliberately ignore the
version attribute on the
package element... Ooops, to say the least.
By glazou on Monday 6 August 2012, 15:04
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
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
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
<meta property="dcterms:source"> elements. Lovely...
Tuesday 19 June 2012
By glazou on Tuesday 19 June 2012, 10:09
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
By glazou on Monday 18 June 2012, 11:09
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
By glazou on Tuesday 10 April 2012, 23:12
If like me you spend a lot of time reading, reviewing, navigating into W3C specs, you have probably also spent a lot of time scrolling to find the table of contents of these documents. Again, again and again. So many times you're probably fed up with it, like I am. In that case, this add-on for Firefox is for you. Install it and browse your favorite W3C spec. When it's loaded, look for the small box in the top-left corner. Make your mouse pointer hover over it to open the floating table of contents. Click anywhere (including on a link) in the expanded box to shrink it back. Enjoy
Update: v1.1 is here. Next updates will be automatic.
Friday 10 February 2012
By glazou on Friday 10 February 2012, 10:57
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.
-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-bottom-left-radius -webkit-border-bottom-right-radius -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-radius -webkit-border-start -webkit-border-start-color -webkit-border-start-style -webkit-border-start-width -webkit-border-top-left-radius -webkit-border-top-right-radius -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-shadow -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-mask -webkit-mask-attachment -webkit-mask-box-image -webkit-mask-box-image-outset -webkit-mask-box-image-repeat -webkit-mask-box-image-slice -webkit-mask-box-image-source -webkit-mask-box-image-width -webkit-mask-clip -webkit-mask-composite -webkit-mask-image -webkit-mask-origin -webkit-mask-position -webkit-mask-position-x -webkit-mask-position-y -webkit-mask-repeat -webkit-mask-repeat-x -webkit-mask-repeat-y -webkit-mask-size -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-padding-after -webkit-padding-before -webkit-padding-end -webkit-padding-start -webkit-perspective -webkit-perspective-origin -webkit-perspective-origin-x -webkit-perspective-origin-y -webkit-print-color-adjust -webkit-region-break-after -webkit-region-break-before -webkit-region-break-inside -webkit-region-overflow -webkit-rtl-ordering -webkit-svg-shadow -webkit-tap-highlight-color -webkit-text-decorations-in-effect -webkit-text-emphasis-position -webkit-text-fill-color -webkit-text-security -webkit-text-size-adjust -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-padding -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.
-webkit-*prefix (or even implement the prefixed version in Moz) for
-webkit-text-size-adjustgiven 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
By glazou on Thursday 9 February 2012, 19:38
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:
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!