Although I have both a weblog and link weblog there are still things that remain unpublished although I had plans to write about them. Here a collection of some of those things; I’ll try to make it more than just a link dump.
Unicode technical note 22 written by fantasai. Robust Vertical Text Layout (PDF; beware). This article lays the basis for the upcoming CSS3 Text Module working draft and deals with vertical text layout. (That’s right, it’s going back to working draft as the current specification has quite a few errors.) As with all things that look easy from the outside, vertical text layout is tough. And not just that, it’s complicated too. I wonder when the day comes that user agents will be able to deal with block progression, inline progression and glyph orientation. Internet Explorer has some support for vertical layouts I believe and it is on Internet Explorer that the current — not the upcoming — CSS3 Text Module is based upon.
One of the many interesting things that are noted in the twenty-seven pages long write-up is the note on the new directionality values. These will eventually apply to the DIR attribute in HTML documents and to the direction property in CSS. Currently both ltr (Latin) and rtl (Arabic, Hebrew) exist. If all goes well ttb (traditional Mongolian), ltr-ttb (Han, modern Yi) and ltr-btt (Ogham) will be added. I guess — not completely sure as I’m under informed about internationalization — that a separate btt, rtl-ttb and rtl-btt are not needed as there are no languages that go from bottom to top and have no horizontal directionality, go from right to left when displayed horizontal and from top to bottom when displayed vertical and that go from right to left horizontal and bottom to top vertical respectively. (For these values new Unicode directionality characters have to be added as well.)
Another thing — noted before — is glyph orientation. Some scripts, when displayed vertically, need their characters to be flipped ninety degrees and for others they should not. A property text-orientation will probably be added for this. Note that besides an internationalization issue the this also is presentational one as you might want to display your text vertical for some ‘side header’.
(To read that document I used Adobe Acrobat Reader 7 from inside Firefox. Although this new version is so much faster and more stable than version 6 I still managed to crash it. Ugh.)
Tim Bray: First, let’s acknowledge that this aspect of the XML spec is B.A.D.
He’s talking about attribute-value normalization. Sick. Where within elements white space is as important as hell, causing trouble for everyone working with the DOM doing more than just styling it with CSS, in attributes white space must be normalized by the XML processor. You remember “the PRE element doesn’t work” remarks in the comment section of this site? Indeed; hereby an apology to WordPress and its developers for blaming them on an XML design flaw.
I pointed this out to the WHATWG in the hope they can add a note close to the <input type=hidden> element to make more people aware of this pitfall. In XForms this is solved neatly by keeping the actual values of input fields separately inside your own custom data format where you can decide whether it should be stored inside an attribute or element. Of course, that is ten years ahead of us, but mentioning it will do no harm.
A Neutrino feed is a collection of pointers to other syndication feeds - say, a blog, Flickr and Del.icio.us - all of which belong to one individual. It's essentially indirection for feeds - point someone at your Neutrino feed and they can then discover your blog feed, your Flickr feed, your Del.icio.us feed, and anything else you care to include which you publish and can be syndicated.
More information. Home page. Draft specification. NetNewsWire will support it.
Tantek Çelik: We are pleased to announce the first public draft (v0.1) of hReview, jointly co-authored by representatives from America Online, CommerceNet Labs, Microsoft, Six Apart, Technorati, and Yahoo!.
Sounds like a cool thing to me. The only thing I dislike about ‘micro formats’ are that their semantics are hidden away in some attribute value. However, as noted before that can also be a good thing. Further I’m wondering if everyone who uses these formats is also using some appropriate profile pointer for each of them.
Forming Consensus: An article written by Micah Dubinko, once editor of XForms and now editor of the yet unpublished XHTML2 working draft. (The one with the ROLE attribute.) What struck me was that he didn’t mention HTML once. Well, actually, there was one occurrence of it in a quote from the W3C’s team comment on the Web Forms 2 submission. XForms is never going to work in HTML. Web Forms 2 is and that is very important in my opinion. Although not everyone acknowledges it, creating well-formed XHTML is a tough job. And well-formed XHTML is exactly what is needed for XForms to work in any arbitrary browser. (And that browser may not be Internet Explorer as Internet Explorer doesn’t support that, which is the number one reason for Web Forms 2 existence.)
The fact that XForms is not backwards compatible is the reason Web Forms 2 exists today and the arguments that the two should be combined are irrelevant because of this. XForms was never designed in a way that it should work in a text/html context. That there are implementations out there which actually do this doesn’t prove me wrong. It just proves that supporting Internet Explorer is important.
Oh, and Atom. Atom is very close to being finished, but now everyone starts to realize that new massive threads are created on the mailing list. I’m personally wondering how everyone will react when the fact is out that ‘Atom — we need a permathread about the new name’ is incompatible with Atom 0.3. Of course, everyone was told Atom 0.3 was just a temporary format but people are using it. Heck, for the better features of it I’m relying on it for my link weblog.
What is cool that besides becoming some protocol and format The Atom working group will also write a specification for detection of the format in HTML and XHTML pages. Should it include the in HTTP 1.1 but still in HTTP 1.0 link header so Atom can be detected in common XML documents as well? Heck, you could even detect an Atom feed from a CSS feed that way, to follow the updates. Furthermore the Atom working group will also develop an implementation guide that hopefully will arrive before the specification.
Did you know that ‘marking up’ entries sometimes takes more time then writing them?
A bit of context to Tim Bray's comment.
You remember “the PRE element doesn’t work” remarks in the comment section of this site? Indeed; hereby an apology to WordPress and its developers for blaming them on an XML design flaw.
I'd forgotten about your troubles with this same issue. But, in debugging the problem with MovableType, I was eventually reduced to flipping the MIME-type of the page back-and-forth between text/html and application/xhtml+xml. Once it was clear that exactly the same code yielded different results, I was able to stop cursing MT's developers and delve into the XML Specification.
Clearly, Bray and the other editors of the XML Specification were trying to make things easier for application developers, "Here, let me normalize that attribute-value for you!" The troubles this can cause application developers have only begun to be apparent.
Combine the CSS3 Text Module with tablet PCs, and we'll have to start adding "this side up" arrows to our webpages.
I wonder if it is practical. Most mouses don't deal with horizontal scrolling, and people hate horizontal scrolling. The only media that are useful can only be print and projection.
Technical remark: shouldn't your post be marked up as a list? It is slightly confusing to see paragraphs on different subjects following each other.
I can't believe vertical text can be that hard. Surely in programming, it's easy to think of boxes and text flow just going in a different direction. The problem lies in that the web (and HTML) has been constructed for horizontal text and flow only. We may well have to rewrite our browsers from scratch, or apply some major hacks to the existing browser engines. But maybe people are already working on this behind the scenes. (A trip to Bugzilla might reveal this.)
I hate to think about forms and vertical text though. How will they cope? Perhaps we should have a simple rule: NO VERTICAL TEXT AT ALL ALLOWED ON THE WEB. Is it really necessary? In Japanese, for instance, it was a traditional style derived from painting with brush strokes. This does not apply on the web. Unless of course there are languages that are solely written vertically, but even then, would the users not be able to adjust? (Sorry to be so eurocentric.) The web is not print, after all.
Note that CSS is not solely intended for the web and this is a real problem for some languages. Also, as mentioned, it is already used.
It seems reasonable to me to normalize attributes and to keep whitespace in elements given that the former is considered to be less 'important' than the latter.
@Chris: is it really neccesary to support ë, é, ä and all European non-interesting stuff like that? After all, the most spoken language on the web is English... who needs more than 256 ASCI characters? ^_^
Hi Anne,
We spent a long time building 'XForms in HTML', which as you rightly say, leads to documents that are often not valid, but you generally have no way of knowing that. However, of late we have been pushing everything through our Sidewinder Viewer, which validates documents first, before rendering them. At the moment it is very unforgiving, which does make it ideal for development work. Getting error messages that tell you that you have tried to use @bind with an ID that doesn't exist, or you have duplicate IDs on your case elements, is a real time-saver.
But the most interesting thing is that the schemas it uses to validate against are XHTML+SVG+MathML+XForms. If you have the formsPlayer XForms processor, Adobe's SVG Viewer, and Design Science's MathML player installed, they will automatically be invoked on your document.
Of course we're still working on things, but I think it indicates what is possible. And as so-called 'compound documents' become more common, I think this aspect will become increasingly important.
All the best,
Mark
Mark Birbeck