Re: [CSS21] anonymous blocks vs run-ins; and Distinguishing block boxes proposal

Peter Moulder wrote:
> On Mon, Aug 09, 2010 at 10:28:02PM +0200, Anton Prowse wrote:
>> Peter Moulder wrote:
>>> On Sun, Aug 08, 2010 at 04:37:48PM +0200, Anton Prowse wrote:
>>>
>>>> Whilst I agree that various unresolved complications concerning run-ins
>>>> still remain, I'm not sure why this leads you to the following conclusion:
>>>>
>>>>> On Wed, Jul 21, 2010 at 12:16:54AM -0700, fantasai wrote:
>>>>>
>>>>>> ...
>>>>>> Section 9.2.1.1 Anonymous block boxes
>>>>>>
>>>>>> # In other words: if a block box (such as that generated for the DIV
>>>>>> # above) has another block box or run-in box inside it (such as the P
>>>>>> # above), then we force it to have only block boxes and run-in boxes
>>>>>> # inside it.
>>>>>>
>>>>>> s/another block box or run-in box/a block-level box/
>>>>>> s/only block boxes and run-in boxes/only block-level boxes/
>>>>> [...] the behaviour that I've seen makes me inclined to suggest that
>>>>> the explicit mentions of run-ins should be retained in each of those cases:
>>>>> although the evidence isn't unanimous, the principle of avoiding making
>>>>> unintended normative changes suggests that the explicit mentions of run-ins
>>>>> should be retained for now at least.
>>>> Currently, 9.2.3 says that display:run-in causes various block-level or
>>>> inline-level boxes to be generated.
>>> it would
>>> appear that the new definitions make no difference to whether run-in boxes need
>>> distinct mention, so without looking into it we should err towards trusting the
>>> initial text's author's judgement that it's worthwhile mentioning them
>>> explicitly.
>> It's a very fair point.  Whilst mentioning them was already as
>> editorially risky as it is now to remove that mention (eg, see below), I
>> too am now more confident that it doesn't actually matter whether we
>> define the behaviour of a block container box in terms of the presence
>> of run-ins or not.
> 
> Do people (Anton particularly) agree that explicit mention of run-ins does
> serve practical purpose, that retaining some mention of run-ins is more likely
> to result in the desired interpretation for at least some readers?
> The excerpts that Anton identified do add weight to a reading where explicit
> mention would be desirable.

Honestly?  I'm – at best – indifferent to run-ins in CSS21.  If it were
up to me, I'd drop them from the spec altogether (or at least say that
in CSS21, display:run-in only applies to elements/boxes that have no
non–inline-level descendants; though I haven't given much thought to the
feasibility or consequences of that).  My only concern right now is that
their explicit mention doesn't mess up our definition of block
container box, and won't mess it up if we decide to remove that mention
later.  As I said, I'm reasonably confident that it doesn't.


> That's not to say that it would be impossible to change the text to avoid this
> conflict, but I hope it does add a little weight to the argument that
> retaining explicit mention of run-ins will be helpful to some readers,
> and that it also shows that run-ins have non-obvious behaviour even
> before we've looked into how those two sections together interact with
> various other parts of the spec that either modify the box tree or whose
> behaviour depends on the box tree (such as counters, list item numbering,
> anonymous table box creation, list-style-position:inside, and so on).

I understand your motivation, although I think we could restore the
reference later if it proves necessary.  As Boris say in a later post,
we're all working off of an out-of-date spec anyway, so it's really hard
to pass judgement at the moment.


>> The trouble is, the timing device doesn't hold together very well.
> 
> If by that Anton means that the timing is underspecified, then I agree.
> However, at least it isn't inconsistent.
> 
> (I think Anton was trying to show that although the current text is unclear,
> the timing probably isn't as simple as "apply one of these sections to all of
> the tree before applying the other section to any of the tree" for most
> readings of the spec, and I would tend to agree with that.)

Both of those.


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 10 August 2010 20:59:32 UTC