- From: Kai Hendry <hendry@cs.helsinki.fi>
- Date: Fri, 9 Jul 2004 13:20:07 +0300
- To: Rotan Hanrahan <Rotan.Hanrahan@MobileAware.com>
- Cc: www-di@w3.org
On Fri, Jul 09, 2004 at 10:42:12AM +0100, Rotan Hanrahan wrote: Warning: Rotan's MUA is broken. > ###--- Hard to do one without doing the other. Personally I find adapting > content to be more of a challenge, but I accept that manipulating the > content without doing something with the style can lead to bad results. > Interestingly, you can usually get away with manipulating the style > without having to manipulate the content. Here's an example: for a small > screen (or window, or viewport...) you can fit a big doc by using > content collapsing. This can be done through style (i.e. making areas > invisible until an event like a click or "mouse"-over). Alternatively, > you can collapse by moving areas into separate pages that can be reached > by clicking. The former is a style adaptation, the latter is content > adaptation. I like to think of all the possibilities. Yes, the style sheet is the key. It's like a debian package diff file. So how about a policy to leave the original content intact? Discouraging people from altering(e.g. removing) original content (in adaption) imo is important! > And this is a model that exists for real too. Which is a good starting > point. But we don't plan to stay at the starting point, so let's see > what else can be done. If you want to stay at the pure client-server > model, then fine. It's also a valid instance, but not one I would > prefer. Ok, so can we please agree to start at the client server model, and perhaps build to these more complex models? :) > ###--- And we will. Now that we have a better understanding, we are > working to create new solutions. Expect to see W3C Recommendations > from the DIWG in this area. Also, "guidelines" is something that we > have been thinking about. Something like: "how to author content so > that it is suitable for device independence". Whether we assume the > presence of adaptation, or expect the native markup to be ubiquitous is > a matter for discussion. It's early days on this one... Well, my thesis will also address this: http://www.cs.helsinki.fi/u/hendry/work/thesis/tktl/template.pdf http://natalian.org/archives/2004/06/18/the-third-way/ This is work in progress and far from complete! > ###--- Conformance and flexibility. Always a struggle. You are right, > though. If the browsers permit sloppy markup, people will write sloppy > markup. I would like a compromise where the browser displays an ugly > warning at the top of the screen, yet continues to do its best to render > the page. That way the customer doesn't fail to get the content, and > the author is encouraged to fix the markup to get rid of the ugly I can hardly call it a struggle. Conformance is extremely rare ! :) This point features in my thesis. There are problems with this. First there is no standard mechanism for a mobile user to email the web site author about the details of the problem. This is a problem area I think W3C could help address. Second, we might think browsers should display a warning. Great. But at the end of the day this is never implemented. Try Mozilla with: http://dabase.com/soup/soup4.xhtml for example. There are far too many broken pages, and the user does not want to know about it.
Received on Friday, 9 July 2004 06:35:59 UTC