9 Sep
2009
9 Sep
'09
2:51 p.m.
On Sep 9, 2009, at 13:58, Vincent Massol wrote:
On Sep 9, 2009, at 1:28 PM, Denis Gervalle wrote:
Well, I agree but removing the duplicate is obviously always a good
choice, no ?
On Sep 9, 2009, at 12:28, Vincent Massol wrote:
Good point re behavior when titles are empty. However this doesn't
change the need to have a compatibility flag to decide what to do when
title is set and level1 header is set with the same value.
On Sep 9, 2009, at 9:16 AM, Denis Gervalle wrote:
Sure but this means that a title has been specified !
My question was, do we have a case where there is nothing in the
title
fields and the first H1 of the document should not be considered as
the true title of the document ?
My proposal has the effect of avoiding empty title and building them
based on the WYSIWYG. Isolating title in a specific field is for me
more an implementation issue than a user issue. Having title stored
separately from the content of the document is useful for reusing it
in head section, linking and navigation, not for enhancing the
experience of the user during edition.
My solution has the side effect to avoid compatible mode, since it
does not change the behavior from the user point of view.
Do you better understand my proposal now ?
On Sep 8, 2009, at 14:48, Vincent Massol wrote:
> Hi everyone,
>
> With Colibri we've started to display the doc title as the
> document's
> rendered title. This is a big change that not only affects Colibri
> but
> in general the way people write documents.
>
> Here's what I suggest:
>
> 1) Display doc titles with <div>
title should be in H1 to comply with WAI.
> 2) Display document content headers using <h1>-<h6>
> 3) Display doc titles with a larger font size than h1 (or h1
> with a
> smaller font size)
> 4) Force cursor to be in the title field when editing a new
> document.
> Force cursor in the content field when editing an existing
> document.
> This is to make it easy using the keyboard only to enter doc
> titles
> (since it's currently dead easy, we need something close in
> easiness)
> 5) Modify all our existing skins: Toucan, Albatross, Finch and
> Dodo
> so
> that they use they display the doc title, similarly to Colibri
> 6) Have a title compatibility flag in xwiki.cfg. When active,
> use a
> Javascript to do this: if there's no title specified for a page
> and
> if
> the first content is a H1 then use it as the page's title.
>
> We need at least 1), 3), 6) to be able to release the Colibri skin
> for
> 2.0 final IMO.
>
> WDYT?
>
I wonder if "compatibility mode" is really required. This may add
complexity for the end user wihtout real benefit IMO. Is there
really
a case where a document has a first = ... = that is not the title
of
the document when no title has been explicitly specified ?
There is such a case: if someone uses the same header1 content as
the
title it should be displayed. Not doing so would be a bug.
Re empty title behavior we have 2 choices I think:
1) Leave as it is now, i.e. use getDisplayTitle()
2) Make the title mandatory, set it by default to the page name when
creating a page and refuse to save the page if the title is not set
Why not 3), fill the title property with the first = ... = when
possible ?
I also think 1) is best for now since this solves
issues with existing
content with no titles.
The main issue with displayTitle is a really heavy process. When you
use it in navigation panels, this is really a problem. Preprocessing
what displayTitle does into the title property is almost what I suggest.
Currently the title property is inaccessible without instantiating the
document, but this could be changed. We have written a navigation
panel in Groovy recently using direct SQL, and it perform quite well
compare to the native navigation, with the benefit of having meaning
full document link based on titles.
Note that since the title is used in head and could be used in
document links, means it should remain short. Does not this also
suggest that displaying the title at the top of the document does not
permit the document to have a larger title.
May be the duplicate of a title and a starting = ... = even with a
different text is not good as well.
Why not a rules saying: do not put document title if document start
with a = .. = ?
This general rule would avoid the compat flag, that I feel could
complexity any further evolution of the title behavior.
Denis
Have I understood your point?
Thanks
-Vincent
>> If there is no such case, why not use a
behavior like these ones:
>>
>> 1) When editing a document, if no title is specified and first node
>> is
>> a = ... =, use that node as the title and store its value in the
>> title
>> field.
>> Option A: Leave the title in = ... = as well and avoid duplication
>> on
>> display.
>> Option B: Remove the = ... = from the document.
>> B1: in WYSIWYG, completely get rid of the title field, title
>> being
>> edited in the first = ... =, this would be more simple and more
>> WYSIWYG and avoid 4)
>>
>> 2) For fixing old documents (without messing up new one):
>> Option A: When displaying/editing a document without title and a
>> first = ... = is available, do what 1) shoud have already done
>> before
>> proceeding
>> Option B: When migrating the database, ensure that all titles
>> are properly stored as it should have been.
>>
>> For providing navigation, title is really important to be easily
>> accessible in the storage, but from the user point of view I feel
>> that
>> the title of a document is just the first = ... =. I usually forget
>> to
>> precise a title in my document, I never omit involuntarily to put
>> an
>> initial = ... =.
>>
>> Hope this helps,
>>
>> Denis Gervalle
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs