HTML5 support

Nao

  • Dadman with a boy
  • Posts: 16,029
HTML5 support
« on May 6th, 2011, 05:12 PM »
Feature: HTML5 support
Developer: Nao
Target: themers, modders, users
Status: 95% (complete, but by definition this will never be finished. Also, support in progress in media area.)
Comment:

Adds full support for the HTML5 specs in Wedge (except where XML compatibility is required: XML queries, wireless, etc.)
Most notably, IE 6/7/8 users automatically get the 'html5shiv' shim which enables styling the new tags. The default theme uses some of these tags as well.
To save bandwidth, all self-closing tags were updated to use the simplified syntax (<br> instead of <br />, etc), deprecated attributes (type=text/css, type=text/javascript...) were deleted, and valueless attributes had their XHTML value removed.
All pages fully validate the experimental HTML5 validator at validator.w3.org. If you ever find a page that doesn't validate, make sure to tell us -- we will promptly fix it.

Re: HTML5 support
« Reply #1, on February 6th, 2013, 01:46 AM »
Quote from Nao on May 6th, 2011, 05:12 PM
All pages fully validate the experimental HTML5 validator at validator.w3.org. If you ever find a page that doesn't validate, make sure to tell us -- we will promptly fix it.
Don't want to worry anyone, but on wedge.org no page seems to be valid. Mostly easily fixable errors though.

Re: HTML5 support
« Reply #2, on February 6th, 2013, 02:03 AM »
According to what validator, exactly?

Have they changed their minds (again) about what is valid and what isn't? As it is, we're waiting for them to change their minds, yet again, about certain attributes being required when a certain meta tag is (or is not) present.

Re: HTML5 support
« Reply #3, on February 6th, 2013, 02:03 AM »
The errors are related to missing alt parameters. And on this matter W3C changes idea every day.. I wouldn't worry (also because less alt="" means less bytes).

Edit: posted together :D

Re: HTML5 support
« Reply #4, on February 6th, 2013, 02:05 AM »
OK so I hit up the w3.org validator which by its *own* admission is experimental.
Quote
No Character encoding declared at document level
Yeah, there isn't. We do it at header level (the best place for it)

All the rest are img elements not having (empty) alt attributes. Which is the issue we're waiting for them to change their mind on again. Essentially the argument relates to whether an alt attribute is 'required' or merely 'recommended' (but thus optional), and when a meta generator tag is present, it changes whether it is required or not. But they're only just opening a discussion to discuss reconsidering their position, so it might take a while.

Re: HTML5 support
« Reply #5, on February 6th, 2013, 02:07 AM »
What's the relation between a generator meta tag and alt attributes? :P
They're mad

Re: HTML5 support
« Reply #6, on February 6th, 2013, 02:12 AM »
Quote from Arantor on February 6th, 2013, 02:03 AM
According to what validator, exactly?
The one from the w3c
Quote
Have they changed their minds (again) about what is valid and what isn't? As it is, we're waiting for them to change their minds, yet again, about certain attributes being required when a certain meta tag is (or is not) present.
Didn't know that :lol:
But they are not the only ones: if you try to validate this thread, the first error is "Line 66, Column 31: Element div not allowed as child of element h4 in this context. (Suppressing further errors from this subtree.)".

There are some more, but they hide between the alt attribute errors.

Re: HTML5 support
« Reply #7, on February 6th, 2013, 02:16 AM »
Essentially it was some nonsense about automated tools generating code and if there was a generator indicated, it would relax certain validation rules or something. Nao mentioned it, I just threw my hands up with a WTF gesture and am presently waiting for the powers that be to get their heads out of their posteriors.

Yes, I'm sure there are errors. But hey, it's alpha software, with new commits most days, there ARE going to be issues, especially when using a tool that by its own admission is probably buggy, against a standard that won't be a standard for another year at least if ever...

Re: HTML5 support
« Reply #8, on February 6th, 2013, 07:00 PM »
- I think the HTML5 standard is now supposed to be complete and all, but by definition it's also supposed to be flexible so.. Whatever.

- My love story with HTML5 is long over. Back in the days, it was all about freedom. They got part of the XHTML crowd back because of that: XHTML was becoming to be super-boring with its lack of flexibility. So, they said "no alt params on img tags, more freedom to include tags into other tags (e.g. include a div include an anchor), things like that..."
I used to love them. I was so quick to change all of the templates to use HTML5. I was happy. I really, really loved what they did with the standard.
Then, step by step, their "design by committee" proceeded to cancel all of these advances. At the same time, it started to simply NOT matter that a site was HTML5 valid... The less powers they give me, the less responsibilities I'll give them. I just don't care about HTML5 validation much these days. That's pretty simple... Opera has a built-in validator link in their context menu. Opera keeps crashing on me. Chrome doesn't have such a link. Chrome doesn't crash on me as often. So I'm using Chrome these days. And I don't see the validator link. And I'm not tempted to click it, that way.

- Anyway... The lack of validation in this page was due to two things:
1/ <img src="..."> is no longer valid. Since this summer, they reverted their two-year old decision to allow for img tags to remove the empty alt parameter. Three solutions: (a) tell HTML5 to fuck off, (b) restore all 'alt' tags manually in all files, (c) do a small ob_sessrewrite-time replacement of <img> to <img alt> (except for <img> tags that ALREADY have a non-empty alt param, because that would break validation again...). I choose solution (a) personally, but I'll take solution (c) for now, because. Well, right now it's a preg_replace and I really could replace it with a str_replace and instead ensure that all img tags in Wedge start with either <img src...> or <img alt...> (ensuring that I only modify the first occurrence), it would be ten times faster, but right now I don't care.
2/ I had the status buttons (next to user names) included as divs inside a header tag. Three solutions: (a) tell HTML5 to fuck off, (b) give up on the h4 tag and use a div instead, (b) turn pixelicons into a span, and all its sub-classes into 'i' tags. I considered solution (a) for a long time, then switched to solution (c) as of now.

So... You can see that this very page, will now validate. No reason to cry victory, though... I'm sure that next month, the W3C will find something new to fuck with us. Wanna bet they'll suddenly say that we all need to use "/>" closers on self-closing tags again...?

Re: HTML5 support
« Reply #9, on February 6th, 2013, 08:34 PM »
Quote from Nao on February 6th, 2013, 07:00 PM
2/ I had the status buttons (next to user names) included as divs inside a header tag. Three solutions: (a) tell HTML5 to fuck off, (b) give up on the h4 tag and use a div instead, (b) turn pixelicons into a span, and all its sub-classes into 'i' tags. I considered solution (a) for a long time, then switched to solution (c) as of now.
That's because div is a block, span an inline element. This was already invalid in HTML4, I think.
Quote
So... You can see that this very page, will now validate. No reason to cry victory, though... I'm sure that next month, the W3C will find something new to fuck with us. Wanna bet they'll suddenly say that we all need to use "/>" closers on self-closing tags again...?
Did they really do that? Why divide standards into HTML and XHTML in the first place? Just seems an odd thing to do :lol:

Re: HTML5 support
« Reply #10, on February 6th, 2013, 09:20 PM »
Quote from Harz-FEAR on February 6th, 2013, 08:34 PM
Quote from Nao on February 6th, 2013, 07:00 PM
2/ I had the status buttons (next to user names) included as divs inside a header tag. Three solutions: (a) tell HTML5 to fuck off, (b) give up on the h4 tag and use a div instead, (b) turn pixelicons into a span, and all its sub-classes into 'i' tags. I considered solution (a) for a long time, then switched to solution (c) as of now.
That's because div is a block, span an inline element. This was already invalid in HTML4, I think.
A div can behave as an inline element, and a span as a block element... It's all about the display status.
HTML5 reformulated that to enable inline elements to hold block elements, because of the tags' inconstant nature.

Then they reverted their decision years later. Leaving us programmers in trouble with their stupid validator.

The only thing I can say: if it works on every browser, who gives a damn that it's not valid HTML5..?

Heck, even the HTML5 standard isn't exactly originated by the W3C... Look up the WHATWG group. They keep fighting each other over these differences.
Quote
Did they really do that? Why divide standards into HTML and XHTML in the first place? Just seems an odd thing to do :lol:
XHTML's intention was to be a subset of XML, because at the time, XML was the thing-to-do. It was a noble thing.
But now there are other transmission methods like JSON which are just as popular, and XML is not exactly everywhere. XHTML 2 was in the works for a long time, and IIRC someone got bored and decided to 'fork' HTML4 into HTML5, when the W3C had decided earlier that there would never be another HTML standard, only XHTML. HTML5 got popular (if only because the only doctype you have to remember is <!DOCTYPE html>), and the W3C 'changed their mind' and took the WHATWG's proposal and made it into an official W3C standard. Then started the wars between WHATWG and W3C to determine the 'little details' that nobody cared about. Seriously, there's ARIA for accessibility, for accessibility-minded developers, why do they have to bother us with <img alt> when one could just use an ARIA tag, or even better, <img title>? Why force everyone to provide an alt param, even when they don't have anything to put into them...?

It's all fucked up really.

Again: what matters is that it works on your browser. This is what I care about, personally. If a page is valid, all for the best. But if it's invalid because of a policy change, I just won't go the extra mile to please them. What do we owe them..?