Skip to main content ↑ ↓
Topic: XML Hangovers (Read 11734 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

XML Hangovers

Since the code we adopted was at one point xhtml valid, we of course have a lot of xml style markup in it.  I think xml was good in that it was a more restrictive in what was valid markup, html5 however lets you do all matter of things and its still valid, not that I am saying lets do that.

The templates still validate to html5 with these items, but this is a question of what standards do we want to use in the markup, past the obvious stuff like lowercase tags etc.  Below are some of the items I'm specifically thinking about.

So things like
  • void (self closing) tags with />  such as input, br, hr, img, link, meta  I think we can loose that extra / in all of those, and TBH I think we already have a mixed bag of those.  The html5 spec says those are ignored in those cases.
  • Empty attribute syntax such as checked="checked", disabled="disabled", selected="selected", others?  Anyway we should be able to use the one  word to indicate that status checked, selected, disabled without the ="sameword" , that also appears to be from xml and I thnk the one word syntax looks cleaner
  • <script> <!-- // --><![CDATA[ script code //]]></script>  I don't think the cdata items are needed unless we want to validate as xml not to mention I think it looks hideous :P
  • Others?

Re: XML Hangovers

Reply #1 –

Did all that years ago. Never looked back ;)
Go for it, but it'll take you weeks to get it all right. I know I didn't expect it to take so long.
As for data, I learned years after that that I could remove them in HTML5. That, was easier ;)

Re: XML Hangovers

Reply #2 –

I've never been a big fan of html (TBH), always preferred xhtml, but I have no objections! ;)

Kill all of them with fire!!
Bugs creator.
Features destroyer.
Template killer.

Re: XML Hangovers

Reply #3 –

Quote from: emanuele – I've never been a big fan of html
same here.. took me years to properly use the XML syntax and now I should go back? LOL.

PMs and messages need to be processed in some way, could do that via Importer....
Thorsten "TE" Eurich
------------------------

Re: XML Hangovers

Reply #4 –

Html5 was already 'the thing to do' back in 2009-2010... we're in 2014 and it's time to do the right thing and make elkarte use less bandwidth... SMF will do it too, eventually, I'm sure Pete won't refuse to go html5 just because I did it that way in Wedge :P

Also, json >= xml but I'm not feeding another troll! ::)

Re: XML Hangovers

Reply #5 –

Is it really sooo important to save some bytes? I don't believe it's more than just a few Megabytes in a month, even for a bigger sized board...

I personally prefer the XHTML5 syntax but I don't care that much  using one or the other for Elk, thus I'd bow to the majority.
Thorsten "TE" Eurich
------------------------

Re: XML Hangovers

Reply #6 –

I don't have any real issue with leaving things xml-ish, just wanted to see what others felt on the matter, so I / we could be consistent  :D  Kind of like how we format our php code, lots of options.  Sounds like we are happy with lowercase code, quoted attributes and trailing slashes on void elements. 

I may still remove the cdata stuff form the script tags, its not like we are serving the pages as xhtml, nor do I think we would again.  In fact from reading some the the processing deltas between html xhtml we use some tags that would cause problems, and some js that would also.

Re: XML Hangovers

Reply #7 –

I go with HTML5. Sometimes I'll use the slash and sometimes I'll do checked="checked". Either way, so long as it validates as HTML5, I don't waste time (unless I'm bored) making any changes.

Re: XML Hangovers

Reply #8 –

I was probably carried away by the "others?" and my comment to the xhtml-ihs was more related to actually close or not the tags (that is a possibility in html5), about the self-closing I'm neutral Spoiler (click to show/hide)

I'm not really neither in favour nor against.

Well, the checked="checked" and alike always bothered me a bit (sounds dumb).
Anything else... do what you prefer! O:-)
Bugs creator.
Features destroyer.
Template killer.

Re: XML Hangovers

Reply #9 –

Well its valid as is, and I am lazy .... humm what to do what to do :D

Re: XML Hangovers

Reply #10 –

Quote from: TE – Is it really sooo important to save some bytes?
Of course it's important. Isn't it important to you guys..?

QuoteI don't believe it's more than just a few Megabytes in a month, even for a bigger sized board...
And that few megabytes may cost you extra.
HTML size is important because it's not something that's of concern for the visitor OR the server -- it's of concern for both. If you're visiting from mobile, you'll be glad someone thought of making the pages you're visiting regularly lighter, so that you don't go over your data limit. If you're sending from a small-sized server, you'll be glad your website held out for an extra 30 seconds the day you got slashdotted. Oh, it all adds up. It's not 'just' the removal of bits here and there. It's a philosophy. If you keep at it, you'll get good results. I did a quick compare of two topic pages taken from Wedge and ElkArte. I removed all content to make it fairer to compare, of course. I also removed all code pertaining to admin and Wysiwyg quick reply (which isn't enabled here, and can be disabled there). The Elk page is 23KB, and the Wedge page is 16KB. Even after gzipping (Wedge isn't as good at gzipping because it's already optimized for size and doesn't have many repeated patterns), it saves about 400-500 bytes per page load. On a relatively low-traffic forum like ElkArte's or Wedge's, that makes for about 500KB to 1MB per day in wasted data. So, between 15 and 30MB per month. And that's only for the gzipped HTML. Then you get the CSS and JS, and other things like that. A bandwidth-conscious admin would be well advised to stay clear from SMF (or most forum software for that matter), but I certainly wouldn't like to say that Elk isn't bandwidth-conscious.
I'll admit that I went a bit overboard on bandwidth matters over the years (what you could call premature micro-optimization), and it often managed to upset others. But you don't have to be a bytenazi to recognize the virtues of saving space. Don't brush off my hints just because of my ODD behavior, there's certainly a solid middle ground somewhere in there. ;)

Oh, speaking of ODD...
data-icon="some entity;" (<-- it got turned into an actual entity by the editor, and I don't remember the number)
That's in unread_something (can't remember either), and I'm only pointing it out because it has a semi-colon, while other data-icon occurrences don't. It feels... uncomfortable. (Please save this byte. Just look for data-icon in your code and find the one with a semi-colon.)

QuoteI personally prefer the XHTML5 syntax but I don't care that much  using one or the other for Elk, thus I'd bow to the majority.
XHTML had its use many years ago, in the battle against tag soups and <,PEOPLE NOt knoZING='howTo..WRIte"code=butitwazalongtimeago.>
Still, respect.

Shout out, XHTML! You made our lives better for a while, but you're not my !DOCTYPE anymore.

Re: XML Hangovers

Reply #11 –

QuoteOh, speaking of ODD...
data-icon="some entity;" (<-- it got turned into an actual entity by the editor, and I don't remember the number)
That's in unread_something (can't remember either), and I'm only pointing it out because it has a semi-colon, while other data-icon occurrences don't. It feels... uncomfortable. (Please save this byte. Just look for data-icon in your code and find the one with a semi-colon.)
thanks for the report, is already fixed in our repo :)
Thorsten "TE" Eurich
------------------------

Re: XML Hangovers

Reply #12 –

QuoteOh, speaking of ODD...
data-icon="some entity;"
Woops that was ME  :D I'm just a lemming of the validator !

Agree on working to make the pages lower in weight, we still have extra heft in the markup, and still some in line style stuff to sniff out and on some lesser used pages blocks of inline script, etc, etc, lots of opportunity :D  When I think about the amount of that we have already removed, its staggering really

Re: XML Hangovers

Reply #13 –

It certainly does feel faster than SMF2 already, although it's hard to compare apples and oranges (was that the proper expression?) when they're on two different servers.

Re: XML Hangovers

Reply #14 –

If any admin is worried about 100 bytes per page, they are ridiculous. An image alone is many KB. If they're concerned with it, I say let them rewrite all of the themes. This is 2014, not 1976; the bandwidth of any hosting plan is of a large enough size and capacity that it doesn't matter.

Just do what makes development easier. If you worry about minutia, you'll turn off developers. When you turn off developers, you become stagnant. When you become stagnant, you don't get or don't retain users.