8 Sep
2009
8 Sep
'09
2:48 p.m.
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>
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?
Thanks
-Vincent
8 Sep
8 Sep
3:06 p.m.
On Tue, Sep 8, 2009 at 14:48, Vincent Massol<vincent(a)massol.net> 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>
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)
+1 for all (i'm not sure for div since i'm not an html expert but the
important point is that the page title and first level headers should
have different style for sure)
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
+1, as you says it's a totally new way of seeing document content so
it should be applied to all skins.
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.
Is the h1 hidden in this case ?
7) make the toc macro start at first header level instead of second
We need at least 1), 3), 6) to be able to release the Colibri skin for
2.0 final IMO.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
7:31 p.m.
On Sep 8, 2009, at 3:06 PM, Thomas Mortagne wrote:
On Tue, Sep 8, 2009 at 14:48, Vincent
Massol<vincent(a)massol.net>
wrote:
Note that we can change the toc to display the first level all the
time since that will only add the document's title for those in
backward compat mode.
-Vincent
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>
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)
+1 for all (i'm not sure for div since i'm not an html expert but the
important point is that the page title and first level headers should
have different style for sure)
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
+1, as you says it's a totally new way of seeing document content so
it should be applied to all skins.
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.
Is the h1 hidden in this case ?
7) make the toc macro start at first header level instead of second > We need at least 1), 3), 6) to be able to release
the Colibri skin
> for
> 2.0 final IMO.
>
> WDYT?
>
> Thanks
> -Vincent
7:31 p.m.
On Tue, Sep 8, 2009 at 15:06, Thomas Mortagne<thomas.mortagne(a)xwiki.com> wrote:
On Tue, Sep 8, 2009 at 14:48, Vincent
Massol<vincent(a)massol.net> wrote:
Also this should be off by default since it's backward compatibility
and a wrong behavior in a normal new wiki.
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>
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)
+1 for all (i'm not sure for div since i'm not an html expert but the
important point is that the page title and first level headers should
have different style for sure)
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
+1, as you says it's a totally new way of seeing document content so
it should be applied to all skins.
> 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.
Is the h1 hidden in this case ?
7) make the toc macro start at first header level instead of second
--
Thomas Mortagne
We need at least 1), 3), 6) to be able to release the Colibri skin for
2.0 final IMO.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
9 Sep
9 Sep
9:06 a.m.
On Sep 8, 2009, at 7:31 PM, Thomas Mortagne wrote:
On Tue, Sep 8, 2009 at 15:06, Thomas
Mortagne<thomas.mortagne(a)xwiki.com
There's one remaining problem Thomas with this: the default XAR will
not display properly. We would need to have 2 XARs for this to work:
one for backward compat and a new one, using titles. And this is a
pain to do IMO.
We don't want a new user to start XE and find that all titles are
duplicated by default with a clean wiki he hasn't touched.
WDYT?
Thanks
-Vincent
wrote:
On Tue, Sep 8, 2009 at 14:48, Vincent Massol<vincent(a)massol.net>
wrote:
Also this should be off by default since it's backward compatibility
and a wrong behavior in a normal new wiki. 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>
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)
+1 for all (i'm not sure for div since i'm not an html expert but the
important point is that the page title and first level headers should
have different style for sure)
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
+1, as you says it's a totally new way of seeing document content so
it should be applied to all skins.
> 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. > Is the h1 hidden in this case ?
>
> 7) make the toc macro start at first header level instead of second
>
>>
>> We need at least 1), 3), 6) to be able to release the Colibri skin
>> for
>> 2.0 final IMO.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
10:48 a.m.
On Wed, Sep 9, 2009 at 09:06, Vincent Massol<vincent(a)massol.net> wrote:
On Sep 8, 2009, at 7:31 PM, Thomas Mortagne wrote:
We are not supposed to do backward compatibility on what we are
releasing... if XE is wrong for 2.0 it should be fixed.
On Tue, Sep 8, 2009 at 15:06, Thomas
Mortagne<thomas.mortagne(a)xwiki.com
There's one remaining problem Thomas with this: the default XAR will
not display properly. We would need to have 2 XARs for this to work:
one for backward compat and a new one, using titles. And this is a
pain to do IMO.
We don't want a new user to start XE and find that all titles are
duplicated by default with a clean wiki he hasn't touched.
WDYT? wrote:
On Tue, Sep 8, 2009 at 14:48, Vincent Massol<vincent(a)massol.net>
wrote:
Also this should be off by default since it's backward compatibility
and a wrong behavior in a normal new wiki. 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>
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)
+1 for all (i'm not sure for div since i'm not an html expert but the
important point is that the page title and first level headers should
have different style for sure)
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
+1, as you says it's a totally new way of seeing document content so
it should be applied to all skins.
> 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.
Thanks
-Vincent
--
Thomas Mortagne
> Is the h1 hidden in this case ?
>
> 7) make the toc macro start at first header level instead of second
>
>>
>> We need at least 1), 3), 6) to be able to release the Colibri skin
>> for
>> 2.0 final IMO.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:52 a.m.
On Sep 9, 2009, at 10:48 AM, Thomas Mortagne wrote:
On Wed, Sep 9, 2009 at 09:06, Vincent
Massol<vincent(a)massol.net>
wrote:
I don't agree. This would mean someone using 2.0 with Toucan couldn't
upgrade their XAR with the new stuff.
-Vincent
On Sep 8, 2009, at 7:31 PM, Thomas Mortagne wrote:
We are not supposed to do backward compatibility on what we are
releasing... if XE is wrong for 2.0 it should be fixed. On Tue, Sep 8, 2009 at 15:06, Thomas
Mortagne<thomas.mortagne(a)xwiki.com
There's one remaining problem Thomas with this: the default XAR will
not display properly. We would need to have 2 XARs for this to work:
one for backward compat and a new one, using titles. And this is a
pain to do IMO.
We don't want a new user to start XE and find that all titles are
duplicated by default with a clean wiki he hasn't touched.
WDYT? wrote:
On Tue, Sep 8, 2009 at 14:48, Vincent Massol<vincent(a)massol.net>
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>
> 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)
+1 for all (i'm not sure for div since i'm not an html expert but
the
important point is that the page title and first level headers
should
have different style for sure)
> 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
+1, as you says it's a totally new way of seeing document content
so
it should be applied to all skins.
> 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.
Also this should be off by default since it's backward compatibility
and a wrong behavior in a normal new wiki. > Thanks
> -Vincent
>
>>> Is the h1 hidden in this case ?
>>>
>>> 7) make the toc macro start at first header level instead of second
>>>
>>>>
>>>> We need at least 1), 3), 6) to be able to release the Colibri skin
>>>> for
>>>> 2.0 final IMO.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
11:03 a.m.
On Wed, Sep 9, 2009 at 10:52, Vincent Massol<vincent(a)massol.net> wrote:
On Sep 9, 2009, at 10:48 AM, Thomas Mortagne wrote:
Sure if they use an old skin not made for the new rule I don't see how
it would work...
Don't mix everything, backward compatibility is one thing but if the
rule now is that a page is supposed to have a real title and use first
level header for this then the default XE should follow this rule...
since it's the rule.
On Wed, Sep 9, 2009 at 09:06, Vincent
Massol<vincent(a)massol.net>
wrote:
I don't agree. This would mean someone using 2.0 with Toucan couldn't
upgrade their XAR with the new stuff.
On Sep 8, 2009, at 7:31 PM, Thomas Mortagne wrote:
We are not supposed to do backward compatibility on what we are
releasing... if XE is wrong for 2.0 it should be fixed. On Tue, Sep 8, 2009 at 15:06, Thomas
Mortagne<thomas.mortagne(a)xwiki.com
> wrote:
> On Tue, Sep 8, 2009 at 14:48, Vincent Massol<vincent(a)massol.net>
> 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>
>> 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)
>
> +1 for all (i'm not sure for div since i'm not an html expert but
> the
> important point is that the page title and first level headers
> should
> have different style for sure)
>
>> 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
>
> +1, as you says it's a totally new way of seeing document content
> so
> it should be applied to all skins.
>
>> 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.
Also this should be off by default since it's backward compatibility
and a wrong behavior in a normal new wiki.
There's one remaining problem Thomas with this: the default XAR will
not display properly. We would need to have 2 XARs for this to work:
one for backward compat and a new one, using titles. And this is a
pain to do IMO.
We don't want a new user to start XE and find that all titles are
duplicated by default with a clean wiki he hasn't touched.
WDYT?
-Vincent
--
Thomas Mortagne
> Thanks
> -Vincent
>
>>> Is the h1 hidden in this case ?
>>>
>>> 7) make the toc macro start at first header level instead of second
>>>
>>>>
>>>> We need at least 1), 3), 6) to be able to release the Colibri skin
>>>> for
>>>> 2.0 final IMO.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:18 a.m.
On Sep 9, 2009, at 11:03 AM, Thomas Mortagne wrote:
On Wed, Sep 9, 2009 at 10:52, Vincent
Massol<vincent(a)massol.net>
wrote:
Well this means that we cannot release this without fixing all the
other skins (we cannot wait for a 2.0.1 to do that).
-Vincent
On Sep 9, 2009, at 10:48 AM, Thomas Mortagne wrote:
Sure if they use an old skin not made for the new rule I don't see how
it would work...
Don't mix everything, backward compatibility is one thing but if the
rule now is that a page is supposed to have a real title and use first
level header for this then the default XE should follow this rule...
since it's the rule. On Wed, Sep 9, 2009 at 09:06, Vincent
Massol<vincent(a)massol.net>
wrote:
I don't agree. This would mean someone using 2.0 with Toucan couldn't
upgrade their XAR with the new stuff.
On Sep 8, 2009, at 7:31 PM, Thomas Mortagne wrote:
> On Tue, Sep 8, 2009 at 15:06, Thomas Mortagne<thomas.mortagne(a)xwiki.com
>> wrote:
>> On Tue, Sep 8, 2009 at 14:48, Vincent Massol<vincent(a)massol.net>
>> 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>
>>> 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)
>>
>> +1 for all (i'm not sure for div since i'm not an html expert but
>> the
>> important point is that the page title and first level headers
>> should
>> have different style for sure)
>>
>>> 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
>>
>> +1, as you says it's a totally new way of seeing document content
>> so
>> it should be applied to all skins.
>>
>>> 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.
>
> Also this should be off by default since it's backward
> compatibility
> and a wrong behavior in a normal new wiki.
There's one remaining problem Thomas with this: the default XAR
will
not display properly. We would need to have 2 XARs for this to
work:
one for backward compat and a new one, using titles. And this is a
pain to do IMO.
We don't want a new user to start XE and find that all titles are
duplicated by default with a clean wiki he hasn't touched.
WDYT?
We are not supposed to do backward compatibility on what we are
releasing... if XE is wrong for 2.0 it should be fixed. > -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>> Is the h1 hidden in this case ?
>>>>>
>>>>> 7) make the toc macro start at first header level instead of
>>>>> second
>>>>>
>>>>>>
>>>>>> We need at least 1), 3), 6) to be able to release the Colibri
>>>>>> skin
>>>>>> for
>>>>>> 2.0 final IMO.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>
8 Sep
8 Sep
3:22 p.m.
1) Display doc titles with <div>
isn't H1 more semantically correct?
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)
This is not necessary. H1 means the first title in a document. The name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance as the
title), I should be able to do that.
The difference between the title and another H1 is the position in the
document (the title is always the first).
Representing the title as a H1 solves the 6) problem. Can you explain a user
why the first title is bigger on some pages, while on other pages(no title
specified), the title has the same size like other H1?
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)
+1
5) Modify all our existing skins: Toucan, Albatross,
Finch and Dodo so
that they use they display the doc title, similarly to Colibri
+1
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.
+1
We need at least 1), 3), 6) to be able to release the Colibri skin for
2.0 final IMO.
3:27 p.m.
Hi,
On Sep 8, 2009, at 3:22 PM, Ecaterina Valica wrote:
Maybe yes. It just looked strange to me to have 2 H1 but I'm ok with
whatever our HTML experts say :)
= header = generates a H1.
Thanks
-Vincent
1) Display doc
titles with <div>
isn't H1 more semantically correct? 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)
This is not necessary. H1 means the first title in a document. The
name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance as
the
title), I should be able to do that.
The difference between the title and another H1 is the position in the
document (the title is always the first).
Representing the title as a H1 solves the 6) problem. Can you
explain a user
why the first title is bigger on some pages, while on other pages(no
title
specified), the title has the same size like other H1? 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)
+1
5) Modify all our existing skins: Toucan,
Albatross, Finch and Dodo
so
that they use they display the doc title, similarly to Colibri
+1
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.
+1
>
> We need at least 1), 3), 6) to be able to release the Colibri skin
> for
> 2.0 final IMO.
3:50 p.m.
On Sep 8, 2009, at 3:27 PM, Vincent Massol wrote:
Hi,
On Sep 8, 2009, at 3:22 PM, Ecaterina Valica wrote:
Maybe yes. It just looked strange to me to have 2 H1 but I'm ok with
whatever our HTML experts say :)
= header = generates a H1.
The other option is to modify the renderers and the XHTML renderer in
particular so that = header= generate a H2 instead but this means:
- all skins must be modified as mentioned in 5)
- the wikimodel xwiki parser needs to be modified so that only up to 5
"=" symbols are supported since there's not H7
- verify other JS are not broken (like the JS for section edits for ex)
-Vincent
1)
Display doc titles with <div>
isn't H1 more semantically correct? 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)
This is not necessary. H1 means the first title in a document. The
name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance
as the
title), I should be able to do that.
The difference between the title and another H1 is the position in
the
document (the title is always the first).
Representing the title as a H1 solves the 6) problem. Can you
explain a user
why the first title is bigger on some pages, while on other
pages(no title
specified), the title has the same size like other H1? Thanks
-Vincent
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)
+1
5) Modify all our existing skins: Toucan,
Albatross, Finch and
Dodo so
that they use they display the doc title, similarly to Colibri
+1
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.
+1
>
> We need at least 1), 3), 6) to be able to release the Colibri skin
> for
> 2.0 final IMO.
3:52 p.m.
On Sep 8, 2009, at 3:50 PM, Vincent Massol wrote:
On Sep 8, 2009, at 3:27 PM, Vincent Massol wrote:
Note that this would also mean that when using the XWiki rendering
module standalone there's no way to generate a document's title.
<thomas>That's why I was asking the other day whether an onTitle()
event should be added or not to the Listener interface</thomas>
Thanks
-Vincent
Hi,
On Sep 8, 2009, at 3:22 PM, Ecaterina Valica wrote:
Maybe yes. It just looked strange to me to have 2 H1 but I'm ok
with whatever our HTML experts say :)
= header = generates a H1.
The other option is to modify the renderers and the XHTML renderer
in particular so that = header= generate a H2 instead but this means:
- all skins must be modified as mentioned in 5)
- the wikimodel xwiki parser needs to be modified so that only up to
5 "=" symbols are supported since there's not H7
- verify other JS are not broken (like the JS for section edits for
ex) 1)
Display doc titles with <div>
isn't H1 more semantically correct? 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)
This is not necessary. H1 means the first title in a document. The
name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance
as the
title), I should be able to do that.
The difference between the title and another H1 is the position in
the
document (the title is always the first).
Representing the title as a H1 solves the 6) problem. Can you
explain a user
why the first title is bigger on some pages, while on other
pages(no title
specified), the title has the same size like other H1? 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)
+1
5) Modify all our existing skins: Toucan,
Albatross, Finch and
Dodo so
that they use they display the doc title, similarly to Colibri
+1
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.
+1
>
> We need at least 1), 3), 6) to be able to release the Colibri
> skin for
> 2.0 final IMO. 
3:59 p.m.
Vincent Massol wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi,
On Sep 8, 2009, at 3:22 PM, Ecaterina Valica wrote:
Maybe yes. It just looked strange to me to have 2 H1 but I'm ok with
whatever our HTML experts say :)
Well, it is a little strange, because the title's H1 is "above" the first H1
in
the document (since all = headings = generate H1s).
However, a div is not semantic at all, better 2 H1s than a div.
1)
Display doc titles with <div>
isn't H1 more semantically correct?
>> 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)
>>
> This is not necessary. H1 means the first title in a document. The
> name of
> the document could be represented with H1.
> If me as a user, I want to have multiple H1 (with same importance as
> the
> title), I should be able to do that.
How about if I want to have none? why can't I have none? (I will automatically
get a title generated from the document's name).
Also, as I said, I think semantically the document title is more important than
all the other level 1 headings in it (a book's title is more important than any
of its chapters titles).
> The difference between the title and another H1 is
the position in the
> document (the title is always the first).
In this case, then why does the title have its own special input and so on? we
could just rely on an existing first heading level 1, in the content, or use the
document's name if none is set.
>
> Representing the title as a H1 solves the 6) problem. Can you
> explain a user
> why the first title is bigger on some pages, while on other pages(no
> title
> specified), the title has the same size like other H1?
good point.
= header = generates a H1.
?
Thanks
-Vincent
All in all, I find this one a very tricky one (from a semantic pov).
To fix it, we'd need to agree on the semantic of a document title (maybe I
missed some mails or chat discussions):
We know we want it in the breadcrumbs, browser window title, and now we also
want it represented (somehow) in the content. Does any document need a title
(unique toplevel name)? With these semantics, we should also define the
substitution rules: is a user inserted =heading 1= equivalent to a user inserted
title? or it's just the document name that can replace it?
how about:
6) no heading in the document replaces a document title, but upon save, a
document title, if missing, is generated from separating the page name camel
case in words.
just my first thoughts.
Happy hacking,
Anca
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)
+1
5) Modify all our existing skins: Toucan,
Albatross, Finch and Dodo
so
that they use they display the doc title, similarly to Colibri
+1
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.
+1
> We need at least 1), 3), 6) to be able to release the Colibri skin
> for
> 2.0 final IMO. 
3:57 p.m.
Hi!
Ecaterina Valica wrote:
May I disagree with this? I think that a given document has to have a
unique title. Another question is to decide if H1 could be used or not
to mark it. To my understanding, heading1 mark will be used for one or
several paragraphs used to head the first level of the hierarchical
structure of a document under its title.
I think we are messing here two different things: the html marking and
the description of the document structure. I agree with Vicent when he
says that a different HTML mark, no hx, must be used to render the
document title.
Thanks!
--
Ricardo RodrÃguez
Your EPEC Network ICT Team
1) Display doc
titles with <div>
isn't H1 more semantically correct?
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)
This is not necessary. H1 means the first title in a document. The name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance as the
title), I should be able to do that.
The difference between the title and another H1 is the position in the
document (the title is always the first).
4:02 p.m.
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi!
Ecaterina Valica wrote:
May I disagree with this? I think that a given document has to have a
unique title. Another question is to decide if H1 could be used or not
to mark it. To my understanding, heading1 mark will be used for one or
several paragraphs used to head the first level of the hierarchical
structure of a document under its title.
if "hierarchical structure under its title" semantic exists, then it means that
the title _has_ to be a hx (1, since it's toplevel), to have this semantic
correctly marked in html (a div won't do it, _at all_).
Thanks,
Anca
1)
Display doc titles with <div>
isn't H1 more semantically correct?
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)
This is not necessary. H1 means the first title in a document. The name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance as the
title), I should be able to do that.
The difference between the title and another H1 is the position in the
document (the title is always the first).
I think we are messing here two different things: the html marking and
the description of the document structure. I agree with Vicent when he
says that a different HTML mark, no hx, must be used to render the
document title.
Thanks!
9 Sep
9 Sep
12:38 p.m.
Hi Anca!
Anca Luca wrote:
if "hierarchical structure under its title"
semantic exists, then it means that
the title _has_ to be a hx (1, since it's toplevel), to have this semantic
correctly marked in html (a div won't do it, _at all_).
I am afraid once again I've posted without the required reflection. Or
at least without googling enough. I think I've find the place where your
have inspired to name of your blog!
http://www.h1debate.com/
This could be also interesting...
http://www.viget.com/inspire/ending-the-great-h1-debate/
Please, allow me to post these two links here for future reference. Thanks!
Greetings,
Ricardo
--
Ricardo RodrÃguez
Your EPEC Network ICT Team
8 Sep
8 Sep
4:13 p.m.
Ecaterina Valica wrote:
1) Display doc
titles with <div>
isn't H1 more semantically correct?
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)
This is not necessary. H1 means the first title in a document. The name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance as the
title), I should be able to do that. The difference between the title and another H1 is the
position in the
document (the title is always the first).
For me the title of a document is semantically "above" all headings
(including H1) found in the content so I think that it should be
displayed in a different way. I'm fine with using H1 for the title, but
with a different style.
IMO a content H1 can play the role of the document title only if:
* the title field is empty
* the H1 heading starts the document
* the document has only one H1 heading in the content
Using the H1 as document title can be confusing because of the section
editing icon which sometimes is around the title and sometimes it isn't.
Thanks,
Marius
Representing the title as a H1 solves the 6) problem. Can you explain a user
why the first title is bigger on some pages, while on other pages(no title
specified), the title has the same size like other H1?
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)
+1
5) Modify all our existing skins: Toucan,
Albatross, Finch and Dodo so
that they use they display the doc title, similarly to Colibri
+1
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.
+1
We need at least 1), 3), 6) to be able to release
the Colibri skin for
2.0 final IMO.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:18 p.m.
On Sep 8, 2009, at 3:22 PM, Ecaterina Valica wrote:
6) is not solved by this. We still need to convert existing document
content.
-Vincent
1) Display doc
titles with <div>
isn't H1 more semantically correct?
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)
This is not necessary. H1 means the first title in a document. The
name of
the document could be represented with H1.
If me as a user, I want to have multiple H1 (with same importance as
the
title), I should be able to do that.
The difference between the title and another H1 is the position in the
document (the title is always the first).
Representing the title as a H1 solves the 6) problem. Can you
explain a user
why the first title is bigger on some pages, while on other pages(no
title
specified), the title has the same size like other H1? 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)
+1
5) Modify all our existing skins: Toucan,
Albatross, Finch and Dodo
so
that they use they display the doc title, similarly to Colibri
+1
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.
+1
>
> We need at least 1), 3), 6) to be able to release the Colibri skin
> for
> 2.0 final IMO. 
5:28 p.m.
On Tue, Sep 8, 2009 at 2:48 PM, Vincent Massol <vincent(a)massol.net> 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>
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.
Why javascript? This can be easily done on the server side in velocity, by
looking into the string representing the rendered content.
We need at least 1), 3), 6) to be able to release the Colibri skin for
2.0 final IMO.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:34 p.m.
On Sep 8, 2009, at 5:28 PM, Marta Girdea wrote:
On Tue, Sep 8, 2009 at 2:48 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
Yes good point.
Thanks
-Vincent
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>
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.
Why javascript? This can be easily done on the server side in
velocity, by
looking into the string representing the rendered content. > We need at least 1), 3), 6) to be able to release
the Colibri skin
> for
> 2.0 final IMO.
>
> WDYT?
>
> Thanks
> -Vincent
5:49 p.m.
1. The document title is already unique, using the special HTML
element designed for titles: <title>. The problem is that it also
contains context information: the document name, the wiki description
2. Nothing prohibits using several H1 elements, so we should not make
= generate H2. We were doing this a while ago, but we reverted this
behavior.
3. Using a div for the title is much worse than having several H1
elements, one of which is the title. If we want to make it special,
using a plain div only does the exact opposite.
4. Using javascript is bad. JS should NEVER be used for basic
functionality, only for enhancements.
In conclusion, the best approach IMO is the following:
- Leave the title as a H1 as it is now, inside a <div
id="document-title">
- Don't change the current heading behavior, i.e. =XYZ= generates a H1
- Serverside, trim the first H1 element from the rendered content,
which is exactly what gets sent to the client (thanks Marta for the
idea)
Question: do we remove the first heading only when it is the same as
the document title (or when the title is empty), or do we always
remove it?
5:56 p.m.
Sergiu Dumitriu wrote:
1. The document title is already unique, using the
special HTML
element designed for titles: <title>. The problem is that it also
contains context information: the document name, the wiki description
2. Nothing prohibits using several H1 elements, so we should not make
= generate H2. We were doing this a while ago, but we reverted this
behavior.
3. Using a div for the title is much worse than having several H1
elements, one of which is the title. If we want to make it special,
using a plain div only does the exact opposite.
4. Using javascript is bad. JS should NEVER be used for basic
functionality, only for enhancements.
In conclusion, the best approach IMO is the following:
- Leave the title as a H1 as it is now, inside a <div
id="document-title">
- Don't change the current heading behavior, i.e. =XYZ= generates a H1
- Serverside, trim the first H1 element from the
rendered content,
which is exactly what gets sent to the client (thanks Marta for the
idea)
What's the input for the WYSIWYG editor in this case? I think the user
should be able to edit the first heading.
Marius
Question: do we remove the first heading only when it is the same as
the document title (or when the title is empty), or do we always
remove it?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:09 p.m.
On Tue, Sep 8, 2009 at 17:56, Marius Dumitru
Florea<mariusdumitru.florea(a)xwiki.com> wrote:
--
http://purl.org/net/sergiu
Sergiu Dumitriu wrote:
This is only happening in the default view mode, so it should not
affect the WYSIWYG editor.
1. The document title is already unique, using
the special HTML
element designed for titles: <title>. The problem is that it also
contains context information: the document name, the wiki description
2. Nothing prohibits using several H1 elements, so we should not make
= generate H2. We were doing this a while ago, but we reverted this
behavior.
3. Using a div for the title is much worse than having several H1
elements, one of which is the title. If we want to make it special,
using a plain div only does the exact opposite.
4. Using javascript is bad. JS should NEVER be used for basic
functionality, only for enhancements.
In conclusion, the best approach IMO is the following:
- Leave the title as a H1 as it is now, inside a <div
id="document-title">
- Don't change the current heading behavior, i.e. =XYZ= generates a H1
- Serverside, trim the first H1 element from the
rendered content,
which is exactly what gets sent to the client (thanks Marta for the
idea)
What's the input for the WYSIWYG editor in this case? I think the user
should be able to edit the first heading.
Question: do we remove the first heading only when it is the same as
the document title (or when the title is empty), or do we always
remove it?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9 Sep
9 Sep
9:16 a.m.
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 ?
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
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:28 p.m.
On Sep 9, 2009, at 9:16 AM, Denis Gervalle wrote:
On Sep 8, 2009, at 14:48, Vincent Massol wrote:
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.
Thanks
-Vincent
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 ? 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
1:28 p.m.
On Sep 9, 2009, at 12:28, Vincent Massol wrote:
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:
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. 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 ? 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
1:58 p.m.
On Sep 9, 2009, at 1:28 PM, Denis Gervalle wrote:
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.
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
I also think 1) is best for now since this solves issues with existing
content with no titles.
Have I understood your point?
Thanks
-Vincent
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:
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. 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 ? >> 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
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
5583
days inactive
5584
days old
28 comments
9 participants
participants (9)
-
[Ricardo Rodriguez] Your EPEC Network ICT Team -
Anca Luca -
Denis Gervalle -
Ecaterina Valica -
Marius Dumitru Florea -
Marta Girdea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol