Re: comments on WD-css3-box-20010726

Thanks a lot for your comments.

Bjoern Hoehrmann writes:
> Hi,
> 
>    Some comments towards the CSS3 module 'the box model':
> 
> general:
> 
>   * I don't like most alt attribute values, they are descriptive rather
>     than alternatives.

Finding good ALT values is hard. I'm open for suggestions...

> 
>   * pseudo-elements should take the new CSS Level 3 syntax, i.e.
>     ::before instead of :before

Both are correct (at least for pseudo-elements that existed in CSS2).

> 
>   * I don't see a good reason why some references are just placeholders;
>     the relevant specifications are available like the multicolumn
>     module

The file is continually being edited; what you see is a snapshot.
Comments like yours will make the next snapshot better, but probably
for a while still, we will publish drafts that have known (and unknown
:-) ) errors, just because publishing early is more important than
publishing error-free.

I hope that is a good enough reason...

> 
>   * mark member-only links as such

Yes.

> 
> 3. Introduction and glossary:
> 
> [...]
>   root box, root element 
>   
>   The box resp. element that has no parent box resp. element. The root
>   element of the source document generates the root box. 
> [...]
> 
> Why is the root box not generated by the root node instead of the root
> element? Since the root box is said to be initially created by the user
> agent, this makes at least to me more sense. Especially, the root node
> cannot by selected with W3C Selectors so noone has a chance to affect
> those.

The root box belongs to the root element. That seems logical enough to
me, and it's been like that in CSS levels 1 and 2. Of course, the root
box has certain restrictions (cannot float, cannot be positioned,
etc.) and certain special features (e.g., for the purposes of
calculating percentages, it has some sort of "containing block"). But
it seems unnecessary to postulate another box that is the parent of
the root box.

> 
> [...]
>   positioned box, positioned element 
> 
>   A box resp. element whose 'display-role' property is not 'none' and
>   whose 'position' property is either 'absolute' or 'fixed'. A
>   positioned element generates a positioned box. Note that 'position'
>   does not apply to the root element. 
> [...]
> 
> I suggest to adopt the CSS Level 2 definition, e.g. "with a 'position'
> other than 'static'". The same goes for the following definitions.

The difference is in the "relatively positioned" elements: are they
"positioned" or not? It seemed to me that things are easier to explain
if relatively positioned elements are treated as normal flow elements
and not lumped together with absolute and fixed positioned elements.
For example, a relatively positioned floating element: is that OK or
not? I think it is, and so it is easier to say that 'float' applies to
"all elements except positioned elements," because that then
automatically includes relatively positioned elements.

> 
> 
> 
> 4. The 'display', 'display-model' and 'display-role' properties:
> 
>   the example for "various types of boxes":
> 
> the example uses '<h3>' while the text uses 'H3'; even if it is HTML and
> therefore case-insensitive, it should be consistent.

Yes.

> 
> 6. The 'border' properties:
> 
> The example rendering misses examples for 'dot-dash', 'dot-dot-dash' and
> 'wave'.

... as the draft itself already points out.

> 
> 14.1. The @link rule:
> 
>   * the section is misplaced in this document, it has nothing to do with
>     the box model in CSS

... ditto

> 
> 14.2. The link-behavior property
> 
>   * it should be "embed" instead of "expand" (as in XLink)

Maybe. The 'expand' effect is indeed a possible implementation of the
'embed' hint in XLink.

>   * it should be "new" instead of "pop-up" (as in XLink)

Maybe, but I think not. "New" may also mean a new top-level window,
like some implementations do for the "target" attribute in old HTML.
'Pop-up' is specifically a temporary window, such as a dialog box.

>   * it should be "replace" instead of "normal" (as you considered, as in
>     Xlink)

Yes, but the reason it isn't currently, is that there is possible
confusion with the term "replaced element," which means something
specific in CSS (something akin to expand/embed, in fact).

>   * the value "confirm" should be replaced by "download". The user
>     already confirmed his action by activating the link, more
>     confirmations aren't usable. If they are, it's up to the user agent
>     to get a second confirmation from the user.

The goal of every activation is a download; the special thing about
this option is that the download is confirmed first. So I believe
'confirm' is the better term.

> 
>     Instead, we need a "download" behaivour. XLink unfortunaly doesn't
>     include this behaivour but it's needed very often. For MIME there is
>     the Content-Disposition header, but this is not applicable for WWW 
>     resources, since different behaivours are desireable for different
>     links, e.g. downloading images, XHTML documents, etc.

It seems we agree on the functionality, though not on the name...

> 
> 14.3. Confirming link traversal:
> 
>   * the example is invalid, the style element misses a type attribute

Depends on the version of HTML... But I agree, and I'll add it.

>   * the title attribute is indeed abused here and the hyper reference
>     doesn't point to something to download (as it states), it points at
>     some location from where one may download something

You're using knowledge about the target of the link that you cannot
know from the given code...

This happened to be a real life case that I found on the Mozilla site.
(It is no longer there.) But, sure, I can improve the example.

> 
>   * if the WG insists of this property, the title attribute should read
>     like "Download latest Mozilla build?", but as I said, the "confirm"
>     behaivour is useless
> 
>   * who do the rel and rev attributes in XHTML interact with this @link
>     rules?

They don't interact (unless you explicitly put them in a selector, of
course, just like any other attribute).

> 
> 14.5. The ":expanded" and ":collapsed" pseudo-classes:
> 
>   * Huh? More selectors outside the W3C selectors draft? I thought all
>     selectors go in the W3C Selectors module? If so, move them there, if
>     not, move e.g. the UI selectors to the UI draft from the Selectors
>     module

Yes, they should probably go to the Selectors module. But it is a pity
to hold up the Selectors module, which is otherwise ready, because we
haven't finished discussing how to deal with collapsing/expanding
elements yet.

> 
> 14.7. The Back button:
> 
>   * Some interactive user agents don't have "buttons", Lynx for example
>     or voice browsers with some kind of speech control, etc. Don't call
>     it "button"; "history feature" or something like that would be more
>     appropriate.

I hesitate between readability and correctness here. The text doesn't
require the function to be implemented with a button, it's just how
the feature is commonly known. I'll see how it looks with "history
feature" or some such...

> 
> 15. The float property:
> 
>   * the second example isn't well-formed. Even if this is no issue,
>     since the example is HTML, it's bad style if you consider, that
>     XHTML is meant to replace HTML; this goes for other sections, too.
>     For example, please quote all attribute values

Hmm, HTML is much easier to write than XHTML... And because redundant
tags can be omitted, it is clearer in examples as well.

> 
> 18. Collapsing margins:
> 
>   * the third example: the last closing tag should be indented to the
>     same level of the start tag

Yes.

> 
> Acknowledgements:
> 
>   * the last sentence is "See under", I'm sure there is something
>     missing

So am I :-)

> 
> References:
> 
>   * Xlink is now a recommendation (as of publication of this draft)
>   * SVG is a proposed recommendation (as of publication of this draft)

Indeed.

> 
> I suggest to use XHTML syntax for the document and all examples in place
> of HTML; I suggest to incorporate examples for different markup
> languages like SVG or MathML.
> 
> I have more comments, hopefully I'll get some time to write them up...

Yes, I hope you do.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Monday, 30 July 2001 14:38:36 UTC