Re: collapsible property

Are there browser vendors with opinions on this? Would this be difficult to
implement? Are there edge cases that make this complicated?

On Fri, Feb 12, 2010 at 7:03 PM, Daniel Danilatos <danilatos@google.com>wrote:

> Hey guys,
>
> 2010/2/12 Patrick Garies <pgaries@fastmail.us>:
> > On 2/10/2010 11:43 PM, Daniel Danilatos wrote:
> >>
> >> Inferring orthogonal behaviour from line height or similar properties
> >>  seems kinda hacky and potentially leading to all kinds of corner
> >> cases. I think it's clearer and simpler to have a property that
> >> defines exactly the desired behaviour (keep the block element open)
> >> and leave things like line height and min height to their independent
> >> meanings, without having to complicate them with extended
> >> interpretations
> >
> > Maybe I'm misunderstanding the issue.
> >
> > You seem to want an element--when it (A) is empty or (B) all of its
> > child elements are empty or (C) all it contains is whitespace--to remain
> > one line tall rather than "collapse" to a height of zero when it has no
> > content. (Like Andrew, I wouldn't expect (B) and (C) to ever occur with
> > a well-written script though.) If this is actually what you want, then
> > all you're trying to do is control the presentation of the element's
> > height; I don't understand how this is "orthogonal behavior" with regard
> > to the purposes of the |height| and |line-height| properties.
> >
>
> I wrote an attempted explanation earlier. I'm not sure if it's fully
> addressed your question or not. But I don't think it's too important
> as to whether we agree on how "orthogonal" they are.
>
> > Perhaps you could provide some example code or a live example that
> > demonstrates the issue and how existing mechanisms cannot easily be used
> > to solve it? It's a little hard to solve a problem without actually
> > seeing it.
> >
>
> I will try to put some html examples up next week if that will help (I
> have described some already in emails here). The issue is something
> faced and solved (to various degrees, with complicated js code) by
> rich text implementors, at the very least it is an annoying issue in
> google docs and google wave.
>
> 2010/2/12 Andrew Fedoniouk <news@terrainformatica.com>:
> >> Perhaps I shouldn't say "non-collapsed" because my meaning can be
> >> misinterpreted. I gave a clearer definition when I mentioned the <br>
> >> in answer to your second question from the earlier email, hopefully
> >> that answers the above question too.
> >
> > <br> where?
> >
> > Here:
> >
> > <p>|<span></span></p>
> >
> > or here:
> >
> > <p><span>|</span></p>
> >
> > ?
> >
> > If these P and SPAN have different font-size properties then you will
> > get different heights in these cases thus your "collapsing" term is very
> > fuzzy.
> >
>
> To keep things simple, I would define it as the behavior you'd get by
> putting the BR at the very end of the block element you are making
> non-collapsible (this interpretation applies to browsers that use BR
> for this in the first place).
>
> The BR trick is a hack used by some engines; rich text editors attempt
> to emulate it when they need to manually create empty paragraphs,
> setup content, etc. There are many corner cases which both browsers
> and javascript apps get wrong, this is the point we are trying to
> make, that the situation is ugly and needs fixing. It's reasonably
> straight forward to put a BR in an empty paragraph, but when things
> like spans, inline block element, etc start coming into play, it
> becomes harder to tell when you need to do this to keep the paragraph
> from collapsing. It would be much simpler just to be able to set it as
> being always open. Currently, in webkit, it is possible to always
> leave the BR there, and that somewhat solves the problem, but has
> other bad side effects. And, of course, you have this BR in always
> your HTML when you usually don't need it.
>
> 2010/2/12 Andrew Fedoniouk <news@terrainformatica.com>:
> >> I've tried it, it doesn't work. The height differs by a few pixels
> >> when it is empty vs not empty, and the difference is affected by line
> >> height and other properties. It might be the case that with sufficient
> >> CSS hackery there will be a brittle solution, but I think that's far
> >> less desirable than a property that has the exact semantic meaning of
> >> what is desired.
> >
> > Few pixels kind of error but now and some collapsing property in next 10
> > years. Choice is yours.
> >
>
> I'm not sure what you mean - are you saying we shouldn't try to fix
> these problems? Rich text editors have a lot of hacky code to work
> around the problem today, so that is the "now". Improved standards is
> the future. (I am also optimistic it will be a lot closer than 10
> years, and it could be within weeks for Webkit, if there is buy in).
>
>
> >> It also doesn't work at all in IE.
>
> 2010/2/12 Andrew Fedoniouk <news@terrainformatica.com>:
> > It is a bit optimistic to expect it to support 'collapsing' either.
> >
>
> 2010/2/12 Patrick Garies <pgaries@fastmail.us>:
> > Your proposed property will not work in Internet Explorer (the browser
> > with the longest release cycle) for maybe 3-5 years assuming that such
> > an idea were adopted. Then you still have to deal with all of the non-IE
> > browsers which would undoubtedly also have a major lag before they
> > implement it as well as all of the previous versions of those browsers
> > and IE. That's what, a decade before it can be used reliably? So the
> > result would be the same for quite some time.
> >
>
> I'm not sure why we're dwelling on the fact that IE is slow to adopt
> new standards - by this argument we should just give up on all
> progress? I was pointing out that the proposed alternatives brought up
> so far in this thread have various flaws, the fact that they don't
> work in IE being one of them. For the time being, rich text editor
> implementors will have to do (and have been doing) the hard work of
> working around these issues, but isn't that how it works for
> everything on the web? Based on our experience on this matter so far,
> we believe this proposal is a clean, practical solution to the
> problem.
>
> Dan
>