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

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'?


>>>>> 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? 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.


>>> [...] 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.

> counter() returns a string. They are different types.

But '""' and 'counter()' therefore are the same type.

> Just because @import accepts one type of argument does not mean it
> accepts all of them.

But '@import' accepts '""' as an "argument".

Why is

   @import "foo";

...valid, if

   @import counter(foo);

...is not?


>> 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.

> 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().


> [re SGML] Even if I were to define two different attributes that
> take the same two values, the values would be independent of each
> other. They would only /look/ the same.

Actually, that would be illegal SGML. But putting that aside, if you
were right, then the same argument could be mapped to CSS: two
different properties can both take the 'url()' syntax, but these
values are independent of each other. They only /look/ the same. (And
their syntax is defined in the same place for convenience.)


>>> 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).


> 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.


> background: func(arg);
>
> What does func() return?

One or more of:

   <background-color>
   <background-image>
   <background-repeat>
   <background-attachment>
   <background-position>

...or:

   inherit

Why?


>>> Another alternative would be to redefine a single url() value as
>>> replaced content. This would avoid adding another "redundant
>>> property".
>> It's an interesting idea, but it is not backwards- compatible.
> ...Actually, you probably could redefine url() content without
> breaking the spec. CSS2 doesn't say that URI- referenced resources
> should be inserted as inline-level children of the pseudo-element's
> box--just that they're inserted.

If I say:

   h1:before {
      display: block;
      content: url(header.png);
      width: 50%;
      background: blue;
   }

...then I hope my header isn't stretched to 50%. But if I say:

   h1:before {
      display: block;
      content: replaced(header.png);
      width: 50%;
      background: blue;
   }

...then it should, with the aspect ratio kept the same.


> So, theoretically, a later version of CSS could clarify that by
> default, the content gets appropriately "replaced" in a manner
> similar to <img>.

That is incompatible with the spec, and, maybe more importantly when
it comes to ambiguities, with shipping implementations of ':before'
and ':after'.


>> Is your only problem with my proposal that it introduces a new
>> function notation which you feel is redundant with url() ?
>
> It is that you are introducing function notation to change the
> behavior of the property, which I don't think is a good idea.
>
> Whether the URI is noted by url() or replaced(), it is /still/ a
> reference to another file. It hasn't changed, so neither should its
> handling.

Here is the problem I am trying to solve:

   There are two ways of handling references to files: as mixed
   content, and as replaced content. CSS2 allows references to files
   to be handled as mixed content. Devise a way in which CSS can be
   extended to allow it to flag URIs as replaced content too.

The whole *point* of my solution is to change the handling of
references to other files.

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?

-- 
Ian Hickson                                            )\     _. - ._.)   fL
Invited Expert, CSS Working Group                     /. `- '  (  `--'
The views expressed in this message are strictly      `- , ) -> ) \
personal and not those of Netscape or Mozilla. ________ (.' \) (.' -' ______

Received on Friday, 3 August 2001 19:00:47 UTC