- From: Leif Halvard Silli <lhs@malform.no>
- Date: Sat, 02 Jun 2007 19:25:14 +0200
- To: Anne van Kesteren <annevk@opera.com>
- Cc: www-archive@w3.org
On 2007-06-02 10:02:30 +0200 Anne van Kesteren <annevk@opera.com> wrote:
> On Sat, 02 Jun 2007 03:58:51 +0200, Leif Halvard Silli <lhs@malform.no>
> wrote:
>> Anne, you are right. But we are all wrong.
>
> I don't think so. #IMPLIED just means the attribute is optional.
#IMPLIED attributes may in some cases be inherited:
#IMPLIED [1]:
«[...] Each attribute definition is a triplet that defines: [...]
* Whether the default value of the attribute is implicit (keyword
"#IMPLIED"), in which case the default value must be supplied by
the user agent (in some cases via inheritance from parent
elements); [...] Some attribute definitions
explicitly specify a default value for the attribute.
[...]»
Inheritance for TABLE cells works differently from other elements. I'll just quote one example [2]:
«Note. Note that a cell may inherit an attribute not from its parent
but from the first cell in a span. This is an exception to the general
attribute inheritance rules.»
«Span» means row, col, rowgroup, colgroup. I.e. exactly those values that SCOPE can take:
«<!ENTITY % Scope "(row|col|rowgroup|colgroup)">»
Many attributes, that are not generally inherited (I think only LANG, DIR and STYLE are) in HTML, are inherited in TABLEs. HTML4 describes many such inheritances for the COL, ROW, ROWGROUP and COLGROUP elememts. For instance about WIDTH [3]:
«The width attribute of the COLGROUP element is inherited by all 40 columns.
So when the spec says about SCOPE that [4]
«For a given header cell, the scope attribute tells the user agent
the data cells for which this header provides information.»
then what does it speak about other than inheritance? Even if it does not use that word? I would appreciate an alternative interpretation, if you have one. That a datacell inside a COL inherits the header text of its header cell, is just as obvious as the same cell inherits the width of its COL.
It makes sense to me, to see HEADERS as a way to override [or add, add could also be possible, if the UAs would remove double references] headers inherited via SCOPE. Just as many other attributes can be overruled per cell basis.
It is interesting that the spec introduces the section about rendering tables for non-visual UAs with the word «labeling» [5]:
Please consult the section on labeling cells for non-visual
user agents for information and examples.
The LABEL element is namely also one element which casts meaning from one parent element to a child element:
«The LABEL element associates a label with a particular form control»..
(The LABEL element also often appears inside TABLE.) LABEL also has one attribute, which reminds about HEADERS, the FOR attribtue [6]:
for = idref [CS]
This attribute explicitly associates the label being defined with
another control. When present, the value of this attribute must be
the same as the value of the id attribute of some other control in
the same document. When absent, the label being defined is
associated with the element's contents.
However, unlike HEADERS, which «collects» IDs, the FOR attribute «casts» the LABEL on to another element, so that the connected element «iherits» the meaning of the LABEL.
> As for the
> rest, [...]
.... my interpretation should support the WHATwg proposal, in all except the removal of the very HEADERS attribute.
[1] HTML4, section 3.3.4 «Attribute declarations»
[2] HTML4, section 11.3.2
[3] HTML4, section 11.2.4
[4] HTML4, section 11.4.1
[5] HTML4, appendix A.3.9 «CHanges to forms»
[6] HTML5, section 17.9.1
--
leif halvard silli
Received on Saturday, 2 June 2007 17:29:14 UTC