RE: Visual Studio 2010 - removing colspan from td

Discussion in 'ASP .Net' started by Chris, Jun 25, 2010.

  1. Chris

    Chris Guest

    I have the exact same problem - why does this happen and how can you turn it
    off?

    "" wrote:

    > Hi all,
    >
    > I have a table in the source view of an aspx. When i save the aspx,
    > visual studio immediately marks it all as changed and has removed all
    > occurances of colspan from my td tags. Anyone got any ideas?
    >
    > Cheers
    > --
    > D
    > .
    >
    Chris, Jun 25, 2010
    #1
    1. Advertising

  2. Chris

    jb Guest

    I have some good news and some *really* bad news on this....

    Firstly, the good news. The colspans are only removed where they are not
    necessary, and do not change the behaviour of the HTML. For example, if you
    have:

    <table>
    <tr>
    <td colspan="2"></td>
    </tr>
    <tr>
    <td colspan="2"></td>
    </tr>
    </table>

    they *will* (both) be removed as they may as well not be there. However, if
    you have:

    <table>
    <tr>
    <td colspan="2"></td>
    </tr>
    <tr>
    <td></td>
    <td></td>
    </tr>
    </table>

    the colspan will *not* be removed, as that would change the behaviour. In
    other words, I find they seem to get that right. You may not like them being
    removed for your own purposes, but it seems there's nothing you can do to
    stop it.

    Now the *bad* news. In doing the removal, VS sometimes "corrupts" your HTML
    (a bit higher up in the source) by simply removing a bunch of characters in
    an unrelated place, delivering simply incorrect HTML. Just for example, I
    had a line (which had nothing to do with the change):

    <td class="clsPartHeadBold" style="width: 100%">User Interface</td>

    and after VS had made its colspan changes later on, this line got
    "corrupted" to:

    <td class="clsPartHeadBold" styUser Interface</td>

    It's as though it's buffering(?) of lines simply went wrong, losing a number
    of characters.

    It seems this has something to do with size of the file and/or the
    complexity/nesting of the tables. The lines it will change vary depending on
    the content --- I cannot find any pattern. You guys may not have seen this
    yet, but believe me it's waiting for you as your file content changes....

    Worst of all, you have no idea this has happened. If you are "lucky" it
    will make your HTML syntactically incorrect, so you will notice it. If you
    are "unlucky" it will not cause an error but some of your content has been
    removed, and you may not notice it till it's too late....

    The only workaround is you have to go through every single colspan in your
    code and figure & remove the ones VS will remove, so that it will not do any
    removing of these itself. Then, you won't get the random corruptions.

    I would love to report this and have MS solve it, but I don't really know
    how to so that they will, especially since the only way I can reproduce is to
    give them big .aspx files of mine, as if I edit them down the problem can go
    away....

    For me, this is a horrendous bug, having just moved from VS 2005 (which was
    fine) and come across this once I start editing.
    jb, Jul 13, 2010
    #2
    1. Advertising

  3. Chris

    jb Guest

    I have a correction to make to my post above (in case anyone ever reads this).

    Firstly, I stick by what I said about the colspan-removal behaviour. They
    produce a "correct equivalent" --- the only time it would matter is if your
    runtime code added further rows and (thought it could) rely on the existing
    rows' colspans you typed in originally.

    But for the "corruption" I have *finally* tracked it down and it is *not* to
    do with changing colspans. Rather, my .aspx file had in one table:
    <tr></tr>
    i.e. an empty row *which contains no <td>s*. (This was not intentional: it
    may have been from a previous version of VS design-mode editing, or after
    hand editing). IN THIS CASE, VS2010 WILL CORRUPT UNRELATED LATER-TABLE-LINES
    WHENEVER YOU HAPPEN TO EDIT STUFF LOWER DOWN IN THE PAGE. Removing such an
    empty row (or putting in, say, a single <td></td>) thankfully solves the
    problem, thank goodness. Only took 2 days to discover this........
    jb, Jul 13, 2010
    #3
  4. Chris

    jb Guest

    I do not disagree with anything you say. (I presume by "table corruption"
    you mean that the colspan changes do not deliver the correctly laid out table
    in your circumstances, which is nowhere near as bad as actually chopping out
    random partial bits of HTML elsewhere in your document, as my problem is/was!)

    I was merely commenting, for those who read, that in, say, the plain case of
    a table with no dynamics/%ifs etc., its changes actually deliver the same
    table layout, rather than getting it wrong. We can guess that they must
    build their own representation of your table's rows & columns with your input
    colspans and then spit it back out with their "factored" colspans, all
    doubtless in the name of attempting to allow you to edit it. Yours is the
    only thread on the net discussing this behaviour, which has changed from
    previous versions.

    "" wrote:

    > Cheers for the info.
    >
    > However, this is an example of VS trying to be too clever. It can
    > result in table corruption as i have found when using <%if ...%>
    > statements surrounding parts of the table.
    >
    > Bottom line is VS should not automatically change my code - i would be
    > perectly happy with it flagging it and allowing me to change it if i
    > agree. Imagine if MS Office automatically changed your sentences
    > based on what the grammar checker deems to be correct.
    >
    >
    >
    > On Tue, 13 Jul 2010 09:30:15 -0700, jb <>
    > wrote:
    >
    > >I have a correction to make to my post above (in case anyone ever reads this).
    > >
    > >Firstly, I stick by what I said about the colspan-removal behaviour. They
    > >produce a "correct equivalent" --- the only time it would matter is if your
    > >runtime code added further rows and (thought it could) rely on the existing
    > >rows' colspans you typed in originally.
    > >
    > >But for the "corruption" I have *finally* tracked it down and it is *not* to
    > >do with changing colspans. Rather, my .aspx file had in one table:
    > > <tr></tr>
    > >i.e. an empty row *which contains no <td>s*. (This was not intentional: it
    > >may have been from a previous version of VS design-mode editing, or after
    > >hand editing). IN THIS CASE, VS2010 WILL CORRUPT UNRELATED LATER-TABLE-LINES
    > >WHENEVER YOU HAPPEN TO EDIT STUFF LOWER DOWN IN THE PAGE. Removing such an
    > >empty row (or putting in, say, a single <td></td>) thankfully solves the
    > >problem, thank goodness. Only took 2 days to discover this........

    > .
    >
    jb, Jul 14, 2010
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. wh
    Replies:
    2
    Views:
    505
    Cowboy \(Gregory A. Beamer\)
    Jan 16, 2004
  2. Thirumalai
    Replies:
    0
    Views:
    648
    Thirumalai
    May 22, 2006
  3. rockdale
    Replies:
    1
    Views:
    598
    Juan T. Llibre
    Aug 23, 2006
  4. xman
    Replies:
    0
    Views:
    481
  5. Saraswati lakki
    Replies:
    0
    Views:
    1,321
    Saraswati lakki
    Jan 6, 2012
Loading...

Share This Page