Re: [CSS21] 17.4: properties on outer & inner table boxes

On Sat, Nov 06, 2010 at 09:37:05PM +0100, Anton Prowse wrote:

> I don't think this is an issue since, as I understand it, the table
> box doesn't have a 'display' property.  The value of the 'display'
> property of an element determines (sometimes in conjunction with
> other information) the types of boxes that the element generates.
> The boxes themselves don't necessarily correspond exactly to the
> values of the 'display' property.  A table box is outwardly
> block-level and inwardly table, for example.
> 
> When the spec sloppily refers to blocks, inline blocks, inline
> tables, tables, list items etc in a context where it's really
> talking about boxes, the only sensible assumption is that it's
> referring to the principal box of the element of that type, so the

Section 17.2.1 (anonymous table object creation) is another place where
the spec currently assumes that boxes do have a 'display' property, and
needs e.g. the phrase "'table-row' box" to include boxes not generated by
a display:table-row element.

It's not enough to absolutely rule out going with the idea that boxes
don't have 'display' values (the "strong" version of the above approach),
but it is enough to dampen my enthusiasm for it.


However, either way, we still have a problem that §17.2.1 currently says
to generate table boxes around any table captions that are in an outer
table box, and we similarly have the problem that §17.2.1 only has effect
if there do actually exist table, table-row etc. boxes to start with, but
we currently don't have much text describing whether such boxes do exist
and what a box's parent is etc.

We do have "Each block-level element generates a principal block-level
box..." (§9.2.1), and the vague-looking statement "Internal table elements
generate rectangular boxes with content and borders" (§17.5) which we might
choose to change to "Each internal table element generates..." if we wanted
to make it less vague.  Of course as usual we don't have any text
describing what the properties of the boxes are or what their parents or
children are.

One approach to the problem of first saying that the parents are one thing
and then later saying that they're actually something else would be to
describe a sort of pipeline, where elements generate "provisional boxes"
that are subject to the manipulations of §17.2.1, which specifies a certain
output tree that §17.4 operates on.

Another approach would be to look at an existing implementation and rewrite
that as a specification.  However, this approach has legal issues: first
because it requires permission from a copyright holder of the existing
implementation, but even if granted, it's not clear that implementations
would legally be able to use the result: note that cover.html specifies
its license as

  http://www.w3.org/Consortium/Legal/copyright-documents

which expressly witholds permission to create derivative works.
Some jurisdictions may nevertheless allow it on grounds of local
equivalents of estoppel or scenes a faire (note I'm not a lawyer), but
this restrictive licence does seem like an unnecessary and undesirable
obstacle to the creation of conforming implementations: I'd have thought
that we actually *want* implementations to copy copyrighted elements such
as the "structure, sequence and organization" from W3C standards, since
doing so makes it easier to confirm that the implementation matches the
specification; conversely, it is reasonable to assume that deliberately
choosing not to copy those things in order to reduce one's exposure to
legal claims would tend to reduce conformance and interoperability, and
as such tend to reduce the value of W3C standards: the value of a standard
depends in part on how "standard" it really is.  Note that advancing legal
opinions here as to whether such a case could prevail doesn't really help
unless those opinions are added to the above-referenced licence statement
so that implementers can see them at the same time as the "do not implement
these standards" message that the existing licence statement gives.

Sorry that some of that paragraph is beyond the topic of www-style, but it
does seem relevant to what wording approaches to use: how close to final
algorithm form we make the text.


pjrm.

Received on Sunday, 7 November 2010 09:49:22 UTC