Re: Proposed Design Principles

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