Re: Wrapping delimited lists, fluid rows

Mikko Rantalainen wrote:
>> > Rules like
>> > 
>> > ul.menu li:after { content: " |  " }
>> > ul.menu li:last-on-line:after { content: none }
>> > 
>> > effectively create oscillation condition in the layout algorithm.
> 
> And exactly how this is different from :hover, for example?

Because mine is layout and his yours is runtime. Moving something on hover is 
plain stupid and you can't blame the developer for it.

But a layout approach that keeps moving the target around in circles while you 
try to render it is, sadly, a problem.

I am guessing he means that if removing the divider bar allows one more item to 
fit, last-of-line now moves across one, the divider bar now gets replaced, the 
last item on the line is kicked off, the divider bar is replaced, and so on.

Kinda screwy. I am sure you can cause oscillation with :float too but that would 
be a "runtime" failure that occurs under user action and would be resolved by 
simply moving the mouse away. It would also be an event-driven failure leaving 
the browser still able to process events.

Whereas a render-time oscillation failure would in effect crash the CSS 
rendering engine, since it would be locked in a state unable to decide how to 
draw anything.

He has a fair point. But I am sure it's not without solution. For example, 
making decisions in parallel, such that you check whether the dividing bar would 
  trigger such a condition, and then leaving the wrap as it is. But it could be 
unpleasant.

You might find that the solution lies in taking a totally different approach to 
solving the problem!

> Also, where does one end? If :nth-on-line() is added, perhaps we need
> :nth-word(), :nth-character(), :nth-pixel()?

hm ... When I read Wikipedia, I see a variety of typographical effects that just 
look broken when it comes to HTML. As I recall, writing this: "Please 
<em>en</em>able, not disable the setting" causes the word "enable" to be split 
into two words. I've wondered how we're actually meant to achieve effects like 
that. In spoken word it's OK, in print it's OK, but on the Web, it's not so 
good. (OK that wasn't the best example, but I have seen many good cases for 
highlighting merely part of the word).

I don't know how far we need to go. However, I just thought that being able to 
tell where an inline item is on a line, would not only help improve the 
appearance of horizontal navigation, but grant table-like border control to 
fluid grids.

There are of course many ways to decorate fluid grids that don't need this. One 
is a background colour on each cell. One is to put a border around each cell so 
that you have a grid.

But things you cannot do include putting a thicker outer border around the grid, 
e.g.

      #=======#=======#=======#=======#
      H       |       |       |       H
      H       |       |       |       H
      H       |       |       |       H
      H-------+-------+-------+-------H
      H       |       |       |       H
      H       |       |       |       H
      H       |       |       |       H
      H-------+-------#=======#=======#
      H       |       H
      H       |       H
      H       |       H
      #=======#=======#

When your 10-cell grid is merely this:

  <ul class="fluidgrid">
   <li> ... </li>
   <li> ... </li>
   <li> ... </li>
   <li> ... </li>
   <li> ... </li>
   ...
  </ul>

Which cells start the rows? Which cells end the rows? Which cells are on the 
first and the last rows?

(Yes, the missing cells at the bottom make life even more fun, since "bottom 
row" and "at the bottom" are not the same thing ;-)

Another simple example is when you want alternating rows. For example, with a 
table you may wtite this:

  tr:nth-child(2n) > td { background-color: #DFD }

Rows in a table are addressable. Rows in a fluid grid are virtual and cannot be 
addressed.

CSS3 does a great job of giving us all manner of nice table formatting, but I 
firmly believe that non-tabular data -- where there is zero semantic value to 
the rows and columns and we're only interested in presentation -- does not 
belong inside a <table> tag. display: table helps as long as we're content with 
the number of columns, but I submit that it's not reasonable to ever assume how 
many columns to use. Particularly as we usher in more and more smaller-screen 
devices, it makes the life of the browser, and user, much easier if it doesn't 
have to rip tables to pieces to shove them down a narrow screen, or force the 
user to scroll left and right to view all the content.

And alas, by throwing away table presentation, we also lose, for now, a lot of 
our control over grid presentation.


How far this should go, such as :nth-pixel, depends on whether you can find a 
compelling use case

Received on Monday, 26 February 2007 13:59:13 UTC