Re: Shrink to fit

@ David:
The link on Neville's initial proposal included a case-specific sample
implementation in Javascript, and it only takes two statements to do
the size fixing. Even in the general case, this shouldn't have too
much of a performance impact.
IMO, the sanest way to implementing this proposal would be to just
adjust the size of any relevant element when its size is changed by
any other reason (including if the element got more room after
shrinking a nearby element.
Of course, this might have a more serious performance impact on those
pages that abuse this feature (in the extreme case, applying this to
all elements); but these extreme cases would be as silly as a while(1)
doSomething; script.

@ Alex:
On Sat, Sep 26, 2009 at 2:37 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> I think however that the reason for current behavior is interoperability more than performance. Not sure if the algorithm is documented in CSS2.1, but current implementations are clearly interoperable so this behavior is not changing.
There is no intent to alter current behavior. The proposal is about
adding some *explicit* option in CSS3 to trigger the new behavior only
on the chosen elements.
Achieving an interoperable implementation for the new feature between
different browsers should be a matter of providing clear enough spec
text and a good test suite.

> It is of course possible to implement the other behavior too, if there is a need for it. Which leads to the next question - if an option existed for a "tighter" shrink to fit, how would it be used? Is there an example where it would make a significant difference? Perhaps something that would be really hard or impossible to do with current standard?
On my first reply to this thread, I shared a link to an example that
would fall into the "impossible" (without scripting) category.
The link, again, is http://abc-jitkasplayground.com/. The relevant
part of the page is the dropdown menu below the logo. These is what
the client and artist asked for:
1) The menu should be centered. This wasn't entirely achieved: it gets
close to centered for wider viewports, but it had to use approximate
sizes to avoid breaking when a replacement font is used.
2) When the viewport is resized to be narrower than the full menu, the
menu should break into multiple lines, but it should be still be
centered (this is, the remaining h-space after sending enough elements
down to new lines should be equally split among both sides).
3) It shouldn't use javascript to solve this. Not very rational, but
go try to explain a non-expert client that javascript compatibility
issues are a ghost from the past and easily avoided with sane
scripting practices and careful fallback. At the end of the day, it's
the client who pays the bills ^^;

With a "shrink-more-to-actually-fit" feature, this could have been
done via inline blocks, absolute positioning for the submenus, and
display:none vs. display:whatever based on :hover state. Without such
a feature, it turned out to be impossible to implement. Maybe using
inline blocks instead of the floats trick could have made 1) work, but
2) is currently unachievable without script.

Regards,
Eduard Pascual

Received on Saturday, 26 September 2009 09:46:57 UTC