In case HTML changes the spec one day, again



  • Continuing the discussion from In case HTML changes the spec one day...:

    @Keith said:

    public const string HtmlRowTagIdAttribute = "id";
    public const string HtmlRowTagClassAttribute = "class";
    public const string HtmlRowTagStyleAttribute = "stlye";

    public static class HtmlHelper
        {
            public static string GetBeginTag(string tag, Dictionary<string, string> attributes)
            {
                using (var sr = new StringWriter())
                {
                    sr.Write(@"<{0} ", tag);
                    if (attributes != null)
                        foreach (var attribute in attributes)
                            sr.Write(@"{0}=""{1}"" ", attribute.Key, HttpUtility.HtmlEncode(attribute.Value));
                    sr.Write(@">");
                    return sr.ToString();
                }
            }
    
            public static string GetEndTag(string tag)
            {
                return string.Format(@"</{0}>", tag);
            }
    
            public static string GetTag(string value, string tag, Dictionary<string, string> attributes, bool encodeValue = true)
            {
                return string.Format("{0}{1}{2}", GetBeginTag(tag, attributes), encodeValue ? GetEncodedValue(value) : value, GetEndTag(tag));
            }
    
            public static string GetEncodedValue(string value)
            {
                return HttpUtility.HtmlEncode(value);
            }
    
            public class Tag
            {
                public const string Html = "html";
                public const string Body = "body";
                public const string Meta = "meta";
                public const string Head = "head";
                public const string Style = "style";
                public const string Table = "table";
                public const string Tr = "tr";
                public const string Td = "td";
            }
    
            public class Attribute
            {
                public const string Class = "class";
                public const string Style = "style";
            }
    
        }
    

    While I can get behind GetBeginTag, since it does the string building stuff, and maybe GetEndTag and GetTag make the code a bit cleaner, the rest is just... urk.



  • Booo, they spelled "style" correctly.



  • @Maciejasjmj said:

    ```
    public const string HtmlRowTagIdAttribute = "id";
    public const string HtmlRowTagClassAttribute = "class";
    public const string HtmlRowTagStyleAttribute = "stlye";

    
    Fuck me. That's literally the worst thing ever.
    
    **EDIT:** If I met the person who wrote this code I would literally punch them in the face and tell them to stop programming.


  • I'm still waiting for something like this, but with each string localized, to pop up here. Somebody must have done that.

    Filed under: Only tested under en_US!



  • To be the devil's advocate, in C# land this allows you to easily answer questions like "where am I using td tag?"
    Also, if a need arises, you can extend these simple consts into properties that might allow you to, for example, push out uppercase or lowercase tags or some shit like that.

    That said, I'd still go with just strings unless I had a REALLY good reason otherwise.



  • @cartman82 said:

    push out uppercase or lowercase tags or some shit like that.

    @cartman82 said:

    "where am I using td tag?"

    And that would be useful because...?



  • @cartman82 said:

    "where am I using td tag?"

    C:\codez> grep "\"td\"" *.cs?



  • @Keith said:

    Booo, they spelled "style" correctly.

    What about referer?



  • You really want that shit on a higher level though. Have a table object, an image object, etc... by the time you're serializing to HTML there's no reason not to hardcode.



  • Huh.

    The best thing about this code is that it's actually used to generate an .xls file... well, TIL Excel will open a HTML file containing a <table> and even parse it correctly (albeit with a "wrong format" warning).


  • SockDev

    @Maciejasjmj said:

    And that would be useful because...?

    The only reason I can think of is using the constant in several places in the code, so there's only one string instance. However, IIRC, the C# compiler finds all occurrences of string literals, and de-dupes them automatically, which renders the whole exercise pointless.

    So, yeah, it's not useful at all.



  • I've heard that for a long time our 'excel export' was a CSV file with an .xls extension. Excel would open this correctly and without warnings.



  • @cartman82 said:

    To be the devil's advocate, in C# land this allows you to easily answer questions like "where am I using td tag?"

    Why would you ever care about the TD tag specifically? (I could see asking, "where am I using tables?"


  • SockDev

    The only situation I can think of is using JS to live-update totals for an invoice (or a similar task). But then, if you're doing that, you should be using CSS classes in the form fields themselves, and iterating over them, not rooting through a multitude of <td>s.



  • @Maciejasjmj said:

    public const string HtmlRowTagIdAttribute = "id";
    public const string HtmlRowTagClassAttribute = "class";
    public const string HtmlRowTagStyleAttribute = "stlye";

    :wtf:

    This is literally the worst. What are they even thinking? Constants are supposed to be in all-caps.


  • SockDev

    @hungrier said:

    Constants are supposed to be in all-caps

    You're forgetting the underscores :stuck_out_tongue:



  • @RaceProUK said:

    The only situation I can think of is using JS to live-update totals for an invoice (or a similar task).

    But but but... but the search is in the C# code. He even says "in C# land" in his sentence.


  • SockDev

    @blakeyrat said:

    But but but... but the search is in the C# code. He even says "in C# land" in his sentence.

    Well, yes; doesn't change my point that looping through the <td>s in stupid.



  • @Maciejasjmj said:

    And that would be useful because...?

    @blakeyrat said:

    Why would you ever care about the TD tag specifically? (I could see asking, "where am I using tables?"

    Just an example. The point is, there's advantage to having things properly typed instead of strings.

    @PleegWat said:

    You really want that shit on a higher level though. Have a table object, an image object, etc... by the time you're serializing to HTML there's no reason not to hardcode.

    Fair enough. I guess it depends on how fancy you want to get.

    @tar said:

    C:\codez> grep ""td"" *.cs?

    //total distance
    var td = distance * count;
    

    Oops.



  • @cartman82 said:

    @tar said:
    C:\codez> grep ""td"" *.cs?

    //total distance
    var td = distance * count;
    

    Oops.

    Nuh-uh. What do you think the \" and \" are for?

    (Tested on Windows, COMPLAINS!)



  • @cartman82 said:

    Fair enough. I guess it depends on how fancy you want to get.

    There's cases where it's useful. An advantage of building objects first is that you can add components to containers before they are fully populated.

    Hardcoding entirely has its place as well. Softcoding tag names is absurd.



  • @cartman82 said:

    Just an example. The point is, there's advantage to having things properly typed instead of strings.

    Right; but C# has a XML/XHTML builder in its standard library which is already properly typed, so there's still no reason to do this asshattery.


  • SockDev

    IIRC, there are in fact two such APIs; one in System.Xml, the other in System.Xml.Linq (or System.Linq.Xml; I forget which way round it is).



  • @PleegWat said:

    I've heard that for a long time our 'excel export' was a CSV file with an .xls extension. Excel would open this correctly and without warnings.

    Are you sure? For .csv files that are indeed comma separated, Excel doesn't recognizes the columns, because it expects semicolon separated values. :wtf:



  • That depends on your locale (specifically, decimal separator). Of course there are apps which won't realize that and will happily shit over your data with commas in both roles (*cough* fuck you NVidia Profiler*cough*)



  • @Maciejasjmj said:

    TIL Excel will open a HTML file containing a <table> and even parse it correctly (albeit with a "wrong format" warning).

    I support systems that do "excel exports" using this and older versions didn't give the wrong format warning. When the customer upgraded to a version that did there were some unfun meeting trying to explain why they were now getting the warnings and what it would take to fix.



  • Quite possibly semicolons. I've only got it from hearsay - it wasn't a 'real' excel sheet. May well have been @locallunatic's table tags too.



  • Oh wow, so Excel is "smart" enough to know that in Hungarian, comma is a decimal separator, so if I find a CSV anywhere on the internet, it surely can't be comma separated :)



  • IIRC there's some place in excel where you can fiddle with the parameters for the .csv import



  • AFAIK, that's only on import. On open you're stuck with the defaults.



  • probably, it's been years since i used excel to do any csv related work



  • @Jarry said:

    it's been years since i used excel to do any csv related work

    Lucky.



  • It ain't too bad if you control the .csv, and spitting out .csv is probably the easiest way to quickly get an Excel sheet from a script or so. If you don't, well, better start praying...



  • @Maciejasjmj said:

    .csv is probably the easiest way to quickly get an Excel sheet from a script or so.

    I like scripting languages that can write .xls(x) directly.



  • @PleegWat said:

    CSV

    Just don't start your file with "ID"



  • @Maciejasjmj said:

    easiest way to quickly get an Excel

    Modern Excel tends to import HTML rather well ... dump it as a basic HTML table structure and it should import fine.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.