 |
|
|
 |
www.dotnetnuke-websites.nl
Joined: 5/4/2004
Posts: 498
|
|
|
Jenni Merrifield wrote:
That's exactly right, which is why the Style Guide's primary audience is the developers and designers working on components that ship "out of the box" (i.e., in the official DNN packages) and third party developers and designers are only its secondary audience.
Members of the primary audience (DNN Corp and Community Team developers/designers) will be required to make new or modified components meet these guidelines at the strictest level possible.
I don't understand why you are making this distinction, we - as community members - want all developers/designers to produce the best possible standards compliant solution. Of course, you are in a better position to have corp. members adhereto the style guide.
BTW You might want to rephrase: Community Team developers/designers will be asked nicely to make new or modified components. Remember, we are dealing with an open source community.
Peter.
|
| |
|
|
 | |
|
|
|
peter schotman wrote:
Jenni Merrifield wrote:
That's exactly right, which is why the Style Guide's primary audience is the developers and designers working on components that ship "out of the box" (i.e., in the official DNN packages) and third party developers and designers are only its secondary audience.
Members of the primary audience (DNN Corp and Community Team developers/designers) will be required to make new or modified components meet these guidelines at the strictest level possible.
I don't understand why you are making this distinction, we - as community members - want all developers/designers to produce the best possible standards compliant solution. Of course, you are in a better position to have corp. members adhereto the style guide.
BTW You might want to rephrase: Community Team developers/designers will be asked nicely to make new or modified components. Remember, we are dealing with an open source community.
LOL! I think your point about asking nicely underscores why I am making the distinction - yes, we do all want developers/designers to produce the best possible standards compliant solution, but asking nicely is all we can really do in an open source environment!
That said, what I really meant with respect to Community Team developers/designers, is that new or modified code/markup in projects that must go through Release Tracker will be expected to comply with the Style Guide requirements and preferably with Style Guide recommendations. New code must comply as closely as possible. Preexisting code that has been modified should include improvements, as appropriate, to make it minimally compliant or better. So, yes, we can only ask Community Team developers/designers very nicely to comply but those that don't make the effort may find that their work does not make it into the release.
Code that is not part of the official DNN releases is completely different of course and the developers/designers creating third party modules, skins, etc. can really do whatever the heck they want and we have no way to stop them. What we can do there though, is make the Style Guide available and evangelize it, encouraging third parties to make their DNN products consistent with the standards that we intend DNN releases to follow.
:-j(enni)
Jenni Merrifield
strawberryJAMM Designs
User Experience Design Specialist
"Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity."
- C. Mingus
|
| |
|
|
| |
|
|
|
So, I've considered all the feedback received here and elsewhere and have revised the guidelines for the XHTML Standards. I've included the content of the revised section below - please let me know what you think. :)
:-j(enni)
4.1 Hypertext Markup Language
Jenni Merrifield
strawberryJAMM Designs
User Experience Design Specialist
"Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity."
- C. Mingus
|
| |
|
|
| |
|
|
|
I think you've done a great job. These are standards that are easily achieved and can reasonably be expected of everyone developing in the core and core projects.
|
| |
|
|
| |
|
|
 |
Joined: 6/3/2005
Posts: 2799
|
|
|
One thing I see in this back-and-forth is the concern for sites and/or uses which cannot work with the Strict DOCTYPE and thus need a Tansitional declaration. My major concern is that this means the Core cannot be guaranteed to adhere to a Strict DOCTYPE, even though it is obvious that such should be the goal. I woulr warrant that 95% or more of the DNN users out there never modify the core, so we're all stuck with whatever the developers provide. Allowing the core to handle Transitional means that no site can ever be Strict without eliminating something or mucking about in the core code.
At the very least, pick a standard and stick with it. Don't be a moving target. When appropriate, switch the standard to HTML5, but not before. If you do not use the strictest possible standard, publish a list of what fails the Strict DOCTYPE so those who need to use Strict can choose not to use those core modules in favor of more compliant third party ones. And if it ends up being a Transitional standard, make sure that all required code meets the Strict DOCTYPE and allow Transitional only in modules that can be replaced or unloaded by a general, non-programming, user.
Jeff
|
| |
|
|
| |