W3C home > Mailing lists > Public > www-style@w3.org > November 2002

About the bad CSS2 spec. - bad defined display types!

From: by way of Bert Bos <tapio1@gamma.nic.fi>
Date: Tue, 12 Nov 2002 00:43:33 +0100
To: www-style@w3.org
Message-Id: <200211120043.33093.tapio1@gamma.nic.fi>

Hi

I have discussed about the bad CSS2 spec. with a designer of Mozilla.


HTML 4.0 & CSS2 specs. use the word "inline" too loose. Inline-block
 level element creates always rectangular UNBREAKABLE shape around
 itself.

In existing (X)HTML language the shape is always RECTANGULAR.

Indeed in theory the shape could be also some else continuous
 unbreakable shape like ellipse and rounded rectangle, but (X)HTML
 doesn't support other shapes; radio button is ellipse but the 'input'
 element itself creates rectangular box around itself, which flows in
 the row.

I try below figure an elliptical shape:

hkkjkjkjkjkjkjkjkj
jljlkl kl kjkkkjkjk
löölölöijh   kllklk
jkkkkkkk       hkhkkhk
hkkjkjkjkg   hjjhjhjhjhj
jkj kjkjkjjkjkjkj kkj jkjk

If <input type="radio"> as big button would cause a shape like above,
 it would behave as inline-block, which shape type would be "ellipse".
 The PRIMARY feature of 'inline-block' that the shape itself can't be
 broken and wrap a piece of it to the end of line and second piece to
 the beginning of the new line.

The behavior type 'inline-block' should define precise in future specs.

I mean pure inline element just elements, which don't create
 rectanqular boxes but the content can be broken from arbitrary place
 to the next line(s). Inline - inline-block - block should be used
 consistent, which any spec. doesn't do!

Of course the default value of generated content is inline, but in
 PRACTISE the  display type of the content depends on what kind of
 content you actual embed to the document.

IFRAME is as its nature always inline-block, because the whole content
 is always inside a block! I know that 'inline-block' has added to CSS3
 primary because of form control element. IFRAME is however as much
 'inline-block' as for example 'textarea'. IF it would be real inline
 element, it should behave like <? require 'getFragment.inc'; ?>, which
 does or does not create a rectangular box. ONLY 'q','ins' and 'del'
 elements can in theory get replaced content, which behave like
 ordinary inline content. THAT kind of content should be handle like
 string.

When the spec. says that replaced inline element can have height etc.,
 that is INCORRECT behavior for replaced strings!

in fact elemenents, which have as the natural behavior type
 'inline-block' owns the STRONGEST display type. You can change ANY
 OTHER display type to some other display type except 'inline-block'!
 IF you set it as 'inline' you can just change properties, which are
 somehow secondary for the element (if the background-color is for the
 entire element, if borders are one line tall etc.), but you CAN'T
 change the real essense of the element.

If we speak about 'inline-block' we should speak also 'inline-string',
where string is PCDATA + such elements, which behave like a string
 ('b', 'strong').
Maybe the expression 'inline-string' is not good, but I can't think a
better one. Maybe 'inline-phrase' would be the best. Indeed it would be
best if
inline == inline phrase => NO confusion, no messy explanations!

In my mind inline has been defined too loose.

(below is a discussion)

>"inline" means a few things in CSS:
>
>1)  It's a statement about flow (inline boxes may wrap or may not).
>2)  It's a statement about what properties apply (eg width/height)
>3)  It's a statement about how baselines are determined and how they
>    affect vertical alignment.
>
>There are a few other facets to it.  inline-block and replaced inline
>are identical in their treatment of items #1

Just because the CSS2 is BAD. "inline boxes may wrap or may not" - BAD
definition because it is inexact! It defines as "inline" TWO remarkable
different behavior types! In my mind the basic error of definition in
 CSS is here! Because CSS2 defines inline on the base of HTML 4.0., the
 result is in my mind bad.

The common feature is just the flow.

>and #2

The spec. is TOTALLY BAD here too. It defines, that some "inline"
 element can have width and height and some not. The expression
 "replaced inline element" DOESN'T describe correct way the behavior
 type. There can be replaced inline level element, which behave like
 'inline-block' or like ordinary phase on the line. Replaced elements,
 which creates rectangular boxes (they behave like 'inline-block'),
 should take width and height but ordinary phrases should not. The
 difference of two behavior types should not be expressed by using the
 category "non-replaced inline level elements" - "replaced inline level
 elements". Rather we should write "replaced element, which have
 intrincis dimension" and elements, which don't have them. Replaced
 element, which have intrinsic dimensions, should get width and height,
 other not - INDEPENDENT if they are replaced or not. In some XML
 language can be element <include string="" /> where 'string' is
 PCDATA. It is very bad matter, if in this case the replaced element
 should be handled like 'object' or 'img' in HTML! The spec. should
 handle expected behavior of arbitrary XML language and give tools to
 set correct presentation for all element. It should NOT base on the
 behavior of existing HTML elements execpt that CSS should be able to
 emulate all HTML elements.

>item #3....

The CSS spec. would be clearer if:

Inline

1)  It's a statement about flow. Boxes flow on the line and the may
 wrap from artbitrary places.
2)  It's a statement about what properties apply, eg width/height.
 Inline elements don't NEVER take width/height
3)  It's a statement about how baselines are determined and how they
affect vertical alignment. They are as default set into the baseline.

Inline-block

1)  It's a statement about flow. Boxes flow on the line but they can't
 be wrapped like a phrase.
2)  It's a statement about what properties apply, eg width/height.
 Elements can take width/height properties. The intrinsic width of the
 box is the instrinsic width of embedded object or the width of widest
 text or child elements (shrink-wrapping algorith has been used). The
 intrinsic height is the intrinsic height of the embedded object or the
 height, which is consequence of the intrinsic width (the content of
 the element should fit into the box). User agent can set default
 heigth and with for boxes, which work as if intrinsic dimensions.
3)  It's a statement about how baselines are determined and how they
affect vertical alignment. They are as default set into the baseline.

>If you tried hard, you could stretch the definition of
>"inline-block" to cover the replaced inline behavior for item #3, but
> it would have disastrous results on the conformance requirements for
> (eg) form controls.

Then the expected behavior should be redefined or form control elements
should have an own display-type(s). Except the item #3 the display type
'inline-block' could be equal with 'object', 'img' etc. + form control
elements.






tapio1@nic.fi; http://www.nic.fi/~tapio1/
 __
¦__¦__ Cascading
¦__¦__¦__ Style
¦__¦__¦__¦   Sheets

http://www.nic.fi/~tapio1/Opetus/FAQ.php3
http://www.nic.fi/~tapio1/Teaching/FAQ.php3
Received on Monday, 11 November 2002 18:43:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:17 GMT