Re: Browser Support Policy revisited

Paul,

Thanks for the reply; I agree with your compromise 100%. I think the 
benefit of an abstract basic policy is that it will be more stable over 
time. It's kind of like separating content from presentation -- we know 
that we are going to want to change technologies and browser support 
levels, just like we want to change a site's presentation from time to 
time. The Konqueror/XMLHttpRequest example illustrates that. So let's 
build the policy to be adaptable from the beginning.

I like the "history file" parallel. I was thinking along the lines of 
the US "Homeland Security Advisory System" (http://www.dhs.gov), as in, 
"Plone's Support for IE 5 is currently Guarded"  ;)


chad





Paul Howell wrote:
> I think this Policy statement nicely meets the design goals of clear and 
> concise, and potentially these are achievable compliance levels.  I 
> think the levels are quite well chosen as useful demarcations.
> 
> What are the pros and cons of leaving the CSS specification as a 
> "currently reigning" moving target, as opposed to stating the spec at 
> this point in time?
> 
> At least as something of a more useful compromise, I would like having 
> in the same place as the Policy a clear statement of what precise specs 
> currently reign, with references for reading them, and a date given.  
> Such a "Current State of Compliance" statement could be added to the 
> policy in the same way that a history file serves a program... read the 
> most recent status and changes at the top, and work downward for a clear 
> documentation of the path this has taken.  It leaves the "moving target" 
> approach in place, but makes it perfectly clear what we need to shoot at 
> for each Plone release.
> 
> There could be a comparable Browser Listing, updated as necessary with 
> new browser releases.  This would simply be a useful item for us all, 
> not a necessary part of the Policy, by any means.
> 
> =Paul
> Smoothstone Systems
> 
> At 04:32 PM 5/25/2004 -0400, Chad Whitacre wrote:
> 
>> Designors,
>>
>> Now that we have let the Plone Browser Support Policy stew for a 
>> couple months, I propose that we revisit it and hammer out a final 
>> version.
>>
>> Contrary to what I was saying before, I think we should keep the main 
>> document pretty concise; we can address specific technologies and 
>> browsers in a separate document. The reason is that we want our policy 
>> to stay pretty constant, while technologies and brower support levels 
>> are going to change over time (e.g., Konqueror has added 
>> XMLHttpRequest support since our last go-round).
>>
>> I suggest that we gather feedback from everyone, and that we publish 
>> the document when Alex, Geir, Joe, Michael, Tom and I arrive at a 
>> consensus.
>>
>> Thanks.
>>
>>
>>
>> chad
>>
>> P.S. I would put this on plone.org but we don't have logins right now 
>> so we can handle slash- and CA-dotting. :)
>>
>>
>> ###
>>
>>
>> Plone Browser Support Policy
>> 1st edition, June 2004
>>
>> Plone strives, through standards-compliance, to be accessible to as 
>> many users through as many browsers as possible. The Plone User 
>> Interface Team's specific commitments are as follows. These 
>> commitments refer to the core Plone product out-of-the-box, but we 
>> encourage their adoption for third-party products and customized 
>> implementations of Plone.
>>
>>
>> Level 1 - Universal Information Access
>> --------------------------------------
>>   All information for anonymous Plone will be accessible using any
>>   browser.
>>
>>
>> Level 2 - Graphical Styling
>> --------------------------------------
>>   All style for anonymous Plone will be consistently displayed across
>>   all browsers that support the current reigning CSS specification.
>>   Plone will degrade for non-supporting browsers.
>>
>>
>> Level 3 - Basic UI Features
>> --------------------------------------
>>   Basic UI features for authenticated Plone will be available using
>>   any browser that supports the current reigning DOM specification ("the
>>   DOM"). These features may or may not degrade for non-supporting
>>   browsers.
>>
>> [FLAG: Does this account for disabled content managers (as opposed to 
>> disabled anonymous visitors)? I think we want to support blind folks 
>> up to this level, but I don't know enough about ECMAScript support in 
>> screen readers. Tom?]
>>
>>
>> Level 4 - Advanced UI Features
>> --------------------------------------
>>   Advanced UI features for authenticated Plone will be available using
>>   browsers that support them. These features will degrade to Level 3 for
>>   browsers that support the DOM but that do not support these advanced
>>   features; they may or may not degrade for browsers that do not support
>>   the DOM.
>>
>>
>> ###
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Plone-design mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/plone-design
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click