- From: <bugzilla@jessica.w3.org>
- Date: Tue, 15 Feb 2011 06:52:51 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11737
Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xn--mlform-iua@xn--mlform-i
| |ua.no
--- Comment #2 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-02-15 06:52:49 UTC ---
(In reply to comment #1)
> > * It solves the main problem of the current content model - that some headings
> > in a hgroup no longer have h1-h6 semantics (except that they do, in legacy UAs)
> > - this is hard to grasp and hard to "calculate" the effects of.
>
> I don't understand this point. Can you elaborate?
In a HTML5 UA, <hgroup> has the "heading value" of the child with the highest
heading value.
Wheras in a HTML4 UA, <hgroup> would have no "heading value" whereas each hn
child would have a heading value.
By saying that only one hn element is permitted, the HTML4 UA and the HTML5 UA
would get a much more identical effect - they would both see only one header.
(The disadvantage would be that HTML4 UAs would not see any heading value for
the sh elemetns.)
> > * It is easier to style with CSS. It doesn't require the same detailed view of
> > the markup structure as the current content model does.
>
> The hgroup styling is hardly burdensome:
>
> hgroup > h1 { ... }
> hgroup > h2 { ... }
I would assume that if the <h2> follows a <h1> inside a <hgroup>, then the h2
would be styled differently from when the <h2> appears outside hgroup, no?
Whereas the selector you demonstrate there treat both cases the same. If you
treat both cases the same, then it seems to me that you woudl treat a <h2>
inside <hgroup> the same as a <h2> outside <hgroup>. But in that case, you
would probably not need 'hgroup' inside the selector!
> The proposal above doesn't really improve it, either - I don't think this is
> any more intuitive:
>
> hgroup > h1 { ... }
> sh { ... }
The simplification is that I can do
hgroup h1+sh { }
hgroup h2+sh { }
of courrse, one can also do for example
hgroup h1+h1 { }
hgroup h1+h2 { }
hgroup h1+h3 { }
hgroup h1+h4 { }
hgroup h1+h5 { }
hgroup h1+h6 { }
hgroup h2+h1 { }
hgroup h2+h2 { }
hgroup h2+h3 { }
hgroup h2+h4 { }
hgroup h2+h5 { }
hgroup h2+h6 { }
however, as you can see, this creates many more options - for what the element
after the h1 element is. It thus creates many options that the author doesn't
need and which only needlessly complicate things. if a detailed differentiation
is needed, then the author can use class names.
The sh element also allows you to do this - provided that sh is not the first
element:
hgroup h1:first-child+sh {}
as well as
h1+sh {}
So, no, to me 'sh' is really much simpler because it creates fewere options.
> > * It is semantically less confusing, as hgroup with this content model only
> > contains a single hx.
>
> I don't understand why having multiple levels of headings is semantically
> confusing. It seems pretty semantically clear to me.
The 'sh' is also a heading - but it is a sub/super heading. So then we are on
the same page in that detail. The confusing that I have in mind is related to
the outline effect.
> > * It has better semantical fallback: Both a legacy UA and a HTML5 UA would
> > create the same outline. In addition, a HTML5 user agent would EITHER see the
> > whole thing as a heading (if we define it like that) OR it would see the hgroup
> > as solely a container for grouping <sh> together with <hx>.
>
> Not sure what practical effects this would have. What concrete software or
> users would be affected by this "semantical fallback"?
These is the concrete, affected applications I am aware of - on the top of my
head:
* iCab has a feature whereby it creates an outline of the header on the page.
* Amaya has a feature whereby it generates ToC based on the heading element of
the document one has authored
* PrinceXML generates outlines in PDF based on the headerers it finds in the
document. (This outline is presented in the sidebar of the PDF document in the
Mac OS X Preview.app and - probably - in a similar way in Adobe.) This is a
featuere that is independent of ToC's that the author creates manually.
I also believe that AT are affected in similar ways, but I have no concrete
test results.
> > * It it makes the outline algorithm easier to understand and implement. At the
> > same time, the current outline - as described in books and implemented here and
> > there - would continue to work, except when the highest rank heading follows
> > after lower rank heading(s).
>
> The outline algorithm's complexity is not due to <hgroup>. I don't think this
> proposal materially affects the complexity of the algorithm. Indeed <hgroup> is
> not explicitly mentioned in the outline algorithm currently at all.
You might be correct - I would have to recheck the algorithm. But as I assume
you are entirely correct, then then my only point, in this regard, would be
that it is simpler to assume that all hn elements should be inserted into the
outline, than it is to assuem and calcluate with the fact that there are some
exceptions, namely those hn elements thare are not the first and higheest of
rank inside a hgroup element.
> > * It seems harder to use incorrectly. The only obvious mistake that one could
> > make would be to use <sh> outside a <hgroup>, which would be relatively
> > harmless (semantics of <div>).
>
> I don't understand why that is harder than misusing <hgroup>. What failure
> scenarios with <hgroup> are you expecting to commonly see?
By harder to use incorrectly, I meant that it is harder to misuse a "sh"
outside a <hgroup> than it would be to use a hn outiside a hgroup incorrectly.
(I was partly copying an argumetn put forward by James - I think --, so it
doesn't entirely fit.)
If a sh by mistake lands below the hgroup or if the author fails to use hgroup
at all, then the outline still becomes the same as if he/she had wrapped the sh
inside the hgroup. Thus, the only advantage of adding wrapping the hgroup
around a "loose" <sh>, would that it brings "headerness" to the 'sh' element.
Outside the hgroup, it has no headerness.
To your defences, I would then say that, precisely because a "loose" h1-h6
element needs to be inside the hgroup in order to loose its "outline-ness",
then this is an argumetn in favour of the current solution: In a HTML5 aware
user agent, the moving of the hn element inside the hgroup may give the author
visual feedback that he/she is removing the outline-ness.
To my defence: one would get the same effect by using <sh>. But, again, the
disadvantage would be that this would happen even if I did not move the <sh>
inside <hgroup>. I can see some advantages to the current solution in that
regard. The only way to overcoeme this, would be through saying that 'sh' *is*
included in the outline - unless it is kept inside <hgroup>. Could that be an
option?
> Problems with this proposal:
> * It doesn't degrade gracefully in legacy UAs.
> * It doesn't pave existing cowpaths (which use <h1>/<h2> - see e.g. the HTML4
> spec).
> * It only supports one level of subheading.
Replies about the problems you see:
* Strictly speaking, since a sh could be used both before and after the hn
element, it would be possible to discern both a "before subheader" and an
"after subheader".
* But otherwise: Yes, it only supports one level of subheading. However, I
consider the internal fine-grained sub-heading levels as mostly a visuall
formatting thing. Can it be proven that it is otherwise?
* Regarding the cowpath of the HTML4 spec: Is it certain that
<h2>W3C Recommendation 24 December 1999</h2>
does not belong in the outline? If there is a problem with that, then why
didn't they use a <p> element instead?
* a HTML5 parser will not jump over that h2 element when creating the outline
either. So I don't quite see the cowpath.
* Is it relevant to consider that _specs_ creats cowpaths? I have the feeling
that you, in general, find that specs are not "in the wild" examples.
* I don't understand your "degrade gracefully in legacy UA" point of view. It
seems to me that whether this is true depends on whether it is most important
to preserve a "headerness" - which nevertheless does not cause an outline. Or
if it is most important to create a useful outline.
* I believe that, to the extent that current tools and browsers provides
outlines - and/or auto-generated table-of-contents - then authors have adapted
themselves to this. I, for one, would not have followed the HTML4 "cowpath" if
I did not want the H2 element to take part in the table-of-content/outline.
* Therefore, this socalled cowpath, if it exists outside W3 specifications,
seems - eventually - more a result of a focus on the visual results than on the
semantics. And in the cases when it is not about visual effect, then I bet
that they *did* want the outline that this gave them.
* I would of course not claim that HTML4 or XML1.0 was authored by people who
cared for the visual results more than the semantic results. And there are of
course two options: the HTML4 editor could have been very keen on saying that,
<imaginary-quote> the 'W3C Recommendation 24 December 1999' *is* a header,
despite that I am unabl eto remove it from the outline</imaginary-quote>. The
other option is that the HTML4 spec editor were entirely satisfied with both
the outline and the headerness. But what do we know? It is pure speculation to
me.
I think it is correct to assume that one would want to have subheadings, and
for that reason - certainly - it must also be correct to assume that many
occurrences of
<h1>Line 1</h1><h2>Line 2</h2>
could very well have been meant as a
<hgroup><h1>Line 1</h1><h2>Line 2</h2></hgroup>
But that, eventually, to me becomes a cowpath for the very subheading concept,
and not a cowpath for that exact way to construct subheadings.
I am not unable to see that the current content model of hgroup has some
advantages. For instance, it introduces only one element - hgroup - instead of
two - hgroup and sh. And, if you want to change a h2 into a subheader, you
just wrap a hgroup around it, instead of turning it into another element first.
But when evaluating the legacy UA compatibility issue, I believe that it is
more important to consider the outline effect than it is consider the header
effect. And if I am correct in that way of looking at it, then we must look
away from such examples as the HTML4 specification: they don't tell us
anything, and exactly teh HTMl4 spec will nevertheless never be affected by our
decisions, since the HTML4 spec was set in stone 12-13 years ago. We can assume
that the authors of "the next spec" will want to use hgroup, but we cannot know
whether the editor simply want to use a new feature or if he/she truly did not
- and neved did - intend to include 'W3C Recommendation day-month-year" in the
outline.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 15 February 2011 06:52:54 UTC