Quote:
Originally Posted by ElMiko
Yup. Just to be clear, the image i posted WAS with your original code (setting width to 76%). BUt as you say, with a narrow screen it'll split.
Would it be safe to summarize the three methods' pros/cons as:
1) (float method) Pro: displays relationship between bullet and text consistently and replicates list-style formatting. Con: variable bullet lengths will affect the left margin of the text.
2) (table method) Pro: displays relationship between bullet and text consistently and replicates list-style formatting. Con: very busy code.
3) (inline-block method) Pro: bullet length will not affect the left margin of the text. bullet and text element will separate on narrow viewing windows (e.g. cell phones).
...and then, additionally, all three lack the semantic/accessibility info of ol/ul list css.
Is there another "con" to the table method that I'm not articulating? I could've sworn that non-giant e-readers tend to struggle with tables...
|
Downsides for the table method off the top of my head:
It's semantically incorrect as it isn't tabular data. I think maybe a case could be made that the numbers for an ordered list and the elements of that list do kind of constitute a table-like matrix, but it's a stretch.
Anywhere your styling fails, like one-off, oddball reading apps, could display these with borders, whether you want em to or not. Like your chosen styling won't necessarily fail gracefully—if it fails, it'll be "what's going on here" to the reader.
Tables with very high row counts can cause problems for Kindle / KDP. And the platform may display them scaled down, with an icon meant for zoom/pan, which is an oddity you might like to avoid.
Tables are much more of a PITA to reconfigure than lists are, should you have to.
HTML tables default to column width adjustment based on the content within the cells in ways that are kind of unintuitive (to me). There are CSS controls for it, but like above, if they fail, there's going to be all sorts of numeral > list item spacing inconsistencies if you've got one list full of short items and another full of long ones.
I'd assume these don't have high column counts, being that they're actually lists, but a ton of columns is probably the root of the con you cited yourself re: screen size.
Personally, the semantic part is what would bug me most. And the markup hassle would be close behind it.