/    Sign up×
Community /Pin to ProfileBookmark

Tool: HTML (tables) to Css

If you haven’t see the Tables2CSS tool, you should definately check it out. [url]http://www.table2css.com/[/url]

to post a comment
CSS

21 Comments(s)

Copy linkTweet thisAlerts:
@Jeff_MottAug 02.2007 — I tried the online demo for these sites:[LIST]
  • [*]http://diffusionstudios.com/temp/tables/layout.php

  • [*]http://www.google.com/intl/en/about.html

  • [/LIST]
    And both came out very, [i]very[/i] messed up. I don't think anyone should invest any money in this product.
    Copy linkTweet thisAlerts:
    @ellisglauthorAug 02.2007 — I tried the online demo for these sites:[LIST]
  • [*]http://diffusionstudios.com/temp/tables/layout.php

  • [*]http://www.google.com/intl/en/about.html

  • [/LIST]
    And both came out very, [i]very[/i] messed up. I don't think anyone should invest any money in this product.[/QUOTE]


    Should post the issue on their forums. No reg needed.. I've had them correct a couple things. I haven't paid for it - Just been using the demo.
    Copy linkTweet thisAlerts:
    @Jeff_MottAug 02.2007 — Should post the issue on their forums.[/QUOTE]My concern was keeping the users here at Webdeveloper.com informed. You and anyone else interested may of course help to fix the program, but for now it simply doesn't do the job it says it will do:

    On those pages I tried, the HTML markup was [i]not[/i] reduced; the new pages were actually significantly larger. The markup was [i]not[/i] more helpful to search engines; you need to add meaningful, semantic tags to your content for that, and no computer program can do that for you. And the markup certainly wasn't less complex; some DIVs were nested ten levels deep.
    Copy linkTweet thisAlerts:
    @felgallAug 02.2007 — DIVitis is a worse disease than TABLEitis since those with divitis seem to think that they are doing the right thing by replacing tables with divs.

    Using the DIV tag inappropriately is just as wrong as using the TABLE tag inappropriately - more so because they replace one wrong table with a half dozen or so wrong divs.

    The correct markup is to identify what the component parts of the content are and that cannot possibly be done with a program.

    You should only use divs for the divisions within your page - header, footer, navigation, content etc and give them appropriate ids. The only time you should add div tags beyond that is in the rare situation where you need to mark up some content at a block level and an appropriate tag does not exist - in which case you should give the divs an appropriate class name.
    Copy linkTweet thisAlerts:
    @ellisglauthorAug 03.2007 — I usually use that tool to take a simple table to make my base CSS. Of course it's not perfect - but I know how to make the output better. I find it quicker to open dreamweaver up and make my table layout (I will argue that tables are faster to make vs.CSS most of the time because of dreamweaver) - toss it into this, modify the output it to my liking..

    While it's not 100% perfect - it does the job for me.
    Copy linkTweet thisAlerts:
    @CentauriAug 03.2007 — Using css is all about styling content, and as Jeff said, no program is going to be able to extract the content from nested tables and understand that content to apply the appropriate markup to start with.

    I will argue that tables are faster to make vs.CSS most of the time because of dreamweaver[/QUOTE]

    I too use Dreamweaver, and I would argue that when Dreamweaver is used as a tool, css layouts could be done faster. I first write the content, which you have to do anyway - that part of the job would have to be faster when you don't have to select table cells to write into. Dreamweaver makes the job of selecting appropriate tags easy by selecting an area of content and hitting the appropriate tag, whether it be heading, paragraphs, lists. etc. Logical divisions using divs are just as quick. From there, jump into the css panel and start styling - quite a quick and logical process, more so than setting up tables to start....
    Copy linkTweet thisAlerts:
    @vesselinOct 06.2007 — Hello all,

    Hopefully reviving a two-month old thread does not break the board rules (at least not that much) - I planned to answer this thread much earlier but

    could not find time until now to read the thread and to write a detailed reply.

    I am the author of the Table2CSS program - someone posted an excerpt from this thread on the Table2CSS message board, quoting a couple of bugs in the Table2CSS operation. First I want to thank guys that found and reported the issues - the bugreport helped a lot to improve the program. I would like to comment on the different issues mentioned by Jeff Mott as well as a few generic HTML markup issues mentioned by him and by the other posters.

    I tried the online demo for these sites:[LIST]
  • [*]http://diffusionstudios.com/temp/tables/layout.php

  • [*]http://www.google.com/intl/en/about.html

  • [/LIST]
    And both came out very, [i]very[/i] messed up.[/QUOTE]

    Indeed the version that you have tried (v1.1 or v1.2 I guess) had problems converting these two pages. Actually the issue with the page at diffusionstudios was aggravated by the fact that the page there dynamically checked the browser type and adjusted the doctype accordingly.

    All I can say in program's defense is that newer versions perform the conversion much better. Actually the converted page at diffusionstudios looks almost identical to the original. There are two quirks with that page however:

    1. Due to browser type sniffing performed by the page you should either convert the page using the URL as a source, or save the page with Internet Explorer and then convert the local file. Saving the page in some other browser and then converting the local file will cause page

    distortion.

    2. Due to the way external styles for that page are specified they will have precedence over embedded styles. So in order to get a good result from the conversion you should either specify inline styles during conversion or specify embedded styles, and then manually adjust the styles in the external css file.

    There are still issues with the google page (mainly due to text alignment inside the converted page) however these issues are much smaller than before.

    On those pages I tried, the HTML markup was not reduced; the new pages were actually significantly larger.[/QUOTE]
    The idea is to convert the page using embedded styles and then to move the resulting css style rules to an external file. If you do that the remaining HTML is smaller.

    The markup was not more helpful to search engines;[/QUOTE]
    Reduced file sizes are assumed to be better for search engines. Currently the program drops the <tr> tags so there are guaranteed less tags in the resulting HTML code. However I guess you could be right about the program version that you tried - it had some problems analyzing the HTML and for simpler HTML files it could easily create complex HTML code. Hopefully this problem is gone.

    you need to add meaningful, semantic tags to your content for that, and no computer program can do that for you.[/QUOTE]
    and
    and as Jeff said, no program is going to be able to extract the content from nested tables and understand that content to apply the appropriate markup to start with.
    [/QUOTE]

    When people say "semantic tags" or "semantic markup" they usually imply that there is also some kind of non-semantic markup. Which is simply not true. All HTML markup is semantic, the semantics of HTML tags are clearly defined in the HTML specification.

    What people actually mean when they say "semantic markup" is "not using divs/spans for modifying inner element styles or for positioning inner elements". There is also an assumption that automatic converters to "semantic markup" are impossible. This is simply not true. Such a converter is quite easy to write, actually this functionality can be crammed into table2css easily. However the real reason such tools do not exist is that there is no market demand for such tools. People that buy the converter are looking for a table2css converter, none has ever asked if the tool generates "semantic tags". And since there is no demand no one is taking the time to write such a tool.
    Copy linkTweet thisAlerts:
    @WebJoelOct 07.2007 — I tried this (some months ago) also, it is a cute toy. For someone whom doesn't know CSS, it may be of use. It has the potential to break a difficult TABLE-layout into a CSS-layout, but I found myself still reducing things even further. I am happy if users out there actually use this. But it's not for me.
    Copy linkTweet thisAlerts:
    @Jeff_MottOct 08.2007 — When people say "semantic tags" or "semantic markup" they usually imply that there is also some kind of non-semantic markup. Which is simply not true. All HTML markup is semantic, the semantics of HTML tags are clearly defined in the HTML specification.[/quote]Semantic means "with meaning." Tags such as H[i]n[/i], P and EM are semantic; they describe what the data is. Tags such as B and I describe what data should look like, but not what it is. (Is data italicized because it's a title? Because it's important? Because it's introducing a new word? Because a fictional character is thinking?)

    The guideline is: If a tag describes what data is, then it's semantic; it gives the data meaning. If a tag describes what the data should look like, then it's not semantic; the computer still can't know what the data means.
    Copy linkTweet thisAlerts:
    @ray326Oct 08.2007 — When people say "semantic tags" or "semantic markup" they usually imply that there is also some kind of non-semantic markup. Which is simply not true. All HTML markup is semantic, the semantics of HTML tags are clearly defined in the HTML specification.[/QUOTE]I wonder if you're not confusing syntax with semantics.
    Copy linkTweet thisAlerts:
    @vesselinOct 08.2007 — Semantic means "with meaning." Tags such as H[i]n[/i], P and EM are semantic; they describe what the data is. Tags such as B and I describe what data should look like, but not what it is. (Is data italicized because it's a title? Because it's important? Because it's introducing a new word? Because a fictional character is thinking?)

    The guideline is: If a tag describes what data is, then it's semantic; it gives the data meaning. If a tag describes what the data should look like, then it's not semantic; the computer still can't know what the data means.[/QUOTE]


    By giving the example above you imply that the emphasized text (the em tag) is more meaningful than the text in italic text style (the i tag). However the presence of the i tags already has enough information for the human reader to imply that the text in italics is more important than the surrounding non-italicized text).

    Lets say there is a simple program that mechanically searches through the HTML and replaces all i tags with em tags. According to the division of tags to semantic and non-semantic, the new text should be more semantic. And since i tags and em tags are used pretty much interchangeably we can be reasonably sure that the replacement is correct. So how come that a program that does not understand human text can magically add more meaning to this text? The only way to explain this is to assume that the old text using i tags is as meaningful as the new text using em tags.
    Copy linkTweet thisAlerts:
    @ray326Oct 08.2007 — However the presence of the i tags already has enough information for the human reader to imply that the text in italics is more important than the surrounding non-italicized text).[/QUOTE]That's a big assumption. Italic text is used by a lot of people simply to simulate handwriting or other purely presentational effects completely devoid of semantic meaning. In some cases they are used to indicate quotations, e.g., which is completely wrong given the presence of <q> and <blockquote>.
    Copy linkTweet thisAlerts:
    @vesselinOct 08.2007 — or other purely presentational effects completely devoid of semantic meaning[/QUOTE]
    What other "other purely presentational effects"? Do you mean effects like making the text stand out, i.e. [I]emphasizing[/I] it? ?

    In some cases they are used to indicate quotations[/QUOTE]
    Yes, in this case my fictional program would replace the incorrect <i> tag with the incorrect <em> tag. Still the text would not get less semantic - according to "semantic markup" supporters, the <i> tag is completely non-semantic so replacing it with something else could not remove any meaning since there is none.

    Regarding the handwriting argument - how could italic text mean handwriting when there is no semantics (meaning) behind the <i> tag, at least according to the semantic markup supporters. And why indicate handwriting via <i> and not via <em>? I think that emphasizing text is also a completely valid way of indicating handwriting.

    So in the end even if there is a small percentage of cases where replacing <i> with <em> is incorrect, my fictional program would still do great, in most cases correctly replacing the bad semanticless <i> tag with the good semantic <em> tag.

    My arguments above are meant to prove that you cannot say some tags are less semantic than other tags. All tags have some meaning, even the div and span tags which are considered semanticless tags have the meaning of grouping elements together.
    Copy linkTweet thisAlerts:
    @WebJoelOct 08.2007 — A '[I]semantic use[/I]' of a particular tag, -let's say "<blockquote>", belongs around the proper content, in this case, 'a long amount of block-level quoted text', -as in several sentences ,or a paragraph or more...

    This is an excellent example of 'it looks good!' versus 'is this really a long block of [I]quoted[/I] text?' (An actual client's testimonial springs to mind as an excellent example of what could be considered "[I]blockquote[/I]" material..).

    While visually, "blockquote" indents very prettily and looks sweet on the visual page, -a blind person whom is accessing the page using a [I]text-to-speech reader[/I] user-agent like JAWS maybe, gets 'told' that this is [I]blockquoted[/I] material. If it is NOT, then there is confusion for the blind person.. ? If used for visual-only appeal, the tag is used [U]incorrectly[/U]. What difference does this make to the average web page writer? Maybe nothing, but to a blind person reading the site, it is intellectually insulting to have material 'mis-labled'. That is the whole jist of proper use of 'semantic tags', to make the content [I]accessible[/I] & [I]understandable[/I] to [I]all[/I] (or as many as possible) user-agents by calling the content by what it really is.
    Copy linkTweet thisAlerts:
    @Jeff_MottOct 09.2007 — By giving the example above you imply that the emphasized text (the em tag) is more meaningful than the text in italic text style (the i tag). However the presence of the i tags already has enough information for the human reader to imply that the text in italics is more important than the surrounding non-italicized text.[/quote]It's not just the human that needs to understand what the data is. The computer needs to understand too.

    There's been an emphasis lately to make websites accessible to the handicapped, such as the blind community. But how should a voice synthesizer interpret the [i]I[/i] element? Italics has so many different meanings that a voice synthesizer must guess how the text should be spoken. And because it's purely guesswork with lots of room for error, voice synthesizers tend to just ignore italics.

    A tag that indicates emphasis, however, is much more clear: The voice synthesizer should speak emphasized text with a stressed tone of voice.

    The same is true for search engines. They don't have human eyes to see big and bold and centered. They only understand data--headings, quotations, hyperlinks, body text, etc.

    There are practical considerations for the developer as well. Consider:&lt;p&gt;All students &lt;i&gt;must&lt;/i&gt; explain how the formula calculates &lt;i&gt;c&lt;/i&gt;.&lt;/p&gt;Let's pretend several megabytes of web documents are marked up this way. But now the boss says, "We want more color. Can you make those emphasized words red?" We can't say [font=courier]i { color: red }[/font] because that includes other text. The only option is to go through every document to make the change.

    But if we used semantic tags (and used them properly), then we would have:&lt;p&gt;All students &lt;em&gt;must&lt;/em&gt; explain how the formula calculates &lt;var&gt;c&lt;/var&gt;.&lt;/p&gt;Now you can use CSS to make all emphasized text display a certain way, or all variables display a certain way. Semantic markup lets CSS be even more versatile than it already is.

    And these three things--accessibility to handicapped, meaningful data for search engines, and more versatile styling--is what makes CSS-based layouts with semantic markup (what some call CSS-P) so beneficial.

    Lets say there is a simple program that mechanically searches through the HTML and replaces all i tags with em tags. According to the division of tags to semantic and non-semantic, the new text should be more semantic.[/quote]Look at my first example code block again, with the <i> tags. How could a machine know whether the italics means emphasis or a variable? Or any of a dozen other uses for italics? If you figure that out, let us know.
    Copy linkTweet thisAlerts:
    @CentauriOct 09.2007 — Besides the problems with presentational tags as is being discussed above, there are more issues with the slice-and-dice graphics approach with the majority of table-based layouts.

    Take a typical table scenario - a coloured box containing a block of text and a picture, and the text is displayed in a fancy font. This would typically be done as a graphic, and to fit the complete layout, quite often sliced into two, three, or more, graphics contained within table cells. All a conversion program, such as the one being mentioned, can do with this is to place the graphics into floated divs - what has been achieved? Sliced graphics in divs is just as bad as the original table layout - it means absolutely [B]nothing[/B] semantically - screen readers can't read it, search engines can't index it. Such a scenario should really be marked up as a simple paragraph of text, with all presentational aspects (including replacing the text with graphical text if fancy-looking fonts are required) should be the job of the css - [B]NO[/B] conversion program is going to be able to analyse and properly mark this up, and this is one of the most common problems with old table layouts.

    Really, the only way of converting old table layouts to current semantic standards is to start from scratch, rewriting the [B]content[/B] using the most appropriate html elements to [I]describe[/I] that content, and [B]then[/B] apply the styling.
    Copy linkTweet thisAlerts:
    @vesselinOct 09.2007 — Italics has so many different meanings that a voice synthesizer must guess how the text should be spoken. And because it's purely guesswork with lots of room for error, voice synthesizers tend to just ignore italics.
    [/QUOTE]

    Do you have any data proving that? I just tried JAWS - the most popular speech synthesizer and I found two things:

    1. Of course it does not ignore italics. It even has a setting so you can configure how italics are pronounced.

    2. There is no way a screen reader could see the difference between <i> and <em> tags when reading the text from a browser window because browsers display <em> and <i> tags identically. Of course there could be some way to integrate JAWS with the browser but I did see it when browsing through the JAWS options.

    <em> does not seem more useful than <i> in this case.

    A tag that indicates emphasis, however, is much more clear: The voice synthesizer should speak emphasized text with a stressed tone of voice.[/QUOTE]
    And there is no problem speaking the italicized text with a different tone of voice.

    The same is true for search engines. They don't have human eyes to see big and bold and centered. They only understand data--headings, quotations, hyperlinks, body text, etc.
    [/QUOTE]

    There is no evidence that search engines value <em> tags more than <i> tags.


    There are practical considerations for the developer as well. Consider:&lt;p&gt;All students &lt;i&gt;must&lt;/i&gt; explain how the formula calculates &lt;i&gt;c&lt;/i&gt;.&lt;/p&gt;Let's pretend several megabytes of web documents are marked up this way. But now the boss says, "We want more color. Can you make those emphasized words red?" We can't say [font=courier]i { color: red }[/font] because that includes other text. The only option is to go through every document to make the change.

    But if we used semantic tags (and used them properly), then we would have:&lt;p&gt;All students &lt;em&gt;must&lt;/em&gt; explain how the formula calculates &lt;var&gt;c&lt;/var&gt;.&lt;/p&gt;Now you can use CSS to make all emphasized text display a certain way, or all variables display a certain way. Semantic markup lets CSS be even more versatile than it already is.

    And these three things--accessibility to handicapped, meaningful data for search engines, and more versatile styling--is what makes CSS-based layouts with semantic markup (what some call CSS-P) so beneficial.
    [/QUOTE]

    I could do the same trick using almost any other HTML tag (though I may need to add some CSS to neutralize its effects on the text formatting). For example I could use <span> for that purpose. So how does <var> suddenly become more semantic than <span> ?
    Copy linkTweet thisAlerts:
    @vesselinOct 09.2007 — Besides the problems with presentational tags as is being discussed above, there are more issues with the slice-and-dice graphics approach with the majority of table-based layouts.

    Take a typical table scenario - a coloured box containing a block of text and a picture, and the text is displayed in a fancy font. This would typically be done as a graphic, and to fit the complete layout, quite often sliced into two, three, or more, graphics contained within table cells. All a conversion program, such as the one being mentioned, can do with this is to place the graphics into floated divs - what has been achieved? Sliced graphics in divs is just as bad as the original table layout - it means absolutely [B]nothing[/B] semantically - screen readers can't read it, search engines can't index it. Such a scenario should really be marked up as a simple paragraph of text, with all presentational aspects (including replacing the text with graphical text if fancy-looking fonts are required) should be the job of the css - [B]NO[/B] conversion program is going to be able to analyse and properly mark this up, and this is one of the most common problems with old table layouts.

    Really, the only way of converting old table layouts to current semantic standards is to start from scratch, rewriting the [B]content[/B] using the most appropriate html elements to [I]describe[/I] that content, and [B]then[/B] apply the styling.[/QUOTE]

    Conversion of tables to divs+css is not intended to make the HTML code more semantic (whatever "semantic" means). The intention is to make the HTML at least a bit simpler. What you mentioned - floating divs is one option, but currently it does something different - positions the inner divs absolutely in the outer div. This way you can drop the <div> that should correspond to the <tr> element. Other optimizations are also possible, e.g. merging nested divs, e.g. in cases when we have a table with a single cell (this is not done currently), etc.
    Copy linkTweet thisAlerts:
    @vesselinOct 09.2007 — A '[I]semantic use[/I]' of a particular tag, -let's say "<blockquote>", belongs around the proper content, in this case, 'a long amount of block-level quoted text', -as in several sentences ,or a paragraph or more...

    This is an excellent example of 'it looks good!' versus 'is this really a long block of [I]quoted[/I] text?' (An actual client's testimonial springs to mind as an excellent example of what could be considered "[I]blockquote[/I]" material..).

    While visually, "blockquote" indents very prettily and looks sweet on the visual page, -a blind person whom is accessing the page using a [I]text-to-speech reader[/I] user-agent like JAWS maybe, gets 'told' that this is [I]blockquoted[/I] material. If it is NOT, then there is confusion for the blind person.. ? If used for visual-only appeal, the tag is used [U]incorrectly[/U]. What difference does this make to the average web page writer? Maybe nothing, but to a blind person reading the site, it is intellectually insulting to have material 'mis-labled'. That is the whole jist of proper use of 'semantic tags', to make the content [I]accessible[/I] & [I]understandable[/I] to [I]all[/I] (or as many as possible) user-agents by calling the content by what it really is.[/QUOTE]


    OK, I agree that misusing tags causes problems and never advocated for such misuse.

    Thanks to all for the interesting discussion. It is time for me to sign off from the discussion I guess I have already said all my arguments and I do not want to repeat myself :-)
    Copy linkTweet thisAlerts:
    @CentauriOct 09.2007 — Conversion of tables to divs+css is not intended to make the HTML code more semantic [/QUOTE]
    Well, it [B]SHOULD[/B] be... The whole point of css is to get the presentational stuff out of the html so that the html [B]MEANS[/B] something. Simply sticking the same crap into divs instead of table elements really achieves little.
    Copy linkTweet thisAlerts:
    @LeeUOct 09.2007 — Let's try to get back to the original topic: the Tables2CSS tool. Thanks.
    ×

    Success!

    Help @ellisgl spread the word by sharing this article on Twitter...

    Tweet This
    Sign in
    Forgot password?
    Sign in with TwitchSign in with GithubCreate Account
    about: ({
    version: 0.1.9 BETA 5.19,
    whats_new: community page,
    up_next: more Davinci•003 tasks,
    coming_soon: events calendar,
    social: @webDeveloperHQ
    });

    legal: ({
    terms: of use,
    privacy: policy
    });
    changelog: (
    version: 0.1.9,
    notes: added community page

    version: 0.1.8,
    notes: added Davinci•003

    version: 0.1.7,
    notes: upvote answers to bounties

    version: 0.1.6,
    notes: article editor refresh
    )...
    recent_tips: (
    tipper: @AriseFacilitySolutions09,
    tipped: article
    amount: 1000 SATS,

    tipper: @Yussuf4331,
    tipped: article
    amount: 1000 SATS,

    tipper: @darkwebsites540,
    tipped: article
    amount: 10 SATS,
    )...