Re: [PHP] Re: table-less layouts; Ideas welcome
Paul M Foster wrote: [snip] I wish someone had thought of a similar thing for databases. From the beginning, there should have been a spreadsheet-like interface for databases. This could have saved endless trouble, since for lack of this, people store database information in spreadsheets. And then wonder why they can't do this or that with it. Argh. Paul Build one... replicate google docs features using AJAX,PHP (or any server-side language) and CSS etc.. then share the source with us. ;-) Seriously, Regarding spreadsheet or table data, (and fileMaker)... I just have to chime in here... There are many reasons, especially in the web world, where a more simple table-like database, with excellent access features are perfectly appropriate, as well as a breathe of fresh air to the developer. Imagine being able to copy/paste an excel file (lets say a list of test scores) into a text editor, save it to the server, and then being able to access that text file via a web page with the following (simple) code in the body: -- [search db=exceldata.dbgeTESTSCOREdatarq=90TESTSCOREtype=num] These students had scores greater than 90%br [founditems] [name]br [/founditems] [/search] -- The output looks like this(when visiting that web page): These students had scores greater than 90% Paul M Foster Michael A. Peters Ashley Sheridan Robert Cummings When I hear knocks regarding people making fun of table data, I just laugh to myself and know that I'm getting about 20 times the work done that these folks are. ;-) Nothing against MySQL, but my point is: use the right tool for the right job. FileMaker was/is slow, but there are other tools out there that work great and are fast. ;-) Donovan -- =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o D. BROOKE EUCA Design Center WebDNA Software Corp. WEB: http://www.euca.us | http://www.webdna.us =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o WebDNA: [** Square Bracket Utopia **] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: table-less layouts; Ideas welcome
On Sat, 2009-05-23 at 22:23 -0700, Michael A. Peters wrote: Paul M Foster wrote: I wish someone had thought of a similar thing for databases. From the beginning, there should have been a spreadsheet-like interface for databases. This could have saved endless trouble, since for lack of this, people store database information in spreadsheets. And then wonder why they can't do this or that with it. Argh. If I'm not mistaken, Filemaker Pro on Apple was that way back in the OS 7.6 days. The only thing worse than using spreadsheets for databases is using word processors for screenshots! Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: table-less layouts; Ideas welcome
Have anyone of you checked the table to div converter class from www.phpclasses.org ?
Re: [PHP] Re: table-less layouts; Ideas welcome
At 9:08 AM -0400 5/23/09, Robert Cummings wrote: Ya know... the people over at HTML standards design cold have saved the world a large number of headaches by just adding a new attribute to tables: table type=layout Then everyone layout table out there would have been valid by the simple addition of this attribue, backward compatible with older browsers, understandable by future screen readers, and much less hassle in general. But, I guess they were lacking some insight there. Instead we got a CSS spec to support table layouts that depended on the asshats over at Microsoft adding support, required all browsers at the time be upgraded, and today is pretty much useless in a global perspective. I'm all for standards, we could have even overlapped this system with CSS support so that when the browser support ultimately came, the switch would be simple. But no, simplicity would have been far too easy for everyone to swallow. Rob: Ain't that the truth. On one side, people who had very little programming skills took advantage of the HTML language through WYSIWYG editors and created something that solved their needs. On the other side, the same people who didn't foresee the problem when they created the language ignores the obvious need for layout and then further complicates the issue by redefining tables and requiring a css solution. They could have easily sought a simple solution such as what you suggested. I often think there should be a grid of some sort to allow people to construct a layout without having to consider the more problematic css positioning and float rules. What better solves that layout problem than a table? Opportunities lost. Ps. sorry for disappearing from this thread, I had a funeral to attend and had no internet for a week... yes I'm still shaking from withdrawal ;) Sorry about the funeral -- I hope there was nothing seriously wrong. :-) Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: table-less layouts; Ideas welcome
Paul M Foster wrote: I wish someone had thought of a similar thing for databases. From the beginning, there should have been a spreadsheet-like interface for databases. This could have saved endless trouble, since for lack of this, people store database information in spreadsheets. And then wonder why they can't do this or that with it. Argh. If I'm not mistaken, Filemaker Pro on Apple was that way back in the OS 7.6 days. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: table-less layouts; Ideas welcome
Jim Lucas wrote: Since this has been a topic of dicussion, I figured I would add my thoughts. I have been toying with the idea of doing a table-less layouts involving tabular data, calendars, etc... Why? Recent threads have finally made me do it. Let me know what you think. http://www.cmsws.com/examples/templates/div_tables.php http://www.cmsws.com/examples/templates/div_tables.phps (source for above) http://www.cmsws.com/examples/templates/div_cal.php Looks clever, but unfortunately it solves a problem which does not exist. In other words, and with all due respect: useless. When you turn off the styles, the calendar becomes pretty rough on the eyes, but still accessible. Same thing with the tabular data structure. But, not knowing how the various types of accessibility applications work, I am guessing that the layout to an application trying to read it should work fairly well. Let me know if I am way off the mark with my thoughts. Yes. table tags are intended to represent tables. It's as if the authors of HTML foresaw a need... ;) Browsers render them quite well. They are valid in all versions of HTML including HTML 5. Why not use them? The evil of tables is in abusing them for layout purposes. Where entire pages are inside tables. Where you find tables inside table cells of other tables (I've seen them nested 6, 7 levels, no kidding). It goes against fluidity, accessability, maintainability, and everything that's sane and right. Tableless design means you abstain from such table abuse, that you do not use tables for enforcing layouts. Not that you get rid of tables altogether. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: table-less layouts; Ideas welcome
On 5/21/09 5:06 AM, O. Lavell olav...@xs4all.nl wrote: Jim Lucas wrote: Since this has been a topic of dicussion, I figured I would add my thoughts. I have been toying with the idea of doing a table-less layouts involving tabular data, calendars, etc... Why? it's a zen practice. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: table-less layouts; Ideas welcome
On 21/05/2009 10.02, Jim Lucas wrote: Since this has been a topic of dicussion, I figured I would add my thoughts. I have been toying with the idea of doing a table-less layouts involving tabular data, calendars, etc... Recent threads have finally made me do it. Let me know what you think. http://www.cmsws.com/examples/templates/div_tables.php http://www.cmsws.com/examples/templates/div_tables.phps (source for above) http://www.cmsws.com/examples/templates/div_cal.php When you turn off the styles, the calendar becomes pretty rough on the eyes, but still accessible. Same thing with the tabular data structure. But, not knowing how the various types of accessibility applications work, I am guessing that the layout to an application trying to read it should work fairly well. Let me know if I am way off the mark with my thoughts. If you want to respond off list, that if fine by me. TIA Table-less html is a silly idea. Semantic html where tables represent tables makes sense instead. A calendar IS a table, semantically speaking, so emulating it with css-p is useless torture. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: table-less layouts; Ideas welcome
On Thu, 2009-05-21 at 09:54 -0400, tedd wrote: My thoughts are -- my understanding the reason why tables have received such bad-press is that designers have abused tables in holding designs together with nested tables AND in doing so made it difficult for the visually disabled to pull content from the site. Screen readers do not read the screen but rather read the source and pull out of it what they (the screen reader program) think is content. Translating nested tables becomes an impossible job for them. I've heard a rumor this is exaggerated, and I buy it to some extent. Lynx had an algorithm for distinguishing simple tabular data from more complex (and probably layout) tables back in 1999. I'd assume a serious screen reader with more development resources behind it could do better, and I don't think heuristics for working with this would even be particularly hard. This isn't to say tangled table markup is never a problem. It is, both for human and machine readers. But as much as I like CSS -- and as much as it simplifies many designs -- there are some cases for which table layouts are easier and/or more robust, so I almost just wish we'd accepted the horse was out of the barn and tried to figure out an easy way to signal distinctions between layout tables and semantic tabular data, rather than trying to get the entire internet to completely retool. A few years ago, I started marking my layout tables with class=layout. Not always a perfect solution, but makes the distinction easy (and turns out to be a useful styling convention as well), and if table-based layouts really are a significant obstacle to machine readers, my guess is something like this would get us over that hurdle a lot faster than waiting for everyone to give up those layouts. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: table-less layouts; Ideas welcome
At 11:48 AM -0600 5/21/09, Weston C wrote: On Thu, 2009-05-21 at 09:54 -0400, tedd wrote: My thoughts are -- my understanding the reason why tables have received such bad-press is that designers have abused tables in holding designs together with nested tables AND in doing so made it difficult for the visually disabled to pull content from the site. Screen readers do not read the screen but rather read the source and pull out of it what they (the screen reader program) think is content. Translating nested tables becomes an impossible job for them. [1] I've heard a rumor this is exaggerated, and I buy it to some extent. Lynx had an algorithm for distinguishing simple tabular data from more complex (and probably layout) tables back in 1999. I'd assume a serious screen reader with more development resources behind it could do better, and I don't think heuristics for working with this would even be particularly hard. [2] This isn't to say tangled table markup is never a problem. It is, both for human and machine readers. But as much as I like CSS -- and as much as it simplifies many designs -- there are some cases for which [3] table layouts are easier and/or more robust, so I almost just wish we'd accepted the horse was out of the barn and tried to figure out an easy way to signal distinctions between layout tables and semantic tabular data, rather than trying to get the entire internet to completely retool. [4] A few years ago, I started marking my layout tables with class=layout. Not always a perfect solution, but makes the distinction easy (and turns out to be a useful styling convention as well), and if table-based layouts really are a significant obstacle to machine readers, my guess is something like this would get us over that hurdle a lot faster than waiting for everyone to give up those layouts. Weston: With regard to [1] -- while it might look like a simple problem to solve, let me present a simple example to show it's not. Above is your text -- let's say that I create a table that is a simple 2 x 2 table. It's a table that has two rows and two columns. Now, let me place your text in that table like so: 1 | 2 3 | 4 Or, I could do it like this: 1 | 3 2 | 4 Could you be certain that your algorithm would figure out which way it needs to present the text to a blind person? Remember, it should present the text in the correct order, namely 1, 2, 3 and 4. However, newsprint and layouts often uses both types of presentation. Now compound that with cells holding images, place-holders, empty cells and cells with navigation elements, flash, videos, and such -- and you might have a better appreciation as to the problem screen readers face. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: table-less layouts; Ideas welcome
On 21/5/09 18:48, Weston C wrote: I almost just wish we'd accepted the horse was out of the barn and tried to figure out an easy way to signal distinctions between layout tables and semantic tabular data, rather than trying to get the entire internet to completely retool. One year after HTML 4.0 recommended stylesheets over table layouts, WCAG 1.0 (published in 1999) explained how /authors/ could distinguish between layout tables and data tables: 1) When writing a presentational table, stick to the elements table, tr, td. Do not use the headers, scope, axis, or summary attributes. Make sure layout tables make sense when linearized. 2) When writing a data table, add the elements th, thead, tbody, tfoot, caption, and col and the attributes headers, scope, axis, and summary wherever appropriate. http://www.w3.org/TR/WCAG10/#gl-table-markup No algorithm for guessing whether a table matching the first class (but which could have been authored before WCAG 1.0 or in ignorance of WCAG 1.0) is a layout or data table has ever been specified, as far as I know. You are entirely correct that text browsers and screen readers do indeed use such algorithms, however. This is why it's more crucial to use data table markup for data tables than to avoid presentational table markup for grid layout. Fast forward a decade, and authors are getting another tool in our toolbox, not a million miles away from your 'class=layout'. I don't think it's very well specified yet, but: http://www.w3.org/TR/wai-aria/#presentation -- Benjamin Hawkes-Lewis -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: table-less layouts; Ideas welcome
On Thu, May 21, 2009 at 12:10 PM, tedd tedd.sperl...@gmail.com wrote: Could you be certain that your algorithm would figure out which way it needs to present the text to a blind person? My own experience browsing the web with Lynx (which for the most part, tends to ignore table layout, giving you the content of table cells in source order) suggests that order doesn't end up being a significant issue. The common layouts tend to read surprising well in source order. Navigation is usually at the top or the left, so you encounter it quickly. If there's any problem, most of the time it's that the page author has done something hideous with a lot of images with no alt text or abuse of HTML entitites, or part of the navigation structure is only accessible via javascript or flash or something like that... all separate issues from repurposing tabular markup. And when there *is* some kind of a layout issue, most of the time it's easy to adapt as a human reader by searching/scanning (sometimes easier than if you're looking at a bad visual layout). The tools that enhance accessibility on a page in these respects really don't have a lot to do with whether there's tabular markup -- if you want to enable easy access to page navigation, you can add semantic information about that regardless. In fact, that information is quite likely more important and less prevalent than what you end up with even most CSS-positioned sites, given that the vast majority of them simply provide stylesheets for the purposes of... visual layout, and what you're left with when a screen reader ignores them is linear source-ordered elements. None of this is to say that CSS can't be very useful in addressing this problem (and other problems), or that there aren't some problems with tabular markup. The presentation example you mentioned is actually going to be an issue with even real tabular data without some care taken in the markup. And I don't want to go back to coding 1999 markup for 1999 browsers. Mostly my point is that the problem with using tables is a bit more limited in size than it's often made out to be, there are other ways of dealing with the accessibility and semanticity issues involved, some of them potentially more effective. And for some cases, table layouts just work better. I think we'd be better off with a wide variety of professionals who can balance these different issues than with a tables considered harmful summary. Now compound that with cells holding images, place-holders, empty cells and cells with navigation elements, flash, videos, and such -- and you might have a better appreciation as to the problem screen readers face. These are actually some of the heuristic markers I believe some browsers actually use (and if they don't, they certainly could). If you have a table whose cells largely contain highly mixed markup, largely presentational elements, no alternative data, chances are pretty good that it isn't tabular data. And... Benjamin Hawkes-Lewis bhawkesle...@googlemail.com WCAG 1.0 ... explained how /authors/ could distinguish between layout tables and data tables: 1) When writing a presentational table, stick to the elements table, tr, td. Do not use the headers, scope, axis, or summary attributes. Make sure layout tables make sense when linearized. 2) When writing a data table, add the elements th, thead, tbody, tfoot, caption, and col and the attributes headers, scope, axis, and summary wherever appropriate. Exactly. These are great markers for distinguishing between where authors were using table markup semantically or presentationally. I think in practice there are probably many others available. Fast forward a decade, and authors are getting another tool in our toolbox, not a million miles away from your 'class=layout'. I don't think it's very well specified yet, but: http://www.w3.org/TR/wai-aria/#presentation I'm actually amazed... this is very nearly what I proposed in some discussions back in 2004. I eventually shifted to class=layout because it had some other practical benefits and everybody I talked to seemed to feel cluttering up the attribute space with yet another item was wrong (on top of this sortof general malaise about repurposed table markup), especially when considering how much semantic mileage you can get out of class attributes. I'd be totally happy to see anything like it adopted, though, and as I said before, think it'd push the semantic web forward faster than waiting for everyone to come around to doing things one blessed way. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
