9 Sep
2009
9 Sep
'09
11:07 p.m.
Sergiu Dumitriu wrote:
Anca Luca wrote:
just thinking if it's ok to have the title of the page as a (html) semantic
sibling of its (wiki) semantic children.
Also, since the <title> is the title of the page, if the title is a <h1>
it's
also a child of itself (actually that would be true regardless of the markup
we'd use for it...)
Happy hacking,
Anca
Sergiu Dumitriu wrote:
Because it is the best element for the task at hand. It still is a
title, so it deserves a heading element. Vincent Massol wrote:
true, and this means that we could have the title
displayed in a page in
anything (<div>), doesn't necessarily have to be semantic, since its semantic
is
given by its use in the <title>. Normally, from the semantic pov, we should
leave it only in title, but it's just that we need to emphasize it for the user.
Why would we put it in a h1 then? Hi,
Let's vote on how to handle the title behavior for the 2.0 final
release so that we're all on the same page.
Here's what Mediawiki (on
Wikipedia) does:
- the document title is displayed using a h1 id=firstHeading
- the content allows using =titles=, which generate h1
- by a natural process, contributors rarely use =titles= in documents
So I continue to think that we should allow users to enter = titles, and
they should generate h1. There is no rule against a document having more
than one h1. Again, the document title is in the <title> element, not in
the <h1> element. >> After talking to several people
here's what I propose:
>>
>> 1) We remove the top level H1 only if the title compat flag is on and
>> the title H1 is the same as the top level H1
>> 2) The compat flag is off by default in our distributions
>> 3) We modify the Toucan and Albatross skins to display the title (same
>> as Colibri)
>> 4) We modify the Default XE XAR to have titles for all its pages (and
>> remove the header 1 in page content)
> What happens with dynamic titles?
>
>> This should cover both user upgrades and new behavior. Note that user
>> custom skin will still work in most cases since they're not normally
>> touching the contentview.vm file.