Mowser
Weblog on W3C, WHATWG, HTML, CSS, DOM, XML, HTTP and more.
After the W3C Technical Plenary I went back home for eight hours of solid sleep at which point I took a taxi straight back to Schiphol to make a flight to San Francisco. I did a few talks (HTML5 FTW!) for the first week of the Opera University Tours in the Northern California region. Has been a lot of fun discussing the Web with students around here.
I attended the WHATWG meetup as well and missed out on going to something at Google the next day due to being in downtown San Francisco with collegues instead of close to Google. We had some great food at a place close to the harbor. (Earlier that day I had a lemonade at a place called “Hot Dog on a Stick…â€) Will be checking out the food at Mozilla tomorrow. Going there for lunch after which I will probably take the train back to the airport to get on the 4:25PM flight back to Amsterdam.
I arrive in Amsterdam Saturday around 11AM and will meet up with Marcos later that day in Utrecht, probably around 2:30PM. The next day we will leave on a relatively early flight from Schiphol to Kilimanjaro, Tanzania. Awesomeness!
(When I get back from that I will be in the Netherlands for a few days at which point I will go to Germany for the second week of Opera University Tours in that country.)
Some impressions from the plenary day on W3C TPAC 2008 regarding HTML5:
At Standards Suck we are reporting on TPAC 2008 with interviews of various people. More to come.
(Tomorrow the HTML Working Group meeting will start. Michael Smith posted the final agenda. First meeting this week I am in that has an agenda upfront. Mike++)
What also was funny was that the Web was not about the browser except that lots of people here at TPAC wanted browsers to do things differently. E.g., implement XBL, provide some end user visible UI for errors in a site, et cetera. Not exactly consistent messaging.
The other day I bought a Denon AVR-1909. It is quite nice. It supports 7.1, 5.1 and has two independent channels on top of that if you prefer to listen to audio using a set of stereo speakers, for instance. I have a relatively simple 5.1 setup. (Speakers and subwoofer are from KEF, really nice.)
The bad thing about this receiver is the horrible user interface you need to use to control e.g. your iPod or simply the interface you need to use to configure everything. It is similar with television. Who is going to build daily use electronic equipment that features Wi-Fi and a simple HTTP API to control it?
The benefits are hopefully obvious. Easy data sharing with your laptop, data stored elsewhere in your network, a competitive market place to create user interfaces. Since it will become so easy to create these interfaces they could be customized depending on the type of user, et cetera. I would totally buy into it.
As far as Denon receivers go the network bit is coming along. My iPod docking station features a network capabilities, more expensive receivers feature Wi-Fi. But then the manual suggests I have to use Windows Media Player to make use of it. Also, in terms of files it only does music and photos. Please, open it up!
(Another thing I noticed is that I paid too much money. The dollar prices are a lot lower. Sigh.)
In March I wrote a post titled IE8: The Bad, since then a new beta of Internet Explorer has been released. It still seems a bit dubious whether they are actually committing to standards. This could be a communication issue or actually intended. It is mostly unclear to me.
XDomainRequest: Microsoft unfortunately continues with XDomainRequest rather than making changes to XMLHttpRequest as other browsers are doing and as is being standardized by the W3C Web Apps Working Group. (Disclaimer: I am the editor of XMLHttpRequest Level 2.)
Some agreement was made to at least support the same protocol on the server, namely using the Access-Control-Allow-Origin header as per Access Control for Cross-Site Requests. (Disclaimer: I am the editor of that draft too.) However, IE8 only supports * as value for that header, not an origin, e.g. http://annevankesteren.nl (test). Sunava pointed out that was because the W3C WebApps WG was still debating the matter. Here is hoping they will fix the bug as there is agreement on that syntax.
HTML5 DOM Storage: localStorage and sessionStorage are now supported. Enumerating through them does not give the results I was expecting (I got "length" and "remainingSpace" back as well, besides the keys) and they still have a remainingSpace member that is not part of HTML5. Given that anything that gives some indication of space is highly vendor specific as it depends on encoding, compression, and type of device, they should really rename it to msRemainingSpace or some such or simply drop it.
IE8 also supports an event named storagecommit that is not part of HTML5 which tells you when the data has been written to an XML backend format IE8 uses. The event object for used for the storage does not expose key, oldValue, and newValue. The url member is named uri and the source member is null rather than a reference to the Window object. Ouch!
ARIA: Aaron Leventhal recently blogged about how ARIA in IE8 is a pain. (Aaron works for IBM making Firefox and Web applications accessible and is a member of the W3C PF WG which standardizes ARIA.) In short, when IE8 renders in super standards mode ARIA will work as everywhere else, otherwise you have to use Microsoft proprietary syntax. So not only do you need to upgrade your application code to be keyboard accessible and ARIA-enabled, you will also need to upgrade it from quirks to standards mode. Alternatively, you could take the easy way out and lock out other browsers. Not nice.
I should note I only played around with Internet Explorer 8 for an hour so I only discovered the most trivial interoperability issues. More extended testing would undoubtedly reveal more and I hope (independent) Web developers will try to verify what they are told.
In retrospect not the best title, but my presentation, Ajax 2.0, went well. (Requires a rendering engine with support for the CSS projection media type and the HTML video element.) Hopefully the recorded audio together with a video of my screen will be made available soon.
In other news, Standards Suck is back with a post on Advanced CSS Layouts. We’re planning on covering the W3C Technical Plenary this year, which is effectively the Mecca of standards suckage.
The Ajax Experience is fun so far. I might actually have my slides ready twelve hours in advance, though I will probably do some last minute edits. Bruce Lawson suggested calling the talk Ajax 2.0, and I went with that, but unfortunately the printed conference guide suggests it is “Opera and Ajax.†Ouch. The talk will be about making Ajax-style applications accessible (WAI-ARIA), HTML5, XMLHttpRequest Level 2, Access Control for Cross-Site Requests, Web Workers, Web Forms 2.0, and maybe a quick demonstration of Opera Dragonfly. This may seem like a lot, but I talk quite quickly and have to go on for an hour so covering a lot of topics seemed like the best solution. (That is, I will probably be done in forty-five minutes so people can ask questions.)
So far the talk from Francisco Tolmasky from 280 North on Objective-J and Cappuccino was the one I enjoyed the most. He equalled browsers with graphic cards, Cappuccino with OpenGL, and envisioned a world where everyone can just write their own language and is not limited by differences between browsers, and especially not between all the different paradigms browsers offer (CSS, HTML, SVG, canvas, et cetera). Cappuccino also works. Definitely worth following.
Today I updated the cache policy for preflight requests in the Access Control for Cross-Site Requests specification. Eventually it turned out to be fairly simple, but wrapping my head around it and considering all the cases somehow always requires considerable effort. Authors will be glad to learn that this is all transparent to them. Implementors tell me it’s understandable, but then nobody evil (e.g. Ian or Simon) has tested their implementations yet.
The preflight result cache stores the result of a preflight request, which is transparent from the Web API point of view (e.g. XMLHttpRequest), but does require server deployment. Previously a cache entry stored the origin of the request (e.g. http://example.org, https://example.org, http://example.org:81, http://www.example.org are all different origins), the request URL, an expiry time, and the methods and headers allowed (as indicated by response headers). (And the value of the credentials flag, but it is already complicated enough. Hah!) This model was reasonably simple, but it did not really allow for adding new headers and methods over time, as those might have different expiry times. The change the new model made was having a single entry per allowed header or method avoiding that problem. Though everything else had to be updated to take that into account.
In the Web developer world all aforementioned details are not important. It is important that implementors get them right so your servers stay secure (if they are) and you have a reliable platform. All authors have to do to make resources available from other origins is using the Access-Control-Allow-Origin header. And for slightly more complicated scenarios (e.g., a request using the DELETE method coming from another origin) you need to reply to a preflight request which uses the OPTIONS method with a set of additional headers indicating what headers and methods (indeed, DELETE) you allow. Enlightened, yet?
So much for changing my insurance:
Helaas kunt u dit formulier niet op de juiste manier bekijken, omdat u gebruik maakt van een browser die niet wordt ondersteund. Onderstaande combinaties worden door Postbank ondersteund:
That a major Dutch bank recommends these outdated browsers is just utterly unacceptable. Rejecting Opera and Ubuntu is too for that matter.
I wonder if the 2022 debacle is in part due to terminology confusion. That is, the meaning of “W3C Recommendation†changed over time. (Arguably it varies per W3C Working Group too.) When CSS 1, CSS 2, and HTML 4 were created, W3C Recommendation meant that the responsible Working Group was done with their work and it was now up to implementors and authors to start adopting it. Around the start of development on CSS 2.1, W3C Recommendation was changed to mean a specification that has proven itself in the market place. One that is implemented to the letter by at least two implementations in identical fashion (interoperable), is used by authors, and is generally found useful. XML 1.0 is a good example of a W3C Recommendation with the more recent meaning. (Though even XML 1.0 is still tweaked based on experience gained with using, testing, and implementing it.)
What used to be known as W3C Recommendation (in the HTML 4 era) is something we now know as Last Call Working Draft or maybe Candidate Recommendation. Using the new terminology, Ian expects HTML5 to become a Last Call Working Draft in 2009 and W3C Recommendation in 2022. So it’s actually quite close given that the latter date is not that meaningful. On top of that, HTML5 features are already shipping in various browsers today.
(The W3C HTML WG charter suggests end 2010 as W3C Recommendation date, though some deadlines are already missed.)
I just found out that all the HTML5 Twitter commotion was because of two thousand twenty two. Apparently Jeff Croft stopped reading right after he read “2022†which does not seem like a smart thing to do as not reading beyond a single point of disagreement is bound to lead to not understanding what someone was trying to say. (Which is exactly what happened.) Then again, Ian already mentioned browsers are shipping HTML5 features and authors are using HTML5 features before that point, so his rant seems misplaced. Fortunately Jeremy Keith replied with some insights.
(I blogged about this before. It bears repeating apparently.)
Copyright © 2003-2008 Anne van Kesteren. All rights reserved.
You are viewing a mobilized version of this site...
View original page here
Mowser