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

Solving problems in future specs.

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

Hi

CSS has much bad unsolved problems. I try to propose some
reasonable solutions:

CONTENT:URL();

The content can be in principle an entire document or a fragment.
BOTH cause problems.

I propose to add the property "content-url-type" with values 'object'
 and 'fragment'.

If you embed as such an entire document, the sturcture of the master
document has been destroyed. If you embed the url like IFRAME, a
 fragment is unstyled.

content-url-type:object would behave like the element 'OBJECT' with
 some default value (width:auto; height:auto; border:none;). The
 element would float like any embedded object that means its default
 display type would be 'inline-block'.

content-url-type:fragment would behave like <? require ''; ?> - the
 content would be embedded as such and the default display type would
 be 'inline'.

The default type should be in my mind 'object', when
 "content:url(image.gif);" gives the result, which Mozilla today
 supports it and how it has been used in
 "list-style-image:url(someImage.imageFormat);

REPLACED ELEMENTS

Existing CSS specifications handle replaced element totally
 unsatisfactory. In my mind the spec. should not to speak about
 replaced inline level and replaced block level elements but rather how
 OVERALL replaced elements should be handled.

If the UA has in UA style sheets defined that some element has the
 display type "block" and it can have replaced content, I don't see any
 problems. The element should behave like an ordinary block.

In principle UA should define for other elements in UA style sheets
 display types 'inline-block' or 'inline' for replaced content. But
 today they don't do at that way, which is bad.

We can write however elements, which can have intrinsic dimensions like
 'img'. If in the future spec. is not reasonable to write about "block
 level replaced elements", "inline-block level replaced elements" and
 "inline(-phrase) level replaced elements" the future spec. would
 handle just replaced elements, which can have intrinsic dimensions.
 The spec could define reasonable default behavior for them.

The problem is that replaced element can in principle be a phrase,
 which should be handle like inline phrasal elements. The spec. has
 however TOTALLY forgot elements, which embed phrases into the master
 document.

If some document type implements both ordinary embedded objects and
embedded phrases, how to browser could detect the type. There should be
defined default
behavior for replaced content, which would be rather than 'inline',
'inline-block'.

If the default value would be 'inline', the browser should handle it as
inline phrase.

The problem is now that existing definition of "inline" is incorrect!
 in CSS2.1 and CSS3 'inline' should be limeted to inline phrases! This
 means semantic changes like in CSS1 and CSS2 has changed the meaning
 of ":active".

WITHOUT this semantic changes the future CSS specifications are
 PERMAMENTLY INVALID!!! The NEVER descripe properly real behaviors of
 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:47:06 GMT

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