xHTML Principles for Layout Development

[Amy Stephen]

Today, the xHTML team decided we should consider and propse a set of
no more than ten principles to help guide our work together in
refining the core layouts.

Steve Fisher and I worked on the combined list, below, that we submit
for your consideration. Please provide your list, as well, so that we
can quickly build consensus on approach and work thorough areas of
debate.

It is best if everyone goes through this thought process to develop
their own list. However, if you are unable to set aside that time, or
if you find strong agreement with specific points listed here, feel
free to name those points and add additional criteria you see as
important considerations not yet mentioned.

Thanks!

1. Produce xHTML 1.0 Strict compliant output. (Note: This relates to
core xHTML, only. A decision on DOCTYPE for core delivered template is
separate, and outside the scope of this group.)

2. Produce clean structural markup using a minimal, defined set of
tags, that is free of layout xHTML Markup. Avoiding use of tables is a
goal.

3. Offer option to add layout markup using minimal DIV and SPAN areas.
Develop naming convention for ID and Class values and enable
flexibility to easily style similar extensions at once (ex. all
Modules or all Titles) while still providing ability to define
specifity down to the data element level. (ex. Author Name of the 3rd
Article in a Blog Layout on the Frontpage.)

4. Offer option to automatically generate basic RDFa for Articles,
Authors, Weblinks, and Contact information using DC and FOAF elements
that map to existing core structures.

5. Use Lists for Menus.

6. Use dl tags for Forms.

7. Document layouts using Wireframes, sample CSS statements, and a
blank template which will be delivered with core

8. Engage experts in testing using JAWs devices to ensure acceptable
accessiblity.

9. Consider best SEO practices, like H1 headings for titles and
automatically generating Meta descriptions if not provided.

10. Consider accessibility and mobile output, using approaches like
"skip to naviation" links allong with placing the navigation at the
bottom of the xHTML document.

[Andrew Eddie]

Re #2

Don't say "avoid using tables". Say "Use tables for appropriate applications."

Layout markup will be required in many locations. However, you could
strive for sub-templates to be structure free, eg:

/tmpl
blog.php (will contain structural markup to support leading articles)
blog_item.php (just the pure item, aim to use containers only)

Re #3

I assume you mean something like (names made up):

<div id="jBlogList{suffix}">
<div class="item-1 odd">
Foo
</div>
<div class="item-2 even">
Bar
</div>
<div class="item-3 odd">
Hum
</div>
</div>

"On the frontpage" would be handled by suffix. Leading articles could
present a challenge?


Re #6

I'd prefer to avoid DL's for forms and use OL's instead as a
"preference" for simple cases, BUT, for complex forms just do your
best.

Simple example:

<ol class="jSimpleForm">
<li>
<label for="id">Label</label>
<br />
<input type="text" id="id" value="foobar" />
<span>postpend</span>
</li>
</ol>

Compare to:

<dl class="jSimpleForm">
<dt>
<label for="id">Label</label>
</dt>
<dd>
<input type="text" id="id" value="foobar" />
<span>postpend</span>
</dd>
</dl>

Prefer the OL myself. A simple advantage is the ability to put a
:hover over the LI. Hard to do that with the DT, DD combination. The
BR can be zero'd out to nicely if desired and the label floated to the
left of the input field (but I prefer the line break myself).

And sometimes you get really stroppy forms where the only solution to
solve nested floats not working in IE is just to put the thing in a
table. Parameters generally render in a table which I don't have a
problem with. Given that you can't predict what the control has
around it, it's generally safer that way (ie, combo boxes, calendar
controls, etc).

Other points look good.

Might be worth mentioning clearing somewhere (probably a sub-point of
#2). Would like to see:

<br class="clr" />

used in preference to

<div class="clr"></div>

but even better is using

<fieldset class="clearfix">

where possible (sometimes you just have to put in that clearing element).

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/4/21 Amy Stephen <AmySt...@gmail.com>:

[Angie Radtke]

HI

>Don't say "avoid using tables". Say "Use tables for appropriate
>applications."

agree
If we would like to offer data content , tables are the best way to present
them.
This tables have be wellformed and structured sematically correct.
The easiest way is to use scope. If we got nested tables it could be
necessary to thing about headers and IDs.

Last week I saw the site of our german soccer league and it was very funny
to see that they present the club table into css pseudo tables.

What is better for a data table than soccer results!?

> 6. Use dl tags for Forms.

I think that's not a good idea.
Because of two reasons.
Imagine the normal form structure: we have got lables and textfields.
Somtimes we got checkboxes.
The label of the checkboxes are normally positioned on the other site that
the normal one of textfields.

This is a used standard we can read in the Apple , Linux and Mircosoft
Interface guidelines.
So we need exceptions .

The result is that we have more trouble with the exceptions than it helps.

The second reason is the semantic. For whom we need the semantic? Not for
visuell presentation.
If Screenreaders - Users take alook at the forms the jump into the form
mode. In this mode they aren't able to interpret structured html elements.
Like ol ul dl p etc.

So this elements are needless.

The best way is to present forms as clear as possible.

Div and spans are without a structure and the best way to style the forms
with CSS.

bye Angie

[Amy Stephen]

Andrew -

You are right on the layout markup required for aggregated layouts because of the columns. I would revise the position to state: "2. Produce clean structural markup using a minimal, defined set of tags, free of layout xHTML Markup wherever possible."

++++

Now, I apologize because I should have provided a bit of background from our chat session on the purpose of this exercise.

Our goal is to deliver revised layouts in Alpha, if possible, so that the community has as much time as possible to review and provide feedback. Since these topics can get challenging -- we discussed the importance of having a process that drives us forward.  For that reason, we agreed each member should take time to consider and present a set of ten principles that mattered most.

Once these lists have been submitted, it is likely we will agree on more than half of the items. For those items of disagreement, most will be quickly resolved. What should remain are those sticky points.

As we go through this, we need to remember the lists we share are not political statements or philosophical positions, but rather stated goals for building a specific set of layout files produced by Joomla!'s Components and Modules. Within that scope, it is the submitted goal of both Steve and myself that we not use tables.

We expect this to be one of those sticky points the team will work through. Ultimately, to arrive at a decision, it will be most productive to identify the specific layouts where tables are even a consideration. Given those layouts, we should generate code that demonstrates various perspectives. Our discussions should be directed very specifically at the pro's and con's of those code examples. We can reach consensus if we are careful with our approach (even if that consensus calls for a parameter offering choice.)

Again, my apologies, because I should have provided more explanation on this process. Everyone is invited (and encouraged) to submit their list of ten design considerations for Joomla! core layouts. For now, let's hold response to the submissions until time has been afforded those who wish to participate.

Thanks!
Amy

[Jeremy]

There may be more in the end, but this is what my brainstorming came
up with.

1. xHTML 1.0 Strict output in the core, with a set of alternative
overrides available somewhere (1. for 1.5 templates using 1.5 core
output - 2. for other DOCTYPEs, particularly a non xHTML set)

2. Semantic nomenclature for all core components and modules. This
would also establish a style, for example I like "component_title"
instead of "componentTitle" or "component-title", and be selective
when using an ID or CLASS, favoring an ID where possible and prefer
without either when appropriate.

3. Addition of RDFa (favored) and Microformats where appropriate.
Refer to DC and FOAF for direction. Should include additional methods
for JDocument to make extendable for third parties as well. Should be
included for articles, weblinks, contacts, etc.

4. Extend module <jdoc:include..> default to include more parameters,
such as a containing div id, to help reduce the need for overrides.

5. Usage of a DIV or other block elements when its contents are
logically separate from other content, and use inline elements when
the content inside is related to its parent. I don't believe that
removing every spare element is necessary, just that they all fit the
content they hold.

6. SEO concepts are varied and hard to pin down, but some basics are
agreeable such as h1 for titles, h2 for subtitles, etc. Perhaps these
can be made into advanced options also to avoid the need for
overrides.

7. Proper usage of elements and the usage of tables for tabular data
only. Will require a core css file. The better the usage of
elements, the less we will have to rely on classes or ids.

8. EXCELLENT DOCUMENTATION. To encourage third parties to follow suit
it needs to be solid, should include information about conventions and
nomenclature.

9. RTL considerations, not something I'm very familiar with though
(but I know its important!).

10. Specificity for elements, each content block should be able to be
singularly selected by CSS for styling.

Thanks,
Jeremy

[Amy Stephen]

Thank you, Jeremy. That is an interesting list - it's going to make me think.

Our collective set of ideas will be so powerful. Now is the time to communicate those items that really matter to you. Please try to get these submitted within the next week by April 27.

Thanks!

[Rob Schley]

Amy,

I have a few questions about points 2 and 3 in your list. I'm pretty sure that I am just misunderstanding what you are trying to say but I keep reading "that is free of layout xHTML Markup" as "layouts should not have markup in them." That is kind of the point of the layout so I am not sure what to make of that statement. Can you please explain that a bit more? Also, can you explain what you mean by "Offer option to add layout markup using minimal DIV and SPAN areas."

Thanks,

Rob

[Andrew Eddie]

Hi Jeremy

2009/4/22 Jeremy <jeremy...@gmail.com>:

>
> 4. Extend module <jdoc:include..> default to include more parameters,
> such as a containing div id, to help reduce the need for overrides.
>

Can you expand on what you mean by that, or what the underlying
problem is that you are trying to address?

>
> 7. Proper usage of elements and the usage of tables for tabular data
> only.  Will require a core css file.  The better the usage of
> elements, the less we will have to rely on classes or ids.
>

A man after my own heart - excellent way of putting it.

[Amy Stephen]

I tried to explain the rationale on this process earlier - but I'll be more blunt since it was likely to wordy to finish. ;-)

Please provide your list of top ten design principles for the layout effort. (Andrew and Rob - we would very much appreciate your lists, as well.)

We will discuss, question, debate, respond to submissions after Monday, April 27.

Please understand - if you do not provide a list, it will be assumed you accept the work others have put forth.

If someone wants to discuss the process, please ping me.

Thanks!
Amy

[Damien Hodgkin]

On Tuesday 21 April 2009 12:56:02 am Andrew Eddie wrote:

> Don't say "avoid using tables". Say "Use tables for appropriate
> applications."

It is completely possible to code a complete layout without ever using tables,
even for tabular data. If your CSS is setup correctly you can achieve some of
the most amazing layouts you can dream up without relying on any archaic HTML
crap.

XHTML should only be used for structuring a page, CSS for the layout and
styling. Structuring is just a subset of layout, meaning the main structure
of a page is setup via div's and span's, of course your base tags p, h1, h2,
h3, img, a, and so forth.

The rest should be handled in the CSS.

Thus tables can be completely avoided.

Just my opinion.
--
Damien Hodgkin
--------------
Independent Web Developer
Pri. Email: drac...@gmail.com
Alt. Email: damien....@gmail.com
Phone: 207-513-0678
Twitter: dracul01

[Amy Stephen]

Damien -

lol - please provide your 10 items - and hold comments until Monday.

Thanks!
Amy :)

[Damien Hodgkin]

Sorry Amy,

I don't really have ten items. But let me think about it and I will post
something when I come up with it.

Recommendation though, listen to lots of Beatles, Mountain, Quicksilver
Messenger Service, Deep Purple, Iron Butterfly, Doors and Black Sabbath. It
helps to cleanse the palette and inspire originality.

[Amy Stephen]

lol! I will listen to some of that!

I just talked to Rob and apologized for my tone.

He said - you are not really encouraging discussion if you ask people to wait to discuss. And, he's right.

Right now - we are encouraging *thinking*. It's not easy to think about xHTML and recommend ten areas you want improvement.

What's neat, though, is as we see those recommendations come forward, it's obvious we have some very smart people here who can help guide this effort forward. We might actually end up with good output if we can start with good ideas.

I think those who take that time to submit their lists will also find they are committed to the process.

That's what we need right now - smart thinking - and commitment.

Thanks!

[elin]

@Amy

I think this is a very cool idea about how to proceed, but you have to
consider questions of clarification fair game even if you are just
asking for people not to respond, because people may have lists but
not want to repeat or want to understand if there is a fundamental
disagreement. People may also need to ask questions in order to make
their lists. So, I'd kind of say asynchronous/mailing list
brainstorming is a little different than synchronous brainstorming
where a real "just write on post-its for the next 15 minutes and then
we'll cluster responses, discuss and vote" method can be really
useful.

Elin

[Rob Schley]

I'm not sure that the numerical ranking is the exact priority that I would give to each item (1 being highest, 10 being lowest) but it is probably close enough.

1. The default HTML output should be xHTML 1.0 Strict. To tackle alternative output formats, it might be wise to add naming conventions to layout files so the core can come with several output options. One possibility is to name layouts based on their output format like “default.xhtml.php” and then you can configure the output mode in Global Configuration. This will allow us to easily provide the Joomla 1.5 layouts as a "legacy" output option (think "default.legacy.php").

2. The default output should prefer classes over ids. Ids should be used for anchor elements and to facilitate skipping around the page. Ids should be avoided because unless they are used extremely carefully you can run into the situation where you have the duplicate ids which is not valid and can cause bizarre things to happen with anchors, JavaScript, etc. Classes should be based on naming conventions, preferably all lowercase with dashes for separators.

3. The default output should follow a strict hierarchal structure. Component output should get priority for h1 and h2 tags. 

4. Tables should be avoided for structural presentation. Tables should be used for tabular data. Ordered list <ol> should be used for things with explicit ordering such as most recent, most popular, etc. I tend to prefer Definition Lists <dl> for forms but I think Ordered Lists <ol> are also good. More importantly, I think all forms should use one consistent markup style. Fieldsets should be used to organize form fields into logical groups. Legends should be used for fieldsets. Fieldsets should also be used to group form buttons with an appropriate class, such as "actions". Also, tabindex attributes should be used for all form fields.

5. The core output should be designed with the idea of progressive enhancement in mind. http://www.alistapart.com/articles/understandingprogressiveenhancement

6. The design philosophy, naming conventions, and best practices for the core layouts should be documented thoroughly.

7. The core package should ship with a simple, clean template that can be used as a reference/starting point for aspiring designers/template builders.

8. Further considerations should be given to Search Engine Optimization (SEO) and Accessibility including useful title, alt, and longdesc attributes.

9. Microformat and RDF support should be incorporated where appropriate.

10. The implementation of module chrome needs to be rethought to give modules the ability to specify their own titles.

Enjoy,

Rob

[Andrew Eddie]

2009/4/22 Amy Stephen <amyst...@gmail.com>:

> I tried to explain the rationale on this process earlier - but I'll be more
> blunt since it was likely to wordy to finish. ;-)
>
> Please provide your list of top ten design principles for the layout effort.
> (Andrew and Rob - we would very much appreciate your lists, as well.)

I will, but I don't understand some of the points already made, so I
need to ask what they are about or understand where you are going with
it otherwise I might agree with the words but not your intent, that's
all.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




>

[Amy Stephen]

Excellent, thanks Rob!

[Amy Stephen]

Thanks, Andrew, you have more insight into this topic than most. Your input will be very helpful.

Elin - if you get a chance to assemble a list, it would be very appreciated, too. You are the Bug Squad Queen and no doubt have good insight on things we should consider.

Thanks for everyone's patience with this wacky approach.

Amy :)

[Robert]

Here is my list. It is a little bit copying and reordering but I hope
there are also some new aspects.

1. Using the right html-elements in the right place for the output.
Use tabels for table data, use lists for a list of informations e.g.
Menus, headers for the structure and so on. Do not use lists for forms
and tabels for layout.

2. EXCELLENT DOCUMENTATION. To encourage third parties to follow suit

it needs to be solid, should include information about conventions and
nomenclature.

3. Semantic nomenclature for all core components and modules. This
should be configurable in this way that the template designer can
choose the starting level for the heading. In some cases is makes
sense that the structure begins at 2 and not at 1.

4. xHTML 1.0 Strict output in the core

5. Separate the output in logical parts and make the parts reusable.
Allow to use a template like block1.php in different layouts (atm you
have to copy the template and make files like layout1_block1.php,
layout2_block1.php ..... )

6. Consider best SEO practices, like H1 headings for titles and

automatically generating Meta descriptions if not provided.

7. Consider accessibility and mobile output, using approaches like
"skip to navigation" links along with placing the navigation at the

bottom of the xHTML document.

8. Extend module <jdoc:include..> default to include more parameters,

such as a containing div id, to help reduce the need for overrides.

9. RTL considerations, not something I'm very familiar with though
(but I know its important!).

10. Specificity for elements, each content block should be able to be
singularly selected by CSS for styling.

Robert

[Amy Stephen]

Excellent - thanks Robert!

[Angie Radtke]

Hi,
here my ideas.

1. We should Use XHTML according to the W3C specifications for the markup.
Explaination:
Strict would be nice, but we should take care that form elements don't have
the same content for name and id like now.
If we choose strict in the template we should inform the users that some
editors insert deprecated attributes. The combination
Strict doctype and editor produces invalid output.

2.Semantic
We should write grammatically correct and descriptive markup.
We should use markup for headings that express the hierarchy of information
on the page.
We shouldn't skip any levels in the hierarchy of headings in the markup.
It would be nice if we can use configureable headerlevels.
Structure should be kept flexible to accomodate different types of pages.

3.Tables
We should use tables to display relational information and do not use them
for layout. Screenreaders can only interpret tabular data correctly if these
are
presented in tables. Fake-tables built using styles can not be interpreted
correctly!
We should use the th (table header) to describe a column or row in a table
with relational information and
Group rows with only th (table header) cells with the thead (table head)
element. We should group the rest of the table with the tbody (table body)
element.
We should use scope attribute to associate table labels (th cells) with
columns or rows.
and headers and id attributes to associate table labels (th cells) with
individual cells in complex tables.

4. Forms

we need labels for all form elements, group them with fieldsets and add
legends.
Dl, ol und ul are semantic elements and have a clearly defined semantic
meaning. They should never be used for grouping of other elements
without that meaning. Using dl/ol/ul for arranging form elements is rather
worse than to use table elements for this purpose. Both are misuses.

There are some cases where it makes sence to use list-elements for example
checkboxes like :

What's your favorite color:
red
green
yellow

Input elements (consisting of label/input field) must always be arranged
using un-semantic elements like divs and spans.
Indicate which fields are mandatory and which are optional.
Add ankers to #content at the form action
Do not use the same content for id and name of form-elements.

5.Links

Links on websites should not automatically open new windows without warning.

6.
Give meaningful and consistend names to id and class attributes.
We should devolp nameconventions.
We should measure between styling flexibility and less code.

7.Template:

a)CSS should be placed in linked files and not mixed with the HTML source
code.
b)Pages should remain usable if a web browser does not support CSS.
c)Put the content of the page in the HTML source code in order of
importance.
d)The alt attribute should be used on every img (image) and area element and
should be provided with an effective alternative text.
Decorative images should be inserted via CSS as much as possible.
Informative images should be inserted via HTML.
e)We need a logical order for the links on the page.
f)Do not make it impossible to tab to links and make the focus visible via
CSS.
g)Give blind visitors additional options to skip long lists of links bzw.
provide a page index with links to navigate to the different topics .

8.Scripting:
If client-side script is used, use ECMAScript according to the
specification.
If elements in the HTML hierarchy are to be manipulated, use the W3C DOM
according to the specification.
Add the focus to actual selected elements.

9. mod_chrome

Maybe we can add the function beezDevision into the standard to be flexible
with headerlevels of various modules

10. I think we should take into account future developments in HTML 5 and
XHTML 2

[Jeremy]

Nice lists Angie, Robert, and Rob!

I'd say while this is a bit of a strange process, its good to still
ask questions particularly on clarification. I do like the idea of
having a large set of ideas before we really start to discuss some of
the finer details, which are likely to take up a lot of time and
possibly derail some main points if we aren't careful.

To respond to Andrew's request for more detail on this

> 4. Extend module <jdoc:include..> default to include more parameters,

> such as a containing div id, to help reduce the need for overrides.

I find that I use module chromes just to make little changes. I am
proposing to expand the current default to have more parameters in
order to help reduce the need for it. Perhaps the basic concept is
that the template index.php file should be easily able to stand on its
own without needing to add files for overrides as much as possible,
and this is one example I came up with for that. Perhaps I should
also suggest better header management through the template, as in what
gets loaded in the head.

[sascha]

1. Semantic HMTL as much as possible
Use tabels for table data, etc

2. Prefer classes over IDs
Only use IDs for anchor elements and Javascript

3. Usage of DIV or other block elements to separate content blocks

4. Each content block should have its own class for CSS selection

5. Hierarchal structure
Start with h1 tag...

6. Good naming conventions and code documentation

7. For forms I would prefer divs. Something like this
<form>

<fieldset>

<legend>...</legend>

<div>
<label>...</label>
<input />
</div>

<div>
<label>...</label>
<input />
</div>

</fieldset>

<fieldset>

<legend>...</legend>

<div>
<label>...</label>
<input />
</div>

<div>
<label>...</label>
<input />
</div>

</fieldset>

</form>

For the overrides I merged to the Snowflake trunk I had all the points
above in mind. So it should be a good base...

[Amy Stephen]

Thanks Angie and Sascha. Excellent guidelines being proposed here.
Thanks to all who have contributed so far. We'll keep this open until
Monday and encourage anyone interested to please share their list.

[Ernest]

There are some great thoughts here, so please forgive a newcomer for
chipping in, but please can the media be taken in to consideration
during div structuring? It would be really nice if there could be a
nesting container class like '.noprint' for which one could set
'display:none' in a print.css file just once, for things one never
wants to print like menus, pagination, etc. I'm only asking because it
took absolutely ages to customize the templates for print layout.

[Sueter]

My list is not in order of importance (The numbers are for
counting :).) Some people have expressed what I’m thinking better and
in more detail. The specificity that Angie has makes for very
practical guidelines. What do we really mean when we say....

The last 3 points are straight from Rob and Jeremy.

1. Valid semantic markup. Use of tables for tabular data and not for
layout. What about ARIA not validating?
2. RTL. I admit to being clueless on this but it’s a necessary
function
3. Dealing with browser differences
-program for standards compliant browsers and put fixes for non-
standard browsers in separate file
-Do we go for strict validity for the current standard or allow some
CSS3 elements? Do we allow invalid code in our non-standard file?
4. Accessibility
-header mark up for headers, menus, filters and selections
-bring forms into compliance
-appropriate relational markup on tables
-skip nav
-javascript accessible
-Use links for links and markup so it can get focus and be seen to
have focus
5. Menus as lists, ability to navigate with keyboard
6. Forms. This should be an interesting discussion. I’ve never been
sold semantically on dl for lists. I could make a semantic case for ol/
ul for some forms, though not all. I’m all ears on this one.
7. Semantic nomenclature for all core components and modules. I don’t
care if we use "component_title", "componentTitle" or "component-
title" but standardizing on one would be helpful. Use ID if is really
should be an ID, otherwise use CLASS.
8. (Rob) The core output should be designed with the idea of

progressive enhancement in mind. http://www.alistapart.com/articles/understandingprogressiveenhancement

9. (Rob) The design philosophy, naming conventions, and best practices

for the core layouts should be documented thoroughly.

10.(Jeremey) Extend module <jdoc:include..> default to include more

parameters, such as a containing div id, to help reduce the need for
overrides.

Andy

[Amy Stephen]

Nice - thanks to Ernest and Andy!

[Andrew Eddie]

In summary so far I'm seeing the following broad and major points:

1. Validates to nominated standards

2. Semantically relevant markup (rolls up all the stuff on tables,
list for menus, forms ideas, micro-formats, etc)

3. Due consideration is given to support RTL sites

4. Adheres to nominated accessiblity principles (need to dicsuss which ones)

5. Standardised nomenclature (naming practices, etc)

6. Aims to work on nominated browser versions (pick which ones)

7. Consideration is given to a variety of devices (phones, etc)

8. Principles for use of scripting languages (unobtrustive javascript,
rich javascript, Mootools std, etc)

9. Consideration of search engines optimisation principles

10. Hrm, maybe about meta data??

This would form your "best practices" policy document which would
state the objectives and give guidance on how to comply. That sound
about right?

[Amy Stephen]

Nice. Thanks, Andrew! Must be why you get 100 times the Joomla! salary.

Keep it coming, folks - we want to hear from you *now* - not (just) later!

[Damien Hodgkin]

Here is my list of ten point to consider,

1. XHTML strict only, for structure ONLY.

2. Zero tables period. Tabular data can be displayed just as nicely using CSS.

3. RTL is a given.

4. Accessibility is something I really feel strongly about, as I have some
friends that are Blind or have other physical handicaps. So the layouts
should use a global CSS file that @imports the varies other CSS files for the
accessibility stuff.

5. Naming conventions should not only include the layout stuff (id's, classes
etc.) but variables in the templates. I am sure this has probably been
mentioned.

6. Move toward a fully MVC architecture. When I say fully I mean everything
even the plugins need to be split into Models for data(DB, SOAP, WSDL etc.),
Views for displaying data, and Controllers for handling all of the business
logic. I am new to Joomla! and am not sure how MVC is implemented if it is at
all. If not I can recommend either PHPnMVC by my man Tony Bibbs, or Zend
Framework (which I am recently having a torid love affair with :).

7. DL, UL or OL for Definition Lists, Unordered Lists and Ordered Lists only.
Once again preference, but, Forms layout can be achieved with CSS.

8. Styling CSS and Layout CSS should be in separate files and @imported into
the global CSS file.

9. Scripting, I myself prefer either Dojo or JQuery. But that's all
preference.

10. SEO is something I feel should be low priority. The search engines are
going to find your relevant data no matter what if it's good.

There's my list, and my views. I could have ranted for a while on some points
but luckily I chose not to ;)

[Amy Stephen]

Thanks, Damien! Much appreciated!

[Jen Kramer McKibben]

Let me just emphasize the importance of mobile device support.

A few days ago on Twitter, everyone got all excited about some iPhone
Joomla administration thing. (I don't have an iPhone, didn't pay that
close attention...)

If we can run Joomla admin on an iPhone (and perhaps other smart
phones), we should be able to easily run the front end of sites on
phones.

Looking through these comments, I don't think many people have talked
about mobile devices, but please consider the following numbers I
heard from Adobe at last year's Community Manager's summit:

In 2008, there were 500 million "smart phones" out there, with
internet enabled screens.

In 2009, there will be closer to 1 billion.

Please consider that in some countries, there are more people using
phones for accessing the internet than standard computers, and that
the phone market is a growing one.

I live in the middle of nowhere, near the New Hampshire/Vermont
border, where we are excited to just get a cell signal. 2 bars is a
beautiful thing. But I am looking at mobile phone platforms for sites
as something that will be here in another year or two, that my clients
will start requesting. While it may be less relevant today, we need
to think about this going forward.

Thanks,
Jen

[Duke3D]

Great Thoughts!

Expanding on two points I'm not seeing fully listed as considerations:
1. Verbose mode of HTML rendering for template debugging -
selectively displayed comments marking beginning and end of insertions
by extensions and sub-templates - visibility toggled by global
'minified' mode setting.
2. Enable true SEO Reader Order - Tools to place the content to the
top of the rendered HTML just below the accessability menu by
computing space requirements and reserving space with perhaps a
dynamic-calculated CSS offset that reserves room for the header and
higher placed positions.

[Andrew Eddie]

Actually I'm going to change my #10 to:

Aim for simplicity. The core output of components should aim to use
the most simple semantic markup while relying on the least amount of
CSS to achieve the job. Advanced formatting, such as being able to
determine what the third item in a list is, should be done via custom
layout overrides. The core output should allow for bare H1, H2, etc
tags to have a consistent usage across all extensions. It should
follow some of the lessons learned in the administrator where, for
example, a table with a class of "adminList" just works with a
consistent format across the board with minimal ancillary classes
required (relying on styling of the hierarchal structure).

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/4/23 Andrew Eddie <mamb...@gmail.com>:

[Ron Severdia]

OK.. so here goes... :)

First, we're making some assumptions about standards without any
mention of browser support. Not all browsers support some of the items
mentioned here (or consistently) so I guess the first step would be to
decide what the goals are with respect to browser support, W3C
compliance, Section 508, graceful degradation or other standards.

1) XHTML 1.0 Strict- Must validate according to W3C standards. Since
extensions will have varying levels of compatibility, there should be
a fallback to XHTML 1.0 Transitional.

2) CSS 2.1 (incl. Print, Aural, and Mobile CSS), Fonts preferably use
ems and exs over pixels. Must validate according to W3C standards
without any hacks, generally IDs are for top-level elements and
classes for lower-level elements, either dashes or underscores used as
a separating element (choose one)

3) Elements- clear block elements with <div class="clr"></div>, ul
lists for menus, avoid using <br /> tags,

4) Forms require the following:

ID selector for the form itself
Generic form class
fieldset grouping, legends
tabindexing
label for, title, and id
legends
option groups when more than 10 elements
button class

5) Tables- Avoiding the use of tables is paramount. As a somewhat
arbitrary gauge, let's say that tables smaller than 20x20 will be pure
CSS. If tables are used for data, the following must be defined:

ID selector for the table itself
Generic table class
summary
table caption
headers
footers
even/odd rows

6) Standardized naming, which also means lowercase for all code (and
XHTML and CSS requirement anyway) and a specific hierarchy of h1, h2,
etc. instead of "componentheading" etc.

7) Section 508/JAWS compliance- Making in-roads in government adoption
hinges on this.

8) Semantics/RDF/RDFa/Microformats- While RDF is great in concept and
theory, it isn't HTML 4 compliant. But if that's not an issue, then it
should be used where appropriate. Microformats are a good idea to
"play nicely", but I think their usage might be limited within Joomla.
Naturally would need class extensions for 3PDs.

9) Mobile considerations- With the overwhelming popularity of the
iPhone, it would be great to have an auto-detection on the admin side
to switch to an iPhone and/or mobile-XHTML template. Also incorporate
some basic considerations to make formatting & navigation easier.

Since I've likely overdone my 10 items by being overly verbose, I'll
stick with 9. :)

Additionally, I like the idea already presented here of including a
blank template with the core. I've created one for Joomla 1.5 which I
use at Joomla Days or other teaching/template situations. Beginners
who want to see the basics of how things work so they can learn find
this "shell" very valuable.

These are just some rapid one-off thoughts to consider.

[elin]

I'm not going to repeat but here are a few others:

My list


1.Tmpl xml should not include irrelevant parameters for the layout and
it should be clear/intuitive to users what level of drill down
individual/groups of parameters apply to or if they apply to all.
(Examples from the current codebase: irrelevant parameters: standard
contact layout includes category layout parameters; drill down
confusion: when making a contact category link users frequently report
bugs that say that contact category parameters are not applying to
standard contact layouts. The interface does not indicate that they
are category only parameters ).

2.Allow users to set globals for all parameters (standard contact
layout again is a good example of where this is not possible). (I
would love to add allow administrators to change defaults ( set
globals) for module parameters without an override but I know that's
not happening.)

3. Credential checking. When credentials are checked and rejected,
produce appropriate messages (not error pages; rejecting credentials
correctly is not an error) and layouts with proper html status headers
being sent. Handle these consistently across all core layouts (for
example, I would say always treat unpublished items as 404s, page does
not exist). Correctly incorporate ACL into this (a register to read
more claim should not be made for items that are not available to the
default group).

4.Use opening to new windows sparingly with clear indication that a
new window will be opened and in a strict compliant way (e.g. using
onclick). This one is tricky because the standards are going back and
forth (the target attribute is allowed in newer standards), but open
any new windows in a standards compliant way e.g. using onclick.

5. In very specific instances, such as print views, use nofollow.

6. Use publish date not create date as default for date related items
such as sorting and display, though adding a parameter to give users
the choice (create, publish or modified) would be even better.

Elin





On Apr 23, 8:46 pm, Ron Severdia <ron.sever...@community.joomla.org>
wrote:

[Chris Davenport]

I agree with most of what has already been suggested so I'm not going to provide a list of 10 here (sorry Amy), but instead I'll just throw in some random comments that may or may not help.

XHTML Strict.  I think that core output should be designed to be Strict, but the core templates should have Transitional DOCTYPEs until we can solve the problem of ensuring that WYSIWYG editors can guarantee Strict output.

If there is disagreement over whether certain output types should be done in one way or another, remember that it is possible to do both and allow the administrator to choose which layout they prefer in a particular situation.

I don't think anyone has mentioned the subject of performance (my apologies if someone has and I just didn't notice).  Although we should be careful not to optimise prematurely, I think that the core templates should demonstrate good practice in achieving reasonable performance.  I found this to be a useful resource: http://stevesouders.com/docs/web20expo-20090402.ppt

Don't hard-code the name of the template into template paths anywhere.  I want to be able to say to people that if they want to customise one of the core templates they should always copy it, then customise the copy, so that future updates to Joomla don't overwrite their customisations.  To make it possible to do that without having to alter any of the code, it is necessary to avoid hard-coding the template name into paths in the template code.  Milky Way and Beez (if I recall correctly) need fixing in this respect (I'll get a patch together if I ever get a few minutes to spare).

I think it's very important to have a policy regarding which browsers will be supported.  In particular, we need to decide if IE6 is still supportable.  Personally if anyone asks me to support IE6 nowadays I always double my fee.  That doesn't compensate for the frustration but it usually just about covers the extra time required.

Documentation is extremely important, but as this is my area of responsibility and I'm currently working on producing lots of new material on templates, I should be able to help a lot in this area.

Finally, this might be out of scope for this particular group, but I raise it here because it is important and it might impinge on this group's work: backwards compatibility.  Someone who upgrades from 1.5 to 1.6 with a non-core template installed (which is probably almost everyone), will find that their site looks horribly broken.  They are faced with two choices (apart from abandoning the upgrade of course): either they upgrade their template, which they may or may not have the skills to do; or they use the old layouts as overrides, which may not be simple if their template already has overrides in place.  I know we all hate to have to think about backwards compatibility, but I believe we should consider how we can help people in this situation and try to ensure that we make the hurdle as low as possible.  After all, 1.6 is a minor release which "...usually indicates a significant change in functionality.  Moderate to high level of backward compatibility with previous minor increments." (http://docs.joomla.org/Version_Strategy).  What I don't want to see is people struggling to upgrade to 1.6 and perhaps abandoning Joomla because they can't figure out how to make their old template work with the new release.  So my ideal would be a kind of legacy mode switch that would somehow make it all happen.  With that in mind I was particularly intrigued by Rob's suggestion: "To tackle alternative output formats, it might be wise to add naming conventions to layout files so the core can come with several output options. One possibility is to name layouts based on their output format like “default.xhtml.php” and then you can configure the output mode in Global Configuration. This will allow us to easily provide the Joomla 1.5 layouts as a "legacy" output option (think "default.legacy.php")."  Maybe that's not the best way to do it, but I think it is something that needs some serious thought.

Chris.

2009/4/26 elin <elin....@gmail.com>

[Amy Stephen]

Thanks Elin and Chris!

I don't think our scope was very clear - but Chris's point that core output should be designed to be strict gets right at the issue of scope, and I agree with his statement. Core should produce strict compliant output - what the Template actually uses for DOCTYPE is a separate discussion. To be clear, for this effort, we are not talking about the actual core 1.6 template - or any CSS issues - or even parameters used to generate menu items. We are very specifically looking at the xHTML core produces.

Also - Chris - in another discussion, it was determined that we are going to somehow make available the old layouts with the 1.5 Milkyway Template. That is intended to help with the backwards compatibility issue you correctly identify as important. It has yet to be decided how that template package will be shared. I do believe this group will make a recommendation for that as a part of this process.

Regarding the documentation, it's good you are a part of this effort and I am pleased to see you take the lead on that job. Thanks!

For others who want to contribute ideas, please try to get yours posted today or tomorrow.

Thanks to everyone!

[abernier]

About xHTML markup for forms, I'd like to share with you a great
paper, written by Aaron Gustafson (an alistapart.com author) :
http://www.slideshare.net/AaronGustafson/learning-to-love-forms-web-directions-south-07

I'm sure we would really take advantage on following his guidelines
which are really simple to apply.

Cheers,
Antoine BERNIER

[Jeremy]

Since Monday has come to us, I have already started to take the lists
and compile them. If anyone has a list, please submit it today so I
can put them together.

I'm trying to arrange the points so the similar items are together
(with subpoints) to help see what is similar and different about the
concepts. I will also try to add a few of the extra thoughts that
weren't part of the lists.

[Amy Stephen]

That is *much* appreciated, Jeremy. I am looking forward to seeing this!

As Jeremy is saying, we still welcome feedback today.

[Louis Landry]

Design principles of anything are going to be varied and dependent upon the goals of whomever is designing the work.  This is no different in (x)html than it is in really any other medium in my opinion.  The most important thing is that we make it as easy as possible for each person to apply their OWN design principles to their Web site.

To that end the things that I think are most important in working on this project are as follows:

1) Simple:  The layouts should be as absolutely simple as possible, but no simpler (to borrow a phrase).  I think we should be looking to strip out unnecessary parameter options from all over the place and simplify layouts for ease of understanding and readability.  The easier it is to understand what is going on in the base layouts, the easier it will be for people to make the modifications they need to make so that their own design goals are met.

2) Strong:  All of the layouts should follow a strong set of conventions.  Similar things should be marked up in similar ways and the code that marks them up should be structured in a similar way across all layouts.  The stronger our conventions, the easier it will be for others to pick up how things work and the easier it will be for them to make modifications to suit their needs.

3) Semantic: Markup should be built that is as meaningful as possible for both humans and machines.  Different things mean different things to people, so there is no one way.  We can see that in this thread people disagree on how a form should be marked up.  There isn't a wrong or right way, there are just differences in what things mean to different people.  With the consistency of strong conventions and meaningful, descriptive markup it will be easier to style output as well as extract data from it.

4) Complete: We should be working to ensure that all possible markup is generated in layouts so that designers are given the opportunity to make modifications as they deem necessary.  There are still some areas where advancements can be made on this front and while perfection may or may not be possible we should be constant in our goal to improve completeness.

5) Documented: The decisions and reasoning behind the layout's structure and implementation should be as well documented as possible.  Best practices should be described for completing common tasks in layouts.  

I'm looking forward to seeing what you guys and gals put together with this little project.  Those are my thoughts... and good luck :)

- Louis

On Mon, Apr 27, 2009 at 6:51 AM, Amy Stephen <amyst...@gmail.com> wrote:

That is *much* appreciated, Jeremy. I am looking forward to seeing this!

As Jeremy is saying, we still welcome feedback today.

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[Ian MacLennan]

Okay...  here's my list - not a full ten items, but some thoughts.
1.xHTML 1.0 Strict

2. Push as much as possible to the layout.  This really goes beyond just doing new layouts, but what is produced in the layout and what isn't.  Just wanted to put this out there to think about, and it may not be wortwhile.  But, for example, in com_content, we call behavior.mootools in the controller in the frontend.  This means that there are limitations to what you can easily override with the template.  I'm not in favour of getting rid of mootools, but as it really is a layout decision, I think it should be easy to customize in the event that somebody wants a very clean, lightweight site.  This would also make it easier to develop for other devices as well.

3. Use the appropriate markup in the appropriate places.  This *will* mean virtually no tables, but in some places tables will make sense.  Not because it is hard to replicate the same look and feel in CSS, but because if we are talking about using markup properly, the proper way to mark up a table of data is a table.  This is an accessibility win.

4. Documented consistency.  This means that layouts will bear a striking resemblance to one another, because they will, in fact, be very similar.  This standard needs to be documented so that it spreads to third party components.

5. one challenge is how to separate layout parameters from data parameters in our views.  For example, in category blog view, we have sort order parameter and the category id, which are data parameters, and number of columns and number of leading articles, in which you have some overlap.  You don't want to tie the menu items to the template, so I suppose you're kind of stuck with what is in the core layouts.  So I suppose we need to make sure our parameters are complete enough for template developers to use to override.


Ian

[Amy Stephen]

Thanks Louis and Ian - very good thoughts, both.

[Jeremy]

I have uploaded the list of items to

http://groups.google.com/group/joomla-dev-cms/files

I included pretty much all points I hope, but its rather long at the
moment. There are some items that are more template related instead
of core output, they are there just so everything can be considered.
I'm not sure the best way to proceed, other than to start with the top
and move down.

Here are the top 5 (number of times mentioned)
1. (13) Produce xHTML compliant output.
2. (12) Proper usage of elements, for example the usage of tables for
tabular data only. Will require a core css file.
3. (11) Semantic nomenclature for all core components and modules.
4. (7) Consider accessibility
5. (8) Documentation and examples

[Amy Stephen]

Nice job, Jeremy! Wow!

It would be good for everyone to read through the PDF Jeremy created and then consider next steps.

[Rob Schley]

Nice work Jeremy, thanks for compiling that data.

Best,

Rob

On Thu, Apr 30, 2009 at 10:21 AM, Jeremy <jeremy...@gmail.com> wrote:

[Jeremy]

So now that we have all of this, and its been a week, how shall we
proceed? I presume some chat on Skype would provide a quick conduit
for determining which points are contested and which are easily
settled?

[Andrea Tarr at Tarr Consulting]

I think your suggestion is good.

Andy

[G. D. Speer]

This is a great list - I have a concern about #1 possibly due to my limited understanding. 

I don't want to trigger a huge debate - I'm just not sure how this should be addressed.

 

As I understand it, if we meet the XHTML goal our markup becomes 'tag soup'.  From my reading:

 

1. Though we may write will formed XHTML to the 1.0 Strict Doctype, Joomla serves pages as HTML.

This is because IE does not understand/process a page with MIME type of text+xml or application+xml.

Also, for community submitted blog content, the HTML standard is far more forgiving of malformed code.

 

2.  A standards compliant browser parses a Joomla-produced page as HTML because the MIME-type

overrides whatever XHTML DOCTYPE is there.  The only time a DOCTYPE has effect is when the page is read by a

validator or possibly when opened locally without being served - it has no effect on how the page is parsed.

 

3.  I am among those that like working in XHTML because of the XML structure - code editors more clearly
show the nesting of elements and any unclosed tags.  To me, the code is more human readable / has better structure. 

Lots of good reasons to be more rigorous in coding - easier to demonstrate standards compliance.

 

4.  The problem is that though HTML 4.01 is very forward compatible in that all XHTML 1.1 tags are identical 
and it seems to accept the XHTML conventions (self-closing tags, lower case tags and arguements, quoted
arguement values), it doesn't parse the same, the DOM has a different structure when parsed as HTML,

errors have to be handled, and in some cases, the page is 'broken'.  I don't know enough to know whether

the level of 'broken' is of concern or whether we need to addess it.  Several writers said self-closing some

empty tags like a script or an anchor that is a target and not a link is valid XHTML that validates, but

is sometimes not read by some browsers even when they are in standards mode. 

 

5.  I haven't been able to find a list of exceptions - XHTML tag formats that would parse wrongly as HTML

to know to avoid them or structure them differently.  I'm not suggesting we go backwards - I'm just exploring

whether it would be practical to identify and use the subset of tags and syntax that parses identically in

both envrionments.

 

Any thoughts?  Am I way off base to be concerned about this?

Thanks,

Duke

 

 

----- Original Message -----

From: Rob Schley

To: joomla-...@googlegroups.com

Sent: Thursday, April 30, 2009 1:19 PM

Subject: Re: xHTML Principles for Layout Development

---

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.12.10/2088 - Release Date: 04/30/09 06:01:00

[G. D. Speer]

I read today of issues getting Joomla's baseURL working due to HTML parsing of the otherwise well formed XHTML tags.

See Joomulus debugging saga told here and thought to be an IE issue...

http://blog.joomlabear.com/joomulus-20-simple-powerful/comment-page-1/#comment-1167

 

I came across this 2009 W3C article for solving issues serving XHTML as HTML as we do in Joomla:

http://www.w3.org/TR/xhtml-media-types/#compatGuidelines

 

and this article which seems, despite the headline, to be the most accurate, practical and well balanced statement I have seen concerning how to address the issues for current generation browsers.  It does a good job of pointing out fact from fiction and only focusing on the real issues.

http://www.webdevout.net/articles/beware-of-xhtml 

 

FWIW,

[Andrea Tarr]

Jeremy compiled a list of our earlier discussion (you can download the
file at the bottom of google groups). That was pretty massive so I've
tried to break it into smaller chunks. I put it in a spreadsheet so I
could assign different categories and groupings. I've picked a couple
of controversial topics we can discuss individually (forms, tables,
naming conventions). I'll post separate messages on the other 2
topics.

Forms
The biggest divergence of opinion was in how to markup forms.

There are some things that should be done just in terms of usability
and accessibility within the layout:
a. Associate the label with the form element by using the "for" in the
label
b. Use fieldset and legend to group appropriate items together
c. Make sure that the order of the elements makes sense when tabbing
through them
d. Make sure that the form can be completed and submitted using the
keyboard
e. Don't use just color to indicate what are required elements and
indicate required fields/special formatting to the user before they
input the field

We have received the following theories on how the markup should be
done:

dl lists
ol lists
ul lists
tables
divs &/or spans

Forms are not only used on the Contact Us page, but on nearly every
page asking for information from the user. Here are some of the
examples of places that use forms:

Contact Us page
A survey
A poll
Filter/Search/Order on groups of data
Pagination display pages
Login screens
Lists of articles in the Article Manager
Creating/editing an article
Parameters, both as part of an entry page or on their own

If we are really writing semantic xHTML would be want consistancy for
all forms or should we look at the use of the form to dictate the
markup? This will have ramifications on how the CSS is done.

I am perfectly willing to have my mind changed (or go with what's
decided) but to start the discussion and make clear my biases here's
what I think:

The use of the form should dictate the markup. I would decide how I
would mark something up if it weren't a form and mark up the form the
same way.

Therefore, I'd probably do it this way:

Contact Us page - divs
A survey - ol or ul
A poll - ol or ul
Filter/Search/Order on groups of data - divs
Pagination display pages - divs
Login screens - divs
Lists of articles in the Article Manager - table, because I see it as
tabular data
Creating/editing an article - div
Parameters, either as part of an entry page or on their own - ul

On Apr 20, 11:58 pm, Amy Stephen <AmyStep...@gmail.com> wrote:
> Today, the xHTML team decided we should consider and propse a set of
> no more than ten principles to help guide our work together in
> refining the core layouts.
>
> Steve Fisher and I worked on the combined list, below, that we submit
> for your consideration. Please provide your list, as well, so that we
> can quickly build consensus on approach and work thorough areas of
> debate.
>
> It is best if everyone goes through this thought process to develop
> their own list. However, if you are unable to set aside that time, or
> if you find strong agreement with specific points listed here, feel
> free to name those points and add additional criteria you see as
> important considerations not yet mentioned.
>
> Thanks!
>
> 1. Produce xHTML 1.0 Strict compliant output. (Note: This relates to
> core xHTML, only. A decision on DOCTYPE for core delivered template is
> separate, and outside the scope of this group.)
>
> 2. Produce clean structural markup using a minimal, defined set of
> tags, that is free of layout xHTML Markup. Avoiding use of tables is a
> goal.
>
> 3. Offer option to add layout markup using minimal DIV and SPAN areas.
> Develop naming convention for ID and Class values and enable
> flexibility to easily style similar extensions at once (ex. all
> Modules or all Titles) while still providing ability to define
> specifity down to the data element level. (ex. Author Name of the 3rd
> Article in a Blog Layout on the Frontpage.)
>
> 4. Offer option to automatically generate basic RDFa for Articles,
> Authors, Weblinks, and Contact information using DC and FOAF elements
> that map to existing core structures.
>
> 5. Use Lists for Menus.
>
> 6. Use dl tags for Forms.
>
> 7. Document layouts using Wireframes, sample CSS statements, and a
> blank template which will be delivered with core
>
> 8. Engage experts in testing using JAWs devices to ensure acceptable
> accessiblity.
>
> 9. Consider best SEO practices, like H1 headings for titles and
> automatically generating Meta descriptions if not provided.
>
> 10. Consider accessibility and mobile output, using approaches like
> "skip to naviation" links allong with placing the navigation at the
> bottom of the xHTML document.

[Andrea Tarr]

A second area of lesser controversy is naming conventions.

Should a class/id of component heading be:

1. component_heading
2. component-heading
3. componentHeading
4. componentheading

Any preferences?

Andy

[Andrea Tarr]

For the most part, people agreed that tables should not be used for
markup and that tables should be used for tabular data.

This may actual already come out in the discussion on forms, but what
is considered tabular data? a list Soccer scores and dates, yes; an
Article, no; what about a spreadsheet? a list of database records? a
list of database records with fields? the list of articles in the
article manager? :)

[Amy Stephen]

Good for you, Andrea!

On Mon, May 18, 2009 at 12:30 PM, Andrea Tarr <at...@tarrconsulting.com> wrote:

Jeremy compiled a list of our earlier discussion (you can download the
file at the bottom of google groups). That was pretty massive so I've
tried to break it into smaller chunks. I put it in a spreadsheet so I
could assign different categories and groupings. I've picked a couple
of controversial topics we can discuss individually (forms, tables,
naming conventions). I'll post separate messages on the other 2
topics.

Forms
The biggest divergence of opinion was in how to markup forms.

There are some things that should be done just in terms of usability
and accessibility within the layout:
a. Associate the label with the form element by using the "for" in the
label
b. Use fieldset and legend to group appropriate items together
c. Make sure that the order of the elements makes sense when tabbing
through them
d. Make sure that the form can be completed and submitted using the
keyboard
e. Don't use just color to indicate what are required elements and
indicate required fields/special formatting to the user before they
input the field

Good guidelines.

Color would be a CSS issue, which is outside of our scope.
 

We have received the following theories on how the markup should be
done:

dl lists
ol lists
ul lists
tables
divs &/or spans

Forms are not only used on the Contact Us page, but on nearly every
page asking for information from the user. Here are some of the
examples of places that use forms:

Contact Us page
A survey
A poll

We will not have surveys or polls.
 

Filter/Search/Order on groups of data
Pagination display pages
Login screens
Lists of articles in the Article Manager
Creating/editing an article
Parameters, both as part of an entry page or on their own

If we are really writing semantic xHTML would be want consistancy for
all forms or should we look at the use of the form to dictate the
markup? This will have ramifications on how the CSS is done.

I am perfectly willing to have my mind changed (or go with what's
decided) but to start the discussion and make clear my biases here's
what I think:

The use of the form should dictate the markup. I would decide how I
would mark something up if it weren't a form and mark up the form the
same way.

Therefore, I'd probably do it this way:

Contact Us page - divs
A survey - ol or ul
A poll - ol or ul

No survey or poll.
 

Filter/Search/Order on groups of data - divs
Pagination display pages - divs
Login screens - divs
Lists of articles in the Article Manager - table, because I see it as
tabular data
Creating/editing an article - div
Parameters, either as part of an entry page or on their own - ul

Agreed.

Thanks - good job moving this forward!

[Andrea Tarr]

I took Andrew Eddie's grouping and filled in the detail with what I'm
planning on using on the backend core layout files. This is a working
document :)

1. Validates to nominated standards

-xHTML 1.0 strict (Issues: ARIA & Editors)

2. Semantically relevant markup
-TABLES:
a. Use tables to display relational information and do not use them
for layout.
b. Use the th (table header) to describe a column or row in a table
with relational information and Group rows with only th (table header)
cells with the thead (table head) element.
c. Group the rest of the table with the tbody (table body) element.
d. Use scope attribute to associate table labels (th cells) with
columns or rows and headers and id attributes to associate table
labels (th cells) with individual cells in complex tables
-FORMS:

a. Associate the label with the form element by using the "for" in the
label
b. Use fieldset and legend to group appropriate items together
c. Make sure that the order of the elements makes sense when tabbing
through them
d. Make sure that the form can be completed and submitted using the
keyboard

e. Indicate required fields/special formatting to the user before they
input the field.
f. Use semantic markup for the form based on the use of the form, not
the fact that it is a form. For instance, use divs for contact pages,
login screens and creating/editing articles, pagination & filters, use
tables for lists of tabular data (e.g. list of articles in Article
Manager), use ul for simple lists such as parameters.
- HIERARCHICAL STRUCTURE:
a. Use heading tags as well as componentheading and contentheading
-ID's & CLASSES:
a. Use ID if it really should be an ID, otherwise use CLASS.
b. Be careful that you can't end up with one ID more than once on a
page when the page is actually served lists for menus
c. Use as many classes as needed and no more (and how many is that,
pray tell?)

3. Due consideration is given to support RTL sites

-Parameter to designate RTL
-text align: right
-should this change the order of fields: e.g. should the columns in
Article Manager swap around based on LTR or RTL.
-(other RTL such as menu and module switching are template, not core
layout)

4. Adheres to nominated accessiblity principles

-header mark up for headers, menus, filters and selections
-bring forms into compliance
-appropriate relational markup on tables
-skip nav
-javascript accessible
-Use links for links and markup so it can get focus and be seen to
have focus
-able to navigate logically and fully with keyboard
-ARIA

5. Standardised nomenclature (naming practices, etc)

To prevent breakage and in recognition of the numerous extensions that
fold right into the backend, I'm going to use existing names where
possible and follow similar conventions.
For classes & ids:
-One word prefered
-When two words are use, use all lowercase, no punctuation
-If you are using related classes hyphenate between the
words: .button2-left, .button2-right, button2-top, .button2-bottom,
#content-box, #submenu-box, #border-top, #border-bottom

6. Aims to work on nominated browser versions (pick which ones)

-IE6+, FF2+, Safari 3.1+, Opera 9.0+, Google Chrome
-program for standards compliant browsers and put fixes for non-
standard browsers in separate files

7. Consideration is given to a variety of devices (phones, etc)

8. Principles for use of scripting languages (unobtrustive javascript,
rich javascript, Mootools std, etc)

9. Consideration of search engines optimisation principles

10. Hrm, maybe about meta data??

On Apr 22, 5:45 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> In summary so far I'm seeing the following broad and major points:
>
> 1. Validates to nominated standards
>
> 2. Semantically relevant markup (rolls up all the stuff on tables,
> list for menus, forms ideas, micro-formats, etc)
>
> 3. Due consideration is given to support RTL sites
>
> 4. Adheres to nominated accessiblity principles (need to dicsuss which ones)
>
> 5. Standardised nomenclature (naming practices, etc)
>
> 6. Aims to work on nominated browser versions (pick which ones)
>
> 7. Consideration is given to a variety of devices (phones, etc)
>
> 8. Principles for use of scripting languages (unobtrustive javascript,
> rich javascript, Mootools std, etc)
>
> 9. Consideration of search engines optimisation principles
>
> 10.  Hrm, maybe about meta data??
>
> This would form your "best practices" policy document which would
> state the objectives and give guidance on how to comply.  That sound
> about right?
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

[Amy Stephen]

Andy and I are going to talk later today or tomorrow, to try to
finalize recommendations and come up with a plan we can discuss for
how we might split up the work and get the layouts ready for the alpha
release.

I don't mean to take this discussion off-line, but we've stalled and
it could be helpful for a couple of us to voice, put heads together
and bring back ideas for the group to consider. If there are strong
objections to this approach, please let us know. Otherwise, understand
the ideas will be presented and input and changes will be welcome.

Thanks!
Amy

[Rob Schley]

Sounds good. I look forward to the report back.

Rob

[Andrea Tarr]

Amy Stephen & I went over the compiled list of 10 principals and made
some changes. We'd like to get this finalized in the next couple of
days so that we can finish the coding in time for the alpha release of
1.6 coming out in a few weeks.

1. Validates to nominated standards

xHTML 1.0 strict. We will validate the layouts to strict, but the
template could still use transitional. It is the template which
actually controls the validation standard.

2. Semantically relevant markup
-Tables:

a. Use tables to display relational information and do not use them
for layout.
b. Use the th (table header) to describe a column or row in a table
with relational information and Group rows with only th (table header)
cells with the thead (table head) element.
c. Group the rest of the table with the tbody (table body) element.
d. Use scope attribute to associate table labels (th cells) with
columns or rows and headers and id attributes to associate table
labels (th cells) with individual cells in complex tables

-Forms:

a. Associate the label with the form element by using the "for" in the
label
b. Use fieldset and legend to group appropriate items together
c. Make sure that the order of the elements makes sense when tabbing
through them
d. Make sure that the form can be completed and submitted using the
keyboard

e. Indicate required fields to the user before they input the field.
For this project we will use an asterisk before the field to indicate
required fields and will have a JText comment Required fields are
indicated with an *.

f. Use semantic markup for the form based on the use of the form, not
the fact that it is a form. For instance, use divs for contact pages,
login screens and creating/editing articles, pagination & filters, use
tables for lists of tabular data (e.g. list of articles in Article

Manager), use ul for simple lists such as parameters. Decide how you
would mark it up if it were not a form, then markup that way.
- hierarchical structure:
a. Use heading tags as well as componentheading and contentheading. H1
is the componentheader, h2 contentheading. We would like feedback on
the hierarchical structure.
-ID's & Classes:

a. Use ID if it really should be an ID, otherwise use CLASS.
b. Be careful that you can't end up with one ID more than once on a
page when the page is actually served lists for menus
c. Use as many classes as needed and no more (and how many is that,
pray tell?)

d. Restore current classes to yootheme templates unless they have
improved functionality, i.e. use createdate instead of created, but
use icon email instead of the old buttonheading.
e. If you see id's that aren't carried forward, make a list. If you
think you have a class that you don't need put it on the list.

3. Due consideration is given to support RTL sites

- we need RTL expertise on this because it's important and we don't
have the skills.

-text align: right
-should this change the order of fields: e.g. should the columns in
Article Manager swap around based on LTR or RTL.

4. Adheres to nominated accessibility principles
-header mark up for headers, menus (module), filters and selections
-bring forms into compliance
-appropriate relational markup on tables (including scope)
-skip nav (template)
-javascript accessible (the only javascript in the front end layouts
is checking for required fields. That's also covered server-side)
-Use links for links and mark it up so it can get focus and be seen

to
have focus
-able to navigate logically and fully with keyboard

5. Standardised nomenclature (naming practices, etc)

Use existing names where possible and follow similar conventions.
For new classes & ids:
-One word preferred

-When two words are use, use all lowercase, no punctuation
-If you are using related classes hyphenate between the
words: .button2-left, .button2-right, button2-top, .button2-bottom,
#content-box, #submenu-box, #border-top, #border-bottom

6. Aims to work on nominated browser versions (pick which ones)
-IE6+, FF2+, Safari 3.1+, Opera 9.0+, Google Chrome
-program for standards compliant browsers and put fixes for non-
standard browsers in separate files

7. Consideration is given to a variety of devices (phones, etc)

- community member to step up on this matter

8. Principles for use of scripting languages (unobtrustive javascript,

rich javascript, Mootools std, etc). There is very little Javascript
in use in the frontend core at present.

9. Consideration of search engines optimization principles
- would like advice from SEO folks

10. Open, what do you want here?

WHAT WE NEED:
1. Comments and suggestions on the 9 principals above if you think
there should be changes. We left #10 open in case we missed something
important. Feel free to tell us what that was.
2. Someone with RTL experience to tell us what we need to do in the
layout file to accommodate them and to work with us to be sure we get
it right.
3. Suggestions on the hierarchical structure of the headers. What's
the h1, h2, etc. This will have both SEO and accessibility
implications. If you think we should have it user defined, propose a
method.
4. An SEO person to fill details of #9.
5. Someone to take on the mobile world. What do we need to do
differently or keep in mind in the layouts so we don't exclude mobile
devices?
6. Volunteers to help us make the final changes

The Yootheme layout files that we are using are very close to these
rules, so finishing them shouldn't be a big deal. We'd like to get
these new layout files into the alpha release so we want to finish all
the coding within the next two weeks or so.

On Jun 1, 9:07 pm, Rob Schley <rob.sch...@community.joomla.org> wrote:
> Sounds good. I look forward to the report back.
> Rob
>

[Amy Stephen]

Thanks, Andy.

+++++

We need help getting Snowflake in sync with where development is at - without losing the YOOtheme layout work. Were there changes to the layouts that we should be aware of?

Would someone be able to help with that?

++++++

Thanks to Andy for her work summarizing these principles. We went through her list tonight, and I think it is very good. Please post concerns.

Also, please post in if you can help with areas identified - we need experts to guide this  with RTL, SEO, and Mobile.

We also need volunteers to help with what we hope are relatively minor changes needed to the layouts. We want the first set of layouts ready for Alpha - and that is in a couple of weeks. We will share specifics on what and how and when in the next couple of days.

Please consider helping, if you can. This will be a very nice improvement for 1.6. Thanks!
Amy :)

[Rob Schley]

I just had a meeting with Amy and Andrea to discuss their plans and I suggested that they not bind themselves to preserving the old class names in the new layouts. If the markup is changing anyway, the old class names will not be much help anyway. So, they are going to put together some ideas for a standardized approach to class names and some best practices that will go along with the new layouts.

For those that are concerned about backwards compatibility, we will preserve the old layouts in the milkyway template. So, if you are using a template designed for 1.5, you should be able to copy the layout packs out of milkyway into your new template and be good to go.

Best,

Rob

[klas berlič]

a. Use tables to display relational information and do not use them
for layout.

Although it is current trend to drop tables wherever possible, in most cases there is no reason behind this, except being trendy. Some layouts require tables and it is the only right thing to do it with tables (e.g. list layout or table layout in J.1.5. terms). So I would rephrase this to "Use tables for layout only where appropriate and to display relational information ."

2009/6/3 Rob Schley <rob.s...@community.joomla.org>

[Andrea Tarr at Tarr Consulting]

There are definite accessibility reasons not to use table for strictly layout purposes so I think that is beyond just being trendy. However, I agree that the trend toward NO tables is inappropriate. When the information is related in multiple dimensions, such as a list of weblinks with urls, descriptions and hits, a table can be semantically correct.

 

Andy

 

Andrea Tarr

Tarr Consulting

 

www.tarrconsulting.com

 

---

From: joomla-...@googlegroups.com [mailto:joomla-...@googlegroups.com] On Behalf Of klas berlic
Sent: Thursday, June 04, 2009 12:26 PM
To: joomla-...@googlegroups.com
Subject: Re: xHTML Principles for Layout Development

 

a. Use tables to display relational information and do not use them

[Ian MacLennan]

Klas, I really think you are saying the same thing as was stated.

A list layout (i.e. a list of articles), would be relational data.

Ian

2009/6/4 klas berlič <klas....@gmail.com>

[Amy Stephen]

Yes, Ian, you are correct. We plan to use tables for the lists layouts since that is a presentation of relational information (i.e., rows and columns.)

We promise not to be trendy. If we were, we'd toss a little mashup in there or something. Div's are hardly a new fashion statement today. ;-)

2009/6/4 Ian MacLennan <ianl...@gmail.com>

[klas berlič]

What I was trying to say was not that div's are anything new, but that the notion of tables being all bad has become something like an undisputed urban myth. Glad that Joomla has not fallen for that.

2009/6/4 Amy Stephen <amyst...@gmail.com>

[Amy Stephen]

You are right, of course, Klas. Just teasin' ya. Andrew has already
threatened to stomp on our feet if we weren't sensible. That isn't too
concerning to me since he lives halfway around the world, but I
suppose he could hire it out, if necessary.

Thanks for staying involved. We hope to have layouts in Alpha. Since
we are changing classes, etc., we will need people to look very
closely and offer corrective feedback. Hope you are able to help with
that. We need lots of eyes.

[Compass]

> 9. Consideration of search engines optimization principles
> - would like advice from SEO folks

> 4.      An SEO person to fill details of #9.

Ultimately, what is good for accessibility, is good for usability, is
good for SEO
See:
http://www.compassdesigns.net/tutorials/55-usability-accessibility-web-standards-seo.html

In other words, with the framework you have articulated, the output
would be a strong foundation for SEO

[Amy Stephen]

Thanks Barrie - we are hoping also for some direction on Heading structures to use, as well. If you have input on Blog, Article, Module heading tags, we'd like to see some of our SEO folks provide input. (And, of course, any thing that should be considered now.)

[Compass]

Search engine are more sophisticated now and all the Hx stuff is
devalued. I'd focus on being as semantic as you can and the SE's will
credit that organizational structure appropriately.

[mic]

Just one question (i know this is maybe very late, but better now than
never).
Went through all posting, my resume is you are talking about the
frontend only.

Right?

If, what about the backend?
Actually (for example) the backend is worth.
Take a look at the toolbar which is producing one error after error.
The code is producing empty >spans> whre nothing is to show.

Should that (backend) not to be considered in having also valid code
(output)?

thx
michael

[Amy Stephen]

Actually, Andy's SOC project focuses on the Administrator. In 1.6, we should have nice, semantic HTML in both environments.

I think that is going to rock!

[Jeremy]

I like the list, and am not one to report on mobile or SEO that much.
I think #2 was improved and I don't think I disagree with anything
there. Thanks for taking that list and really making it usable.

On Jun 8, 7:21 pm, Amy Stephen <amystep...@gmail.com> wrote:
> Actually, Andy's SOC project focuses on the Administrator. In 1.6, we should
> have nice, semantic HTML in both environments.
>
> I think that is going to rock!
>

[Andrea Tarr at Tarr Consulting]

Four of us (Jen Kramer, Barb Ackerman, Meg McCarty and myself) got together to do some coding based on the principles. As was only to be expected, it took us most of the time just assimilating the principles and looking at how they applied to the existing core templates in Snowflake. We didn’t get to a point where it was workable to bring in remote players, so it remained local. I was sorry about that, but there has been a suggestion we do it again next Wednesday afternoon (before our Joomla users group meeting).

 

The views we looked at most closely were the Content-Articles (default & edit), Content-Category Blog, Content-Category List. For the most part, we had few changes to make.

 

The files had 2 container divs, the outer with class “joomla”, a space, then the pageclass suffix, the inner with a class of the view (i.e. “article” or “cat-bg”). We consolidated that to one div and dropped the joomla class and the space before the pageclass suffix. We thought that if people needed to know it was Joomla then they could add the div in the template. We like the idea of the pageclass being a separate class (with the space), but the same thing can be accomplished by starting the pageclass suffix with a space and that allows you to also use pageclass suffix as a true suffix if you need to.

 

We also changed the class “headliner” to “titleblock” because that seemed a clearer indication of what it was.

 

We changed the class “postmeta” to “iteminfo” again, for clarity.

 

On the Category List we added thead/tbody and removed the align & width style attributes and put in individual classes instead so that could be done in CSS instead of in the HTML. *** Implications *** To do this properly semantically we need to give each of the table columns a different class so the widths can be individually done in CSS. That adds a lot of classes to the CSS. It also has implications for 3 rd party developers because they would need to had new classes with CSS that might not be in the regular template. Another option would be to assign classes of width-5, width-10, width-20, width-25, width-40, width-45, width-50, width-60, width-100 which could be preset up in the CSS allowing the 3PD extensions to slip in easily. Comments?

 

We added scope to the table.

 

We added a header for the filters and labels to the filters.

 

On Amy’s suggestion I’ve created sample wireframes for two of the screens (Article and Category Blog) which show the structure & class/id. I’ll add those .png files to the files at the end of the discussion list.

 

The new forms engine still has to be implemented. We didn’t try to tackle that.

 

*** Nested Category behavior questions ***

The old section code was still in place. We didn’t attempt to change it because we weren’t sure how the behavior should work. With a Section/Category you had limited options. Show the whole section or show only a specific category. With nested categories what do you do about grandchildren? Can you attach articles to all levels of categories or only the bottom most level? What if a category has both articles and sub categories?

 

Thanks,

Andy

 

 

Andrea Tarr

www.tarrconsulting.com

 

-----Original Message-----
From: joomla-...@googlegroups.com [mailto:joomla-...@googlegroups.com] On Behalf Of Jeremy
Sent: Tuesday, June 09, 2009 6:01 AM
To: Joomla! CMS Development

Subject: Re: xHTML Principles for Layout Development

 

 

I like the list, and am not one to report on mobile or SEO that much.

[Angie Radtke]

Hi Andrea,

 

I took a look at  the blog.png  and have some ideas to make the styling more flexible.

It could be possible that I didn't understand your concept right .

 

It's possible to select more than two columns over the menu. 

You add the classes for the width dynamically ( 100% /count column ), right?

The second one is the float class.

 So, imagine you choose 4 columns.

The first 3 should have the same width , the last one should  be bigger.

So with your classes it isn't easy to build it up with  CSS.

My suggestion is to count the columns and add the class dynamically like I did in beez

 

class=" column".<? php echo colcount ; ?>"

 

Sometimes  it's necessary to float some of the colums left , and one right, so you can  override the float class with the columncount.

Designers sometimes like to style the first row in another way  than the second one , so we need the possibility to do that.

So I would  suggest  to count the columns and add the class in the same way like the colcount.

 

 In your  wireframe I couldn't find the seperator .

 We can clear floats, if we choose overflow : hidden for the standardconform browsers and display: inline-block for the IE6.

 The inline-block is sometimes buggy , so we should discuss if we should add  seperator divs to clear the floats.

 

 

My opinion about the class names is to find a good way between the old class names and new names which explain the meaning.

 

Bye Angie

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ausdrucks | STARK
Büro für Kommunikation Angie Radtke
www.der-auftritt.de
Witterschlicker Allee 52    53125 Bonn
0228/6420467   Mail:a.ra...@derauftritt.de
-----------------------------------------------------------------------
Barrierefreies Webdesign
von Angie Radtke und Dr. Michael Charlier
ISBN: 3-8273-2379-7

[Andrea Tarr]

I like the idea of switching to the beez method of creating the
columns. It gives you styling options that the other method doesn't.
Is there anyone out there that would have a problem if we made that
change?

Along the same lines, are there any specific suggestions, for or
against, on the class name changes that we did?

Thanks,
Andy

On Jun 12, 2:55 am, "Angie Radtke" <a.rad...@derauftritt.de> wrote:
> Hi Andrea,
>
> I took a look at  the blog.png  and have some ideas to make the styling more flexible.
> It could be possible that I didn't understand your concept right .
>
> It's possible to select more than two columns over the menu.
> You add the classes for the width dynamically ( 100% /count column ), right?
> The second one is the float class.
>  So, imagine you choose 4 columns.
> The first 3 should have the same width , the last one should  be bigger.
> So with your classes it isn't easy to build it up with  CSS.
> My suggestion is to count the columns and add the class dynamically like I did in beez
>
> class=" column".<? php echo colcount ; ?>"
>
> Sometimes  it's necessary to float some of the colums left , and one right, so you can  override the float class with the columncount.
> Designers sometimes like to style the first row in another way  than the second one , so we need the possibility to do that.
> So I would  suggest  to count the columns and add the class in the same way like the colcount.
>
>  In your  wireframe I couldn't find the seperator .
>  We can clear floats, if we choose overflow : hidden for the standardconform browsers and display: inline-block for the IE6.
>  The inline-block is sometimes buggy , so we should discuss if we should add  seperator divs to clear the floats.
>
> My opinion about the class names is to find a good way between the old class names and new names which explain the meaning.
>
> Bye Angie
>
> ausdrucks | STARK
> Büro für Kommunikation Angie Radtkewww.der-auftritt.de
> Witterschlicker Allee 52    53125 Bonn

> 0228/6420467   Mail:a.rad...@derauftritt.de

[Amy Stephen]

Comments below.

Please go ahead and commit your changes to Snowflake. Very good and thorough and thoughtful work. Appreciate you guys doing this. Documenting those issues must have taken some time. The wireframes will be very helpful to people.

I would like to work on this over the weekend, too. Where should I start? Any preferences for me to jump in?

Thanks very much!

On Thu, Jun 11, 2009 at 11:34 AM, Andrea Tarr at Tarr Consulting <at...@tarrconsulting.com> wrote:

Four of us (Jen Kramer, Barb Ackerman, Meg McCarty and myself) got together to do some coding based on the principles. As was only to be expected, it took us most of the time just assimilating the principles and looking at how they applied to the existing core templates in Snowflake. We didn’t get to a point where it was workable to bring in remote players, so it remained local. I was sorry about that, but there has been a suggestion we do it again next Wednesday afternoon (before our Joomla users group meeting).

Thank you guys very much. Will try to save next Wednesday afternoon.

 

 

The views we looked at most closely were the Content-Articles (default & edit), Content-Category Blog, Content-Category List. For the most part, we had few changes to make.

 

The files had 2 container divs, the outer with class “joomla”, a space, then the pageclass suffix, the inner with a class of the view (i.e. “article” or “cat-bg”). We consolidated that to one div and dropped the joomla class and the space before the pageclass suffix. We thought that if people needed to know it was Joomla then they could add the div in the template. We like the idea of the pageclass being a separate class (with the space), but the same thing can be accomplished by starting the pageclass suffix with a space and that allows you to also use pageclass suffix as a true suffix if you need to.

Yes on dropping the Joomla! class - and the space.

What is cat-bg? category-blog? if so, recommend "blog"
 

 

We also changed the class “headliner” to “titleblock” because that seemed a clearer indication of what it was.

ok

 

We changed the class “postmeta” to “iteminfo” again, for clarity.

ok

 

On the Category List we added thead/tbody and removed the align & width style attributes and put in individual classes instead so that could be done in CSS instead of in the HTML. *** Implications *** To do this properly semantically we need to give each of the table columns a different class so the widths can be individually done in CSS. That adds a lot of classes to the CSS. It also has implications for 3 rd party developers because they would need to had new classes with CSS that might not be in the regular template. Another option would be to assign classes of width-5, width-10, width-20, width-25, width-40, width-45, width-50, width-60, width-100 which could be preset up in the CSS allowing the 3PD extensions to slip in easily. Comments?

I would go with the second option, the presets. It's always possible if more sensitivity is needed to do overrides. I think the presents are flexible, reasonable solution.
 

 

We added scope to the table.

OK

 

We added a header for the filters and labels to the filters.

Good

 

On Amy’s suggestion I’ve created sample wireframes for two of the screens (Article and Category Blog) which show the structure & class/id. I’ll add those .png files to the files at the end of the discussion list.

Very nice, thank you!

 

The new forms engine still has to be implemented. We didn’t try to tackle that.

So, will all forms change? I guess I am very fuzzy on what is going on with the forms engine.

 

*** Nested Category behavior questions ***

The old section code was still in place. We didn’t attempt to change it because we weren’t sure how the behavior should work. With a Section/Category you had limited options. Show the whole section or show only a specific category.

Sections are going away.
 

With nested categories what do you do about grandchildren? Can you attach articles to all levels of categories or only the bottom most level?

All levels can have articles.
 

What if a category has both articles and sub categories?

So, it sounds like we need to talk to the dev involved and see where that is at. Andrew mentioned that later next week he will be in the frontend. Wonder if it's to add nested categories?

[Amy Stephen]

On Fri, Jun 12, 2009 at 10:22 AM, Andrea Tarr <at...@tarrconsulting.com> wrote:

I like the idea of switching to the beez method of creating the
columns. It gives you styling options that the other method doesn't.
Is there anyone out there that would have a problem if we made that
change?

No problem here. Column treatment Angie is proposing sounds reasonable.
 

Along the same lines, are there any specific suggestions, for or
against, on the class name changes that we did?

Commented - looked thru what was there and your notes were very precise. You guys do excellent work. Thank you.
 

[Amy Stephen]

On Fri, Jun 12, 2009 at 1:55 AM, Angie Radtke <a.ra...@derauftritt.de> wrote:

 

Sometimes  it's necessary to float some of the colums left , and one right, so you can  override the float class with the columncount.

Designers sometimes like to style the first row in another way  than the second one , so we need the possibility to do that.

So I would  suggest  to count the columns and add the class in the same way like the colcount.

Angie - the default_items template already has:

    <tr class="<?php if ($item->odd) { echo 'even'; } else { echo 'odd'; } ?>">

That should take care of the need for alternate row styling, do you agree?

 

 

 In your  wireframe I couldn't find the seperator .

Looking at the blog_item template, I agree, Angie, I think the article separator is missing. Andy? Do you agree?

 

 We can clear floats, if we choose overflow : hidden for the standardconform browsers and display: inline-block for the IE6.

 The inline-block is sometimes buggy , so we should discuss if we should add  seperator divs to clear the floats.

 

 

My opinion about the class names is to find a good way between the old class names and new names which explain the meaning.

We should provide a crosswalk with the documentation. Good point.
 

[Angie Radtke]

    <tr class="<?php if ($item->odd) { echo 'even'; } else { echo 'odd'; } ?>">

 

 

That way gives us only to various classes odd and even .

 

Bye Angie

[G. D. Speer]

All sounds good except the not-so-semantic treatment of table columns.  I would think sequentially numbering them with a class of col01 col02 col03 etc. would give all the selectors needed to create very specific rules.

#mydatatable .col01 {....   I really don't like the non-semantic width-20 approach.  It's why the SASS versions of the various grids are becomming popular. 

Duke

----- Original Message -----

From: Andrea Tarr at Tarr Consulting

To: joomla-...@googlegroups.com

---

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.63/2169 - Release Date: 06/11/09 05:53:00

[Angie Radtke]

 

 

Hi Amy,

Sorry, I forgot to say that's the wrong file, we talked about  blog.php and blog_item.

The other one is needed for the table -style.

 

bye Angie

 

 

[Andrea Tarr]

Ok, I made some changes to the Articles & Category Blog diagrams &
added Category List (see the files in google groups). I changed the
multi-column treatment to mimic closer to the beez style (which gets
rid of the width-stuff) and changed some class names (i.e. item-bg to
blog-item) so they are clearer or so they use a similar nomenclature.

I've also started a spreadsheet of class/id names. Somehow it's much
easier to see inconsistencies when they are all listed together. I've
put some of the old names as cross reference, but it's incomplete. :-)
Feel free to make comments and suggestions. I'm using some of the beez
names, but replacing the underscore with a dash, since that's the
style we are going to be using. I can see some potential for
frustration there because they are easy to confuse.

http://spreadsheets.google.com/ccc?key=rVJfQL7ZLcBvnPMyNt4-jRg

Andy

[Amy Stephen]

Duke -

I hear your point. I personally like grids, but that approach is difficult in this case since it would force a physical dimension on the column width in the HTML.

What other ideas do you have, other than a grid?

Thanks for your guidance!
Amy

[Andrea Tarr at Tarr Consulting]

Duke, could you look at the new version I put up and see if that will cover your concerns?

 

Thanks!

Andy

 

Andrea Tarr

www.tarrconsulting.com

 

---

[Andrea Tarr at Tarr Consulting]

Angie,

 

I got a little lost in the discussion of columns and rows. Can you look at the new diagrams and see if they look ok? In the blog layout we now have the column class and the total number of classes along with the separators. Should we have row information as well, or is that just needed on the Category list table?

 

Thanks!

Andy

 

Andrea Tarr

www.tarrconsulting.com

 

---

From: joomla-...@googlegroups.com [mailto:joomla-...@googlegroups.com] On Behalf Of Amy Stephen

Sent: Friday, June 12, 2009 7:38 PM
To: joomla-...@googlegroups.com

[Amy Stephen]

Snowflake was refreshed for 1.6 and has the new layouts back in place.

I will throw together the beginnings of a blank template and upload that, too.

Thanks!

[Andrea Tarr]

I've updated the spreadsheet with all the layout files across the top
row. If you are checking layout files out of Snowflake and want to
avoid duplicating work, go into the spreadsheet and put your name on
the "Working on:" row.

Here's the link again: http://spreadsheets.google.com/ccc?key=rVJfQL7ZLcBvnPMyNt4-jRg

I believe they are planning to redo the forms with the new forms
engine, so I'd do those last...


Andy


On Jun 12, 7:45 pm, "Andrea Tarr at Tarr Consulting"

<at...@tarrconsulting.com> wrote:
> Angie,
>
> I got a little lost in the discussion of columns and rows. Can you look at
> the new diagrams and see if they look ok? In the blog layout we now have the
> column class and the total number of classes along with the separators.
> Should we have row information as well, or is that just needed on the
> Category list table?
>
> Thanks!
>
> Andy
>
> Andrea Tarr
>
> www.tarrconsulting.com
>
>   _____  
>

> From: joomla-...@googlegroups.com
> [mailto:joomla-...@googlegroups.com] On Behalf Of Amy Stephen
> Sent: Friday, June 12, 2009 7:38 PM
> To: joomla-...@googlegroups.com
> Subject: Re: xHTML Principles for Layout Development
>
> Duke -
>
> I hear your point. I personally like grids, but that approach is difficult
> in this case since it would force a physical dimension on the column width
> in the HTML.
>
> What other ideas do you have, other than a grid?
>
> Thanks for your guidance!
> Amy
>
> On Fri, Jun 12, 2009 at 12:04 PM, G. D. Speer <gsp...@cortech.org> wrote:
>
> All sounds good except the not-so-semantic treatment of table columns.  I
> would think sequentially numbering them with a class of col01 col02 col03
> etc. would give all the selectors needed to create very specific rules.
>
> #mydatatable .col01 {....   I really don't like the non-semantic width-20
> approach.  It's why the SASS versions of the various grids are becomming
> popular.
>
> Duke
>
> ----- Original Message -----
>

[G. D. Speer]

Hi Amy -

 

Perhaps I wasn't clear.  I prefer to use a grid system, but my point was to try to avoid having any of the usual grid-like classes in the default markup or anything suggesting widths.  So, I was specifically discouraging use of .width-40 or .span-12 as these do suggest a grid and result in non-semantic class names suggesting dimensions into the html.

 

Instead, I was suggesting simply numbering the columns as they are rendered - .C01, .C02, .C03 or .Col01, .Col02, Col03, .Col04.  Combined with a class suffix for the table, it allows as generic or as granular of CSS selectors as are needed by the end designer.  No suggestion of display width in the HTML.  It is the most accessible generic naming convention we could use without making it content-specific.  It's also considered an appropriate technique for WCAG/508 compliance.

 

In the CSS, these selectors can be left unset and allowed to auto-fit the content, be hand sized, or a grid system could be applied.

 

As for rows, even-odd is fine; but columns usually need column-specific styling to match the content.

 

Is this making sense?

 

Also, came across this a couple weeks ago and it seems to work perfectly ...

Minimizes HTTP requests, still works when JS is unavailable, works well with Blueprint on Sass.

What do you think?

http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ 

 

@Andy - Took a look at the spreadsheet - looks well thought out.

  Didn't spot any other issues.

 

 

 

Thank you!

Duke

 

Version: 8.5.339 / Virus Database: 270.12.65/2171 - Release Date: 06/12/09 05:55:00

[Angie Radtke]

Andrea ,

 

can you send me the editable png-file , so it's more easy for me to add my changes ?

 

Thanks Angie

 

ausdrucks | STARK
Büro für Kommunikation Angie Radtke
www.der-auftritt.de
Witterschlicker Allee 52    53125 Bonn
0228/6420467   Mail:a.ra...@derauftritt.de
-----------------------------------------------------------------------
Barrierefreies Webdesign
von Angie Radtke und Dr. Michael Charlier
ISBN: 3-8273-2379-7

[Amy Stephen]

On Sat, Jun 13, 2009 at 3:13 AM, G. D. Speer <gsp...@cortech.org> wrote:

Hi Amy -

 

Perhaps I wasn't clear.  I prefer to use a grid system, but my point was to try to avoid having any of the usual grid-like classes in the default markup or anything suggesting widths.  So, I was specifically discouraging use of .width-40 or .span-12 as these do suggest a grid and result in non-semantic class names suggesting dimensions into the html.

After responding, it dawned on me that is what you meant.
 

 

Instead, I was suggesting simply numbering the columns as they are rendered - .C01, .C02, .C03 or .Col01, .Col02, Col03, .Col04.  Combined with a class suffix for the table, it allows as generic or as granular of CSS selectors as are needed by the end designer.  No suggestion of display width in the HTML.  It is the most accessible generic naming convention we could use without making it content-specific.  It's also considered an appropriate technique for WCAG/508 compliance.
 

 

In the CSS, these selectors can be left unset and allowed to auto-fit the content, be hand sized, or a grid system could be applied.

 

As for rows, even-odd is fine; but columns usually need column-specific styling to match the content.

 

Is this making sense?

Yes, I agree, that is much better. An important factor is that it can auto-fit the content, and therefore be ignored (thinking ease of use for some.) Combined, the table class suffix and the generic column numbers gives designers precision needed. I think what you are proposing is the way to go.

Andy? Angie?
 

 

Also, came across this a couple weeks ago and it seems to work perfectly ...

Minimizes HTTP requests, still works when JS is unavailable, works well with Blueprint on Sass.

What do you think?

http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ 

 

Interesting approach. At this point, we are not looking at CSS. That could be a good method for the template.

Do you want to help with the xHTML layouts? If so, do you have a JoomlaCode ID? If you let me know what that ID is, I will add you to the Snowflake project. You sound very talented here and we would welcome *even more* of your help!

Thanks!

 

[Amy Stephen]

Angie -

There is only one specific question, I think.

I am understanding you to say that you would like a "row sequence number" on table rows, in addition to the "even" or "odd" class.

So, it would be class="row01 odd" and class="row02 even" and class="row03 odd".

Is that correct? If not, then, we probably should have you sketch it out.

Thanks for all of your help, Angie.

Amy

[G. D. Speer]

Would you mind sending the file along so I may do the same?

 

Version: 8.5.339 / Virus Database: 270.12.66/2172 - Release Date: 06/12/09 17:56:00

[Andrea Tarr at Tarr Consulting]

It’s not an editable png file. I created it using a free collaborative wireframing web service called gliffy.com. I’ll post them as .svg files which can be edited in Adobe Illustrator. I could also set up people as collaborators on the gliffy site.

 

Andrea Tarr

www.tarrconsulting.com

 

---

<BR

[Andrea Tarr at Tarr Consulting]

Will the .svg file work for you? If so, I just added them to the files on the google groups site.

 

Andrea Tarr

www.tarrconsulting.com

 

---

<BR

[G. D. Speer]

Happy to help - I'll contact you offlist.

 

Re: adding row numbering to even/odd - .Row05 odd

That one has me scratching my head just a bit.  The obvious good is that it gives 100% style control to the CSS designer without having to change the generated markup.  On a multi-table page evey cell shape can be precisely sized.  The bad is the extra page weight from accomodating varying row heights in the same table - the markup gets noisy.  I'm not envisioning a use case that causes Row86 to be sized differently from those that came before, but just because I can't think of one ...  I believe you previously decided to not class <td>'s and I wholeheartedly agree.

 

Having thought about it, I'm now leaning toward erring on the side of a more complete markup (even though there are few uses) as the most technically elegant result.

 

Duke

Version: 8.5.339 / Virus Database: 270.12.67/2173 - Release Date: 06/13/09 05:53:00

[G. D. Speer]

Unfamiliar with gliffy, but happy to take the collaborator approach or use an .svg - whichever is best for the group.

Duke

[Andrea Tarr at Tarr Consulting]

To sign on as a collaborator, I need to give your email address to gliffy.com who will email you with instructions on how to set up a free account. They set you up as a 30 day trial for the premium account which will automatically convert to a basic account at expiration. It’s a bit clumsy, but seems to work ok. I actually think it would have been quicker and easier in Photoshop J If anyone knows of better software out there, let me know, especially if it could legibly create it automatically.

 

So let me know if you are ok with me using your email. Otherwise, you can just use the .svg files.

 

Andy

 

Andrea Tarr

www.tarrconsulting.com

 

---

[G. D. Speer]

Responding OFFLIST - thanks

[G. D. Speer]

Gliffy account created and ready for collaboration.