Re: [CSS21] display:run-in clarifications - run-in and :first-line

2009/9/2 Tab Atkins Jr. <jackalmage@gmail.com>:
> On Wed, Sep 2, 2009 at 3:58 PM, Giovanni
> Campagna<scampa.giovanni@gmail.com> wrote:
>> 2009/9/2 Tab Atkins Jr. <jackalmage@gmail.com>:
>>> On Wed, Sep 2, 2009 at 1:01 PM, Bert Bos<bert@w3.org> wrote:
>>>> Combining run-in headings with first-line styling may no doubt give
>>>> interesting effects (at least interesting challenges for
>>>> implementers :-) ), but I can't remember ever having seen it in use.
>>>> That is no doubt because such a thing is difficult to recognize: if you
>>>> apply a first-line style to a paragraph, then it becomes difficult to
>>>> see that the paragraph starts with a heading. Which means, in effect,
>>>> that combining these effects is bad typography.
>>>
>>> To an extent.  I think that reasonably common typographic effects on
>>> first-lines include small-caps and increases in letter-spacing, both
>>> of which can be reasonably applied to a run-in header without removing
>>> the 'header-ness' of it (which is often conveyed through weight or
>>> size).
>>>
>>> So, let's talk typographic convention.  First: in normal typography,
>>> is the header styled identically as a block and run-in?  I think not -
>>> at the very least, block headers are usually substantially bigger than
>>> the surrounding body text, while run-in headers are equal size or only
>>> slightly larger.  So, there's a vote for having *some* mechanism of
>>> styling a header differently when it's a run-in.
>>
>> If you said display:run-in, then it will run in, and you can style it
>> appropriately.
>> In fact, you can infer from the source and style if the element will
>> effectively run in, or if it will became a block (you know what the
>> following element is, what are the contents of the run-in header,
>> etc.). Using creative selectors (especially those available in CSS4,
>> like :has() or :precedes()) you can even get different styles in case
>> you assign display:run-in to all your <h1>s.
>
> I disagree that you can always determine that a header is going to run
> in.  Part of the point of run-in is that you can be flexible about it,
> and only run in when appropriate.
>
> The selectors required to hack an effect similar to :running-in would
> be formidable.

mmm... not just "h1:matches(+ p):not(:matches(div,p,table))" ? (or
h1:previous(p):not(:has(div,p,table)) )

>>> Second: when headers are run-in with a specially styled first-line,
>>> are they styled the same?  You yourself suggest that they are not, and
>>> I agree.  While some styles are shared (my point two paragraphs ago),
>>> some properties are sufficiently different so that you can still
>>> visually tell the header apart from the content.  So, that suggests
>>> that using ::first-line on run-in headers isn't sufficient, at least
>>> on its own.
>>
>> I don't understand what you mean. Bert said that using ::first-line on
>> run-in is just wrong, or anyway it won't be used much.
>
> And I disagreed with Bert, with qualifications.

You agreed, that's what I didn't understand. Anyway, it's clear now.

>>> This points to the idea that we need a way to target headers with
>>> styles based on whether they're running-in or staying block.  The
>>> first idea that comes to mind is a :running-in pseudoclass on the
>>> header that matches whenever the header is running-in.  This seems
>>> like a good idea, but is it enough?  Can this by itself solve the
>>> styling issue so we can go with Option A and just sidestep the
>>> inheritance issue?
>>
>> See above: creative selectors plus knowledge of the source and style.
>> Plus, I think you can forget about:
>> - new features for CSS2 or Selectors3
>> - pseudo-classes based on the formatting structure (they cause
>> circular dependencies)
>
> I'm not talking about adding new features to the existing CSS2 or
> Selectors3; they're too close to Rec to make that an option.

But interaction of :first-line and run-in must be defined in CSS2, or
explicitly left undefined. Else it is a spec bug.

> Circular dependencies are a possibility (such as
> "h1:running-in{display:block}"), but I think that can be worked around
> in this case.

It is so easy to make something a block (display, float, position...)
that it would be problematic. Also you would need to prevent it on
every descendant.

> Alternately, a ::run-in pseudoelement on the subsequent block could be
> used, which can then disallow the use of properties that would make
> its content not a run-in.

That's a better option, but in general non-structural pseudo-elements
have a difficult interaction with the cascade / inheritance system,
that would need to be detailed completely.

>> I think that Option B is what makes more sense, since the run-in is on
>> the first formatted line, right?
>
> I agree, it just makes things more complicated.

It depends on what is the definition of :first-line (inserted in the
document tree or applied over the box tree)
See for example the thread I opened in parallel about it.

>> And it allows you to override properties from :first-letter that you
>> don't like by setting them explicitly on the run-in.
>
> Actually, you can't do that.  ::first-letter nests as deeply as
> possible, so it will override element-specific rules.

Sorry, I meant :first-line.

> ~TJ
>

Giovanni

Received on Wednesday, 2 September 2009 21:56:16 UTC