Hi Everyone,
webchick was really awesome yesterday to come by and talk to us for so long and encourage us to make a very detailed and well thought out list of the things we would like to see from Drupal 7. I thought I would take the initiative to start a thread to discuss all the issues, and keep track of what everyone wants and what the general consensus is about the different issues, and once we reach some sort of agreement I will start entering things into the issue queue. I think it is very important that we discuss these issues as a group before anything gets entered into the issue queue.
I say that we utilize the subject field of our comments for this discussion, make the subject field state the issue you are discussing and try to keep each comment related to one general issue, that will make things easier to keep track of. If any discussions get very involved or heated, I may move them out to a separate thread.
If anyone has notes from yesterday, please post them!
Here is a list of what I remember the most:
- Ability to define menus in .info file
- Core outputs little or no markup or CSS (or vice versa, we had some disagreement)
- Extend Coder module to check for CSS namespaces based on the Drupal Manual of Style that D4D will eventually create
hmm, yeah, I have a bad memory :-P You guys get to it! :)
Comments
Many points of entry for contribution
There are many points of entry for designers/themers/IA/front-end coder people to get involved in Drupal 7.
If you are a:
Themer/Front-end coder
Designer
UX/Information Architects
If you can write well or have the patience to answer questions:
Minimal markup / no unnecessary nested divs
Let's keep that source code clean, folks!
Give the themer more control to add wrapper and nested tags, either in the admin ui or as preprocess functions. Or both! The point is that the front end people should have control over the final markup.
Which leads me to my next point...
--
d.o: canarymason
twitter @canarymason
--
d.o: canarymason
twitter @canarymason
Well, maybe *some* unnecessary nested divs
They come in handy when you're tying to build a an inline table of floating elements. IE6 doesn't support display:inline table, and IE 7 doubles up margins and padding when using the float: attribute.
<sigh>
That's about the only time when the whole list-item > content > content-inner parade is useful.
@modulist
They are useful sometimes, but
They are useful sometimes, but I'd prefer to add them as necessary via a preprocess function or tpl.php. So much cleaner than adding them "just in case"
--
d.o: canarymason
twitter @canarymason
--
d.o: canarymason
twitter @canarymason
total control over class/ID names
Let's bring all classnames into the theme layer. This will give those of us who know the context of each tag give it a semantic name that matches that context. Then we'll have cleaner html that is smaller and can be read by humans.
The existing class/idnames can still exist, but their implementation will be in the hands of the themer. Base themes for beginner/intermediate themers can use them by default, but advanced themers will have the power they need to make their markup kick ass.
--
d.o: canarymason
twitter @canarymason
--
d.o: canarymason
twitter @canarymason
addendum to: total control over class/ID names
Ability to set classnames from the admin interface.
This could be a form element when creating a block, content type, node, menu, etc that let's users with the correct permissions override or add to the default classnames for the bit they're creating.
Better default classnames
I'd like to see a hyphenated version of the block, form, node, etc title be the first suggested classname. That could really help add some automatic semantic relevance to the classes, for the masses.
as as
Let's not overlook menu items! This would really help us target specific menu items in context. it would be sooo much better to target a menu item classed as "get-involved", instead of something like "
--
d.o: canarymason
twitter @canarymason
--
d.o: canarymason
twitter @canarymason
re: total control over class/ID names
I think this is all good stuff!
I think the Better default classnames should definitely be influenced by the Manual of Style we eventually create; it will be a guide to developers when writing all markup for Core.
I think we should categorize the specific class names for menu items under changes to the Menu system output.
The semantic classnames are a good idea, but...
would they egt in the way of portability? I fully agree that better default classnames are the way to go.
Perhaps they should be established by the CSS Style Committee that puts out the CSS Manual of Style ;-)
@modulist
@modulist
I don't want to remove the
I don't want to remove the automatic classnames from the available set of classes, I'd like all automatic classes to become optional. If we have the ability to use a semantic auto-class, a freetext custom class, and a machine-generated autoclass in any combination there should be enough options for all of us. Your class attribute can be as long or short as you like.
--
d.o: canarymason
twitter @canarymason
--
d.o: canarymason
twitter @canarymason
We should start to give examples or prototype
We could choose a theme and do a teardown to give an example of what our intent is.
By defining classes and id's and giving them semantic reference we can build the foundation for a simple base theme.
We must also consult developers familiar with SEO because crawlers use the markup styles to recognize titles.
Any suggestions on a theme to teardown?
Just a quick reminder...
Once you folks have this list whittled down to some actionable items, you should:
a) Make issues for those in the "Drupal" issue queue at http://drupal.org/node/add/project-issue/drupal. Try to make the description nice and clear in terms of what you're trying to do, and make each issue as fine-grained as possible so it doesn't diverge into lots of discussion (for example, "Fix non-semantic class names in Drupal" (good!) vs. "Make CSS in Drupal suck less" (bad!)) Make sure to tag these issues with something consistent (I think in IRC "drupaldesign" was discussed, but feel free to make that whatever you'd like).
b) Edit http://drupal.org/node/394652 to add them (use the [#XXXX] syntax, like [#394652] to make a nice link with status colouring). This page then effectively acts as the design team's "action list" for Drupal 7 (and beyond) and makes a handy place to point people who weren't in the room the day we discussed all of this but still have a major desire to see the "designer experience" for Drupal 7 improved. Also link any tag(s) that you come up with to categorize your issues so that we can continue to use those even for more minor issues.
c) Review, review, review. While comments like "Looks good" and "+1" show that there is general consensus in a given idea, the way to get changes get into Drupal 7 is to illustrate that a patch has been closely inspected by at least 2-3 people. So give detailed reviews that explain what the problem was that existed before, why the code is better now than it was, what things you tried out to test that it's working as intended, and so on. There is some info (probably way too much :P) on reviewing patches at http://drupal.org/patch/review about this.
http://drupal.org/node/28245 gives a pretty decent overview of the process, and there are also some video resources under http://drupal.org/node/128758. As always, I'm around in #drupal basically all the time, and there are over 300 other people in there who can help you get set up with a development environment if you get stuck.