Closed waldoj closed 11 years ago
It looks like the proper solution to this involves the white-space
CSS attribute. I've tried all of its values, and none of them are working correctly. Ostensibly, either white-space: pre
or white-space: nowrap
should do the trick, but I cannot get text wrap at hard carriage returns but not at soft returns.
Here are some sample URLs, where various examples of tabular data can be seen:
Just exempting tabular subsections from wp_texturize()
has done a lot of good. It's still going to be necessary to prohibit wrapping, but that might be the only change necessary at this point.
Although it's tempting to close this issue now (fixed-width documents are way narrower than the page width, so why have scrolling?), that would be a mistake. Given the responsive design, tabular data is going to look goofy on iPhones etc. when it wraps. So it's still necessary keep this material from wrapping.
This is a bit harder to test now, because of an artifact of the Code of Virginia. (Short version: It's poorly encapsulated in the faux SGML format in which it's provided, so <pre>
formatted sections can't be isolated (easily) to be marked up separately from surrounding text.) The only way to test it is with some mocked-up data. Hardly impossible, but a barrier.
At a width of 68 characters, which is the apparent maximum columnar width of Code of Virginia tabular data, the window has to be pretty wide to display the entire width of the text. And that's with 12px type. At 1024px of width, only 56 characters fit:
I have to get to 1185px before all 68 characters are displayed:
So that's the first problem.
The mysterious problem is that this doesn't result in overflow-x scrolling:
.law .primary-content pre.table {
margin: 0 0 20px 0;
font-size: .75em;
overflow-x: scroll;
white-space: pre;
}
Which I don't understand at all.
@boboroshi, any suggestions about how to handle this?
If these are tables, why are they not in table HTML elements?
The overflow-x doesn't work because overflow is funny. You can put "scroll" on the parent section, and give the PRE a fixed width (or ideally, min-width), but then the entire column scrolls. The content not in the Pre, however, wraps properly and does not continue under the sidebar.
Ideally, we could wrap these things in a better setup, HTML wise, and then just scroll THAT particular thing. I'd think of these forms similar to how <code>
blocks work on many blog sites for programming.
So, then we need a name. Is this really tabular data or is it more so pre-formatted content? If it's tables, we should put it in html Tables. If it's more complex, we need to come up with something better than pre class="table"
Calling them "tables" is an attempt to stick with the legal nomenclature. These are generally tabular data (though they can also be forms), but with the information is stored and presented as fixed-width data to basically simulate tables. I appreciate that, in terms of HTML, the term "table" is confusing, but I think it's probably the best term when balancing the interests of consistent legal terminology against the interests of unsurprising HTML terminology. (The <pre>
should be a strong hint to folks that this isn't a table in the HTML sense.)
You nailed it with your description of how <code>
blocks work on many blogs for inserting code. That's definitely what I'm going for here!
So i'd recommend mimicing the code setup but with a div (since it's completely presentational)
<div class="tabular">
<pre>
Stuff goes here!
</pre>
</div>
.tabular {
font-size: 0.75em;
margin-bottom: 1em;
overflow-x: scroll;
pre {
white-space: pre;
} // pre
} // .tabular
I wonder if we can devise a method of doing this without requiring that DIV wrapper? At least, a pure CSS method? It wouldn't be terrible to do this with a <div>
and then a <pre>
(law.php
takes care of this rendering step), and I think that'd be better than doing this via JavaScript.
Puzzling through this, I confess that I can't think of a method of accomplishing this. Sometimes you just need a container inside of a container (the ol' <span>[content]</span>
). :-/
Another option would be to use javascript and have any PRE tag fit with fittext.js: http://fittextjs.com
I dunno, that seems like a pretty stern warning on the site:
Oh, and don't you dare let us catch you using FitText on paragraph text. This is for gigantic display text only!
:)
Right, I'm out of ideas and trying to think outside the box :)
On Aug 1, 2013, at 2:32 PM, Waldo Jaquith notifications@github.com wrote:
I dunno, that seems like a pretty stern warning on the site:
Oh, and don't you dare let us catch you using FitText on paragraph text. This is for gigantic display text only!
:)
— Reply to this email directly or view it on GitHub.
Then we're definitely at the bottom of the barrel. <div><pre></pre></div>
it is! I'll push out a simple change to facilitate this.
I haven't touched the CSS or SCSS here—I'll leave that to you.
http://localhost:8080/59.1-284.13/ looks like the wrapper code is gone here
Oh good Lord—that was dumb of me. I made a change after testing and before committing. That's always a bad idea. :-/ Sorry about that.
The ball is in my court on this right now—I think re-parsing the code will fix it. (The <pre>
content isn't properly set apart with HTML.)
The problem actually lies with the Code of Virginia XML, not The State Decoded. Tabular data just isn't tagged as a table. This is for reasons stemming from the original source material, quasi-SGML LexisNexis creates that has some real shortcomings. I'm going to simply hand-edit the XML, to properly mark up a single table of data, and I'll share that resulting file. John, you can drop that in place of the existing XML file for that law in your import folder (/htdocs/admin/xml/
), and that'll give us all a sample to test on. I'm doing a test import of that modified XML now, and once everything's working properly, I'll pass along the file.
Yup, worked great. Here's a Gist that contains the XML file in question:
https://gist.github.com/waldoj/6225832
Just drop in that in place of your existing 59.1-284.13.xml
and re-run the parser (http://localhost:8080/admin/
) by emptying the database and parsing anew. When that's done, check out http://localhost:8080/59.1-284.13/ and you can see tabular data in situ.
Cool I'll give this a whirl tomorrow.
On Aug 13, 2013, at 5:24 PM, Waldo Jaquith notifications@github.com wrote:
Yup, worked great. Here's a Gist that contains the XML file in question:
https://gist.github.com/waldoj/6225832
Just drop in that in place of your existing 59.1-284.13.xml and re-run the parser (http://localhost:8080/admin/) by emptying the database and parsing anew. When that's done, check out http://localhost:8080/59.1-284.13/ and you can see tabular data in situ.
— Reply to this email directly or view it on GitHub.
:+1:
So, I've got the scrolling working, but unfortunately it's really hard to tell that you can scroll on most Macs, since they hide the scrollbar by default and the content is really long here. I'd recommend doing an inset-shadow here maybe? But for that, we'd need an extra wrapper around the pre
as previously discussed. Adding another class to the section
container would work as well if the whole contents of the section
will be in the pre
.
There actually is another wrapper, despite what you're seeing. I explain in the other issue.
Sorry for the less-than-perfect comment—I'm boarding a flight.
I'd say we do a right positioned fade graphic if that's the problem.
Ok, so the method in that article requires a lot of extra fluff, how about this as a pure CSS3 solution?
I'm fine with that if it looks right in the Class A browsers. Looks right :)
The contents of data tables can surely be rendered more nicely. Right now they wrap badly and generally don't look great. Get them to stop wrapping, and instead scroll side-to-side.