Re: replaced inlines [was: vertical-align content-generated image?]

Ian Hickson wrote:
| 
| On Fri, 3 Aug 2001, fantasai wrote:
| >
| > So :before and :after boxes do not exist by default.
| > Their box is generated by the "content" property.
| 
| I don't know if their box is generated by the property,
| per se, but whether the box is generated depends on the
| 'display' and 'content' properties, yes.
| 
| > But, unlike a box generated for any other element,
| > this content-generated box is stylable by its
| > (pseudo-)element.
| 
| Why that is 'unlike'?

It is unlike other elements because the box generated
for other elements is "the child of the box of the
element being affected", not the box of the element
itself (which is what style properties generally apply
to). Or at least, that's the impression I got from
what you wrote.

| > | > | > background-image takes type 'mixed content
| > | > | > replaced content'?
| > | > |
| > | > | Sure, why not.
| > | >
| > | > And does it also take type 'replaced content'?
| > |
| > | Does it need to?
| >
| > Why should it not? Why should 'background-image'
| > take type 'mixed content replaced content' and not
| > 'replaced content'?
|
| Because there is no reason for it to?

Let me rephrase the question.
Why is 'mixed content replaced content' more
appropriate than 'replaced content'?

| I think this merely proves what a mess can occur if
| you try to forcibly map concepts from strongly typed
| functional programming languages into a declarative
| language without functions.

It proves what a mess you can create by introducing
replace() notation.

| > | > [...] CSS data types were all *universal* to
| > | > the language.
| > |
| > | I challenge the assertion that they were universal.
| > | Why does @import take a string or whatever url()
| > | returns, but not whatever counter() returns?
| >
| > url() returns a URI.
|
| And '""' returns a string.

"A string is also allowed; it will be interpreted as if
 it had url(...) around it." -- CSS2, Section 6.3
 
| > counter() returns a string. They are different types.
| 
| But '""' and 'counter()' therefore are the same type.

counter() returns a string.

| > Just because @import accepts one type of argument
| > does not mean it accepts all of them.
| 
| But '@import' accepts '""' as an "argument".

See above.

| Why is
| 
|    @import "foo";
| 
| ...valid, if
| 
|    @import counter(foo);
| 
| ...is not?

a) Thus far, no CSS "function" accepts another as an
   "argument".
b) counter() is only defined for 'content'; you can
   consider it "out of scope"

| > | Why does attr() work for content, but not for
| > | background-image?
| 
| Because attr() is, in CSS2, a syntax specific to the
| 'content' property. There is a good chance that attr()
| will be allowed in many, many more places at some
| point in the future, including places that do not
| accept strings.

Yes.

| > Because attr() returns type string. 'content' already
| > handles type string. 'background-image' is defined to
| > accept url() notation, which returns something different.
| 
| By your logic, 'quotes' and '@import' should take attr().

'quotes' could take attr().
@import cannot: attr() is meaningless unless associated
with an element.

| > | > And cause CSS functions to become context-aware.
| > |
| > | This isn't as bad as you make it sound. They aren't
| > | functions in the first place, they merely have
| > | "function notation". And why should CSS not have
| > | function overloading based on return type?
| >
| > Why should it? It is not necessary.
| 
| Well, I have yet to see a better way of solving the
| replaced vs mixed-content problem for 'content' 
| (comments below notwithstanding).

Context-awareness came into the discussion when you
wanted to make 'mixed content replaced content' the
return type for url(). It is not necessary for
solving the replaced vs. mixed-content problem even
if you do decide to use replace().

| > It introduces complexity without adding power,
| > and it becomes extremely unwieldy in a strongly
| > typed language with "functions" (properties)
| > already overloaded based on argument type.
| 
| Where does the CSS2 spec say that CSS is a
| "strongly typed language with functions"? I see a
| section on basic data types which gives easy ways
| for properties to say what syntaxes they accept,
| and I see a lot of references to a "functional
| notation", but I don't see any reference to
| functions per se, nor return types, or assignments,
| or the like.

It was a metaphor. Perhaps I should have explained
the analogy before using it.

It is, as you said, possible to view CSS as a strongly
typed language. None of this is explicit, of course, but
by analogy, I can apply the concepts of strong typing to
CSS constructs:

There are a number of universal data types in CSS - 
number, color, string, and so on. They can be
represented literally. Some types have a distinctive
literal syntax, which allows them to be used in any
context without ambiguity. Other types must be
"flagged", as you say, with function notation. This
function notation conforms to the typical behavior of a
function - it takes an argument and returns a value,
typed accordingly. One can consider these types to not
have any literal representation, but to require a
conversion by an appropriate "function".

Keywords are values from an enumerated list specific
to the property. One can draw an analogy to enumerated
types in various programming languages. Thus line-
height's 'normal' is different from font-style's
'normal' even though their names are the same.

'inherit' can be viewed as a global constant similar to
null values in other languages (e.g. undef in Perl).

Like functions in strongly typed programming languages,
CSS properties take a number of "arguments". Many CSS
properties are "overloaded" in that they can take
arguments of multiple types, and indeed, varying orders
and numbers of arguments. How an argument is used or
interpreted depends on both its own type, and the types
and positions of the other arguments given in the same
property-value pair. Take, for example, the 'border-
width' shorthand property. The side to which first
argument is applied depends on how many arguments there
are. For 'border', how the first argument is used depends
on its type. Because of this, a missing type in some
property-value combinations results in ambiguity.
 
| > background: func(arg);
| >
| > What does func() return?
| 
| One or more of:
| 
|    <background-color>
|    <background-image>
|    <background-repeat>
|    <background-attachment>
|    <background-position>
| 
| ...or:
| 
|    inherit
| 
| Why?

func() returns the value 'left'. Is it returned as
a <background-position>, or a <background-image>?

func() returns the value 'white'. Is it returned as
a <background-color>, or a <background-image>?

| I guess I could change the syntax is arbitrary ways, e.g.:
| 
|    content: replace url(foo);
| 
| ...but the difference is trivial.
| 
| My proposal's syntax would then be:
| 
|   <text> := [ <string> | <counter> | attr(X) |
|               open-quote | close-quote |
|               no-open-quote | no-close-quote ]
| 
| content := [ [ replace <uri> | <text>* <uri> 
|              [ <text> | <uri> ]* ] , ]*
|            [ <text> | auto | none ]
| 
| Is that more to your liking?

A bit awkward, but at least it doesn't affect the rest of CSS.

Received on Friday, 24 August 2001 00:21:10 UTC