Re: [csswg-drafts] Please define how the various box tree fixups interact

> None of these conflict

The code comments suggesting that the computed-value fixups from ruby and grid have to happen in a particular order don't make me very confident in this claim, unfortunately.  It's possible those comments are wrong, of course.

> These are mutually exclusive, because they occur in different formatting contexts

Really?  What happens when I have a ruby-text-container parent and a table-cell child?  Which anonymous box fixups apply and in what order and why?

> Anonymous box generation happens after computed value fixup

That's ... not what the ruby draft I linked above says, just to be clear. It _explicitly_ says that ruby-triggered inlinization happens _after_ anonymous box generation for tables, and that it affects computed display values.

> because box generation in general happens after computed values are completely resolved

Yes, that would be the sane thing.  The specs explicitly say that's not how it works, at the moment.

 > or do you need something actually added to the spec here

Well, it would be good if the categorization given didn't disagree with existing spec text, for a start.  That probably involves changing said spec text.

Just to make my position crystal clear:

1. The current situation is complicated enough that neither implementors nor spec editors know what's going on, as far as I can tell.
2. That lack of understanding and clarity about what's going on means it's easy for people to write specs and create implementations that make the whole thing fall down.  On the spec side, that would include explicit wording that violates the ordering of your items 1 and 2, computed value fixups that conflict with other computed value fixups (that's assuming we have no such conflicts so far; even if we assume that, it's far too easy to accidentally create one), anonymous box fixups that conflict with each other, and anonymous box fixups that do not make sense (e.g. in my ruby-text-container+table-cell example above, do we get an anonymous inline-table or an anonymous table?  CSS2.1 says "table for everything that's not `display:inline`", but I strongly suspect it should be an inline-table for general sanity).

I would like to avoid the problems in my item 2.  I think addressing item 1 is likely the best way to get there.  My specific suggestion is to make this stuff very explicit: if anonymous box fixups happen after all computed style fixups, they should clearly say so (and neither one say the opposite).

So a possible start would in fact be to have the two sets of fixups, have all fixups say which set they're in, explicitly invoke the computed-value fixups at cascade time, explicitly invoke the box tree fixups from box tree construction.

Or put another way, whenever someone adds a new fixup, it should be easy for them to check whether it conflicts with existing fixups.  Right now that is more or less rocket science.  Even getting a list of existing fixups is rocket science.

-- 
GitHub Notification of comment by bzbarsky
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1355#issuecomment-301888405 using your GitHub account

Received on Tuesday, 16 May 2017 19:22:40 UTC