- From: T.V Raman <raman@google.com>
- Date: Wed, 28 Mar 2007 13:44:11 -0700
- To: lholst@students.cs.uu.nl
- Cc: public-html@w3.org
For the architectural overview, one issue to add is how things behave at the intersection of the XML and HTML Web. As a specific example, we need to address what should happen when HTML content is brought into XML vocabularies like RSS and ATOM --- the present situation is extremely messy. Laurens Holst writes: > Maciej Stachowiak schreef: > > Inspired by David Baron's suggested requirement of Don't Break The > > Web, a few of us came up with this proposed set of design principles, > > to be used when evaluating changes to the spec. Besides me, and the > > idea and text we borrowed from David Baron, at least the following > > people contributed: Anne van Kesteren, Marcos Caceres, Henri Sivonen > > and Ian Hickson. > > > > http://esw.w3.org/topic/HTML/ProposedDesignPrinciples > > > > I'd appreciate feedback on these. Are any important principles > > missing? Are any of these wrong? Do they need refinement? > > I have some concerns about architecture missing as a consideration in > these design principles, and actually only being mentioned as a negative > in the "Solve Real Problems" item. It makes it sound as if taking a > structured approach to a problem by first discussing the general > architecture is a bad thing. > > In any case, itùs a difficult document to deal with, because many of > these things are a matter of perspective, e.g. what exactly constitutes > øcomplexityù, and when is it too much? Also, often you sacrifice one > principle for another, so you need to weigh them somehow. For these > things, it should really only be used as a guideline. > > Some other points like ødon't break the webù I think should be taken as > rules that should not be broken, so here it is no longer a guideline. > > In general this is a nice document, and it would be interesting to > discuss certain recent proposals in terms of the guidelines laid out > here :). > > However I think it would be good if this were to be taken a step > further, and a secondary specification (or note) were created with an > architectural view of HTML. This document should provide details on > issues like how to provide graceful degradation [1], when to provide > only a scripting interface and when also a declarative one (XForms > transitional, video controls), when to create new elements and when not > (elements like <love> versus a <div>-only universe) and how to deal with > semantics that you donùt want to create elements for (microformats? > class? role? RDFa?), et cetera, et cetera. > > Reading it should give someone who wants to create a proposal for a new > feature specific guidelines on whether it is really desired, and how to > design the new feature. Because it is a separate document, it can also > be discussed on a higher level, separately from implementation details > that are specified in the main specification. > > > ~Grauw > > [1] What constitutes øgraceful degradationù, is using CSS or JavaScript > to provide fallback behaviour in older browsers considered to be > degrading gracefully? And an XBL or XSLT one? Do barebones browsers like > Lynx have to be considered here, or do we assume a world where scripting > is enabled? (personal opinion: please donùt :)) > > -- > Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Laurens Holst, student, university of Utrecht, the Netherlands. > Website: www.grauw.nl. Backbase employee; www.backbase.com. > > begin:vcard > fn:Laurens Holst > n:Holst;Laurens > email;internet:lholst@students.cs.uu.nl > tel;cell:(+31) 020-7507305 > version:2.1 > end:vcard > -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ Google: tv+raman GTalk: raman@google.com, tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Wednesday, 28 March 2007 20:44:49 UTC