Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
3691
Features / Re: Template edits
« on February 7th, 2013, 09:45 PM »
I don't think there's a significant difference between a function call and a static method call.
3692
Features / Re: Template edits
« on February 7th, 2013, 09:12 PM »* Arantor has several copies of this tab open now at differing levels of the topic :/
wetem()->load() is unusual. It's fine, of course, but it feels unusual to write. wetem::load() would be better.
* Arantor can't mentally deal with thinking through all the other consequences right now.
3693
Archived fixes / Re: Tabs in code tags
« on February 7th, 2013, 09:09 PM »It is a bug. (Also, Quick Reply STILL not opening for me :/)
You'll have to give me:
1/ a copy of your html headers, more precisely what CSS and JS files are loaded
2/ what browser are you using exactly?
3/ does this happen on other browsers?
4/ does this happen on your localhost..?
OK, here's the deal. As part of the crap of making tab characters actually fucking work properly across browsers (mostly IE if I remember rightly), they are wrapped in a span, whose display is set to inline - which is when they wrap.
Now, setting bbc_span to inherit from inline-block should fix that[1], at least if I set .bbc_span to display:inline-block it seems to work for me, or at least it displays the lines without wrapping though nothing lines up for me, presumably because of different tab widths in the bbc vs your editor.
1. It only needs display:inline-block but we know that IE requires more effort than that!
So... Do we change that? To inline-block or .inline-block?
3694
Features / Re: Template edits
« on February 7th, 2013, 07:52 PM »wetem()->load() or wetem::load()? Which one looks best to you? Which would you rather see used in Wedge..?
3695
Off-topic / Re: jQuery: .on() instead of .live()
« on February 7th, 2013, 07:32 PM »
This one shouldn't be a problem... Should it?
3696
Archived fixes / Re: Tabs in code tags
« on February 7th, 2013, 07:30 PM »
Could you look into it..? I'm not 'in the right state of mind' for that bug right now :P
3697
Archived fixes / Tabs in code tags
« on February 7th, 2013, 06:06 PM »
Hmm... Bug?
http://wedge.org/pub/7845/template-edits/msg285740/#msg285740
That post contains multiple lines for stuff that appears as a single line in my PHP code... The only 'special' thing these lines have, is multiple tabs between the function name declaration and the function code itself, due to a Naoism of mine[1].
http://wedge.org/pub/7845/template-edits/msg285740/#msg285740
That post contains multiple lines for stuff that appears as a single line in my PHP code... The only 'special' thing these lines have, is multiple tabs between the function name declaration and the function code itself, due to a Naoism of mine[1].
| 1. | Well, a Naoism is always mine. Otherwise it would be called a fucked-up insignificant idea. |
3698
Features / Re: Template edits
« on February 7th, 2013, 06:02 PM »
'kay, I've done everything I said, and also rewrote a bit of wetemItem (renamed to weSkeletonItem) to handle both wetem and weSkeleton objects.
And I'm happy to report... That it's all working just fine :)
With the added benefit that a dynamic class is (very slightly!) faster than a static one, this should help alleviate some of the load on our future message skeleton (considering it'll be rendered 15 times per pages... It's always best to put the priority on this rather than on the main skeleton, which is only rendered once.)
So... Do you think I should keep my code as modified, or I should ditch wetem:: altogether and use either a global $skeleton or a series of functions...?
Or even something I just thought of... Well, a bit silly but...
wetem()->load()
function wetem()
{
static $instance;
if (!$instance)
$instance = new weSkeleton();
return $instance;
}
Lol... This is actually ALL I would need in the entire codebase... No need for the wetem object anymore, no need for function duplication. Hmm. And to think I didn't think of that silly little 4-line function until NOW..!
wetem()->load() or wetem::load()? Which one looks best to you? Which would you rather see used in Wedge..?
And I'm happy to report... That it's all working just fine :)
With the added benefit that a dynamic class is (very slightly!) faster than a static one, this should help alleviate some of the load on our future message skeleton (considering it'll be rendered 15 times per pages... It's always best to put the priority on this rather than on the main skeleton, which is only rendered once.)
So... Do you think I should keep my code as modified, or I should ditch wetem:: altogether and use either a global $skeleton or a series of functions...?
Or even something I just thought of... Well, a bit silly but...
wetem()->load()
function wetem()
{
static $instance;
if (!$instance)
$instance = new weSkeleton();
return $instance;
}
Lol... This is actually ALL I would need in the entire codebase... No need for the wetem object anymore, no need for function duplication. Hmm. And to think I didn't think of that silly little 4-line function until NOW..!
wetem()->load() or wetem::load()? Which one looks best to you? Which would you rather see used in Wedge..?
3699
Features / Re: Template edits
« on February 7th, 2013, 05:33 PM »
So... I wrote this.
I dislike the list of functions, but I made them one-liners, so it basically looks a lot like wetemItem.
Code: [Select]
Fact is... It seems to be working. The original wetem class is now weSkeleton, and is entirely dynamic.
What do you think..? Is it worth calling functions that will simply redirect to... These anyway?
Well, I think I could event get away with wetem::getInstance() calls by simply using self::$instance. I'm going to do that, as getInstance() is always called at startup anyway.
I dislike the list of functions, but I made them one-liners, so it basically looks a lot like wetemItem.
final class wetem extends weSkeleton
{
private static $instance = null; // container for self
// What kind of class are you, anyway? One of a kind!
private function __clone()
{
return false;
}
// Bootstrap's bootstraps
static function getInstance()
{
// Squeletto ergo sum
if (self::$instance == null)
self::$instance = new weSkeleton();
return self::$instance;
}
function has($item) { return wetem::getInstance()->has($item); }
function has_block($block) { return wetem::getInstance()->has_block($block); }
function has_layer($layer) { return wetem::getInstance()->has_layer($layer); }
function build(&$arr) { wetem::getInstance()->build($arr); }
function render() { wetem::getInstance()->render(); }
function get($targets = '') { return wetem::getInstance()->get($targets); }
function before($target, $contents = '') { return wetem::getInstance()->before($target, $contents); }
function after($target, $contents = '') { return wetem::getInstance()->after($target, $contents); }
function remove($target) { wetem::getInstance()->remove($target); }
function move($item, $target, $where) { return wetem::getInstance()->move($item, $target, $where); }
function parent($child) { return wetem::getInstance()->parent($child); }
function load($target, $contents = '') { return wetem::getInstance()->load($target, $contents); }
function add($target, $contents = '') { return wetem::getInstance()->add($target, $contents); }
function first($target, $contents = '') { return wetem::getInstance()->first($target, $contents); }
function replace($target, $contents = '') { return wetem::getInstance()->replace($target, $contents); }
function rename($target, $new_name) { return wetem::getInstance()->rename($target, $new_name); }
function outer($target, $new_layer = '') { return wetem::getInstance()->outer($target, $new_layer); }
function inner($target, $new_layer = '') { return wetem::getInstance()->inner($target, $new_layer); }
function hide($layer = '') { return wetem::getInstance()->hide($layer); }
function layer($layer, $target = '', $where = 'replace') { return wetem::getInstance()->layer($layer, $target, $where); }
}Fact is... It seems to be working. The original wetem class is now weSkeleton, and is entirely dynamic.
What do you think..? Is it worth calling functions that will simply redirect to... These anyway?
Well, I think I could event get away with wetem::getInstance() calls by simply using self::$instance. I'm going to do that, as getInstance() is always called at startup anyway.
3700
Features / Re: Template edits
« on February 7th, 2013, 05:15 PM »
Yep, except I don't understand that suggestion... ;)
Using functions is something I considered yesterday too, doing things like wetem_add() that would redirect to wetem::getInstance()->add(), but it's even more overhead... Imagine that: a function call, then a static call, then a dynamic call...
I could rename getInstance() to something more 'direct', like wetem::backbone(), but it's still too long. wetem::main()->add() simply feels odd to me. I don't really know where this is going...
All I can say is, I did a last attempt at making a static class that extends on the dynamic one, and call $this everywhere. No functions at all inside the static class. Not surprised here: it all works... until the dynamic methods get called and try to access $this. It's a bit annoying, but it's as it is...
Using functions is something I considered yesterday too, doing things like wetem_add() that would redirect to wetem::getInstance()->add(), but it's even more overhead... Imagine that: a function call, then a static call, then a dynamic call...
I could rename getInstance() to something more 'direct', like wetem::backbone(), but it's still too long. wetem::main()->add() simply feels odd to me. I don't really know where this is going...
All I can say is, I did a last attempt at making a static class that extends on the dynamic one, and call $this everywhere. No functions at all inside the static class. Not surprised here: it all works... until the dynamic methods get called and try to access $this. It's a bit annoying, but it's as it is...
3701
Features / Re: Template edits
« on February 7th, 2013, 09:53 AM »Don't use magic functions, they're pathetically slow.
They're only called if the method isn't found.
I've been thinking it over last night, and figured out I didn't really need to have __callStatic...
I can simply implement __call, and then pass all the information about the current object to the static wetem object.
For instance, $message->build() would magically call __call(), which would then pass the data to wetem::build($message->id_object) or something. For instance, I could store the contents of the static object into a temp var, replace the static object's vars with the dynamic object's, call the static function, then replace the static object vars with the temp vars.
Of course it's going to be much slower... But we're talking about relatively small arrays. My only concern is with calling these things repeatedly... It'd be better, I guess, to have a dynamic object in the first place and __callStatic to bind the backbone to a dynamic object, because wetem we know isn't being accessed a lot. But we don't have that leisure, as __callStatic is PHP 5.3 only. Unless Pete wants to reconsider our minimum PHP version. But that particular use case probably wouldn't be enough to justify it...
Then again, we could also simply use arrays of arrays. wetem::$skeleton['backbone'], wetem::$layers['backbone'], things like that...
Can't you simply declare static functions in a base class, declare a new singleton class for main skeleton extending the base which has calls to the parent class but also passes the first parameter and keeps everything sane?
Well, now I guess we could hmm... Well we don't have that many public methods in the object in the first place, that's true.
(I also liked having the 'final' keyword on wetem... It's the only time I ever used it, and because I use it in Class-CSS, it sounded cool to also have it in a proper PHP class :lol:)
That or make a new class for only one skeleton (you need more than one?) which is singleton and has instance object to return the only instance that it has?
I'd really like more of your input on this, as well as Pete's -- and anyone who's into OOP really. (Yeah, OOP, not the other word I used last time, remember Shitiz :lol:)
3702
Features / Re: Template edits
« on February 6th, 2013, 09:32 PM »
Okay, re: plugin-info.xml, to me it'd make more sense to have 'plugin.xml', but it's your 'area', so your preference matters more ;)
Regarding skeletons, I've been considering multiple ways of doing it these last few days, most of them 'unclean'.
So, the two that remain right now are these:
- the 'realistic' solution: wetem remains a singleton, but wetem::$skeleton becomes an array of skeletons. Same for wetem::$layers, etc. Has the advantage of being easy to transition. Can do wetem::render() to render the main skeleton, and wetem::render('message') to render a specific mini-skeleton. Drawback: not that it's necessary inelegant, but having a singleton to manipulate multiple objects can sound strange...
- the 'object-obsessed' solution: wetem becomes an actual object system, we'd then do $msg = new wetem('skeleton-message.xml'), or something like that. Then $msg->build(), then $msg->render(). Main advantage: it looks way better in the code... Main drawback: okay, I can't possibly imagine asking plugin authors to insert a global for $rootSkeleton (or something) and then call $rootSkeleton->add('sidebar', 'my_block') to add a block to the sidebar... This seems uglier to me than wetem::render('message').
I'm trying to figure out whether it's possible to have the best of both world, i.e. if wetem::render is called, then we automatically redirect to the $rootSkeleton object, and if $something->render() is called, render said object. I don't know whether that's possible right now... I could imagine storing the main skeleton inside its own static (or global?! meg...) variable, then relying on it if function render() doesn't find a qualified $this value. But, we'd have to do the same for add(), and so on...
So... Any opinions? I'm afraid I'm not in the best position to comment on object creation :P
Adding to the question.
Both solutions are complicated IMHO...
- Staying static sort of feels like I'm from a procedural world (which is true), and that I'm trying hard to remain traditional while giving the appearance of working with an object.
- Going half static, half dynamic probably means I'm going to have to duplicate a lot of functions... One for mini-skeletons, one for the main skeleton. (Which I'm tempted to rename internally to 'backbone', dunno why :lol:) And that could be even more confusing. Just look at wetemItem: I'd have to rewrite it to address both the 'backbone' and any other skeleton. Because right now it's just acting like it's one big static skeleton. I'll give a try to mixing static and non-static functions and see how they behave when called dynamically and statically.
- Going fully dynamic would be the way to go, but as I mentioned earlier, I would absolutely hate having to force plugin authors to declare a global for backbone/root/main manipulation. I've given them power with so many methods -- I don't want this to be at the cost of simplicity in their main code. And don't get me started with $_GLOBALS['backbone']->build()... Alright? :lol:
---
Okay, it was too hard on me, I decided to immediately try for a simple version of the dynamic/static test I mentioned. Here's the code I tried... Note that all the class and method names are French synonyms of the word 'thing' :P
Code: [Select]
I'm surprised that I'm not getting any crashes, or even any warning from PHP at this point..?!
This was done with PHP 5.3.4, downgrading to 5.2.9 gave me a 'parse error' crash on both $chose:: lines, meaning only PHP 5.3+ supports using a static call from within a dynamic object. Or something... More 'interestingly', $chose::$any_static_variable doesn't work in PHP 5.2.9 either, even though the php.net docs seem to indicate otherwise.
So, it seems there's something that... could be done, I guess... Regarding using 'wetem::add()' for the main skeleton and '$other->add()' for other skeletons without duplicating the 'add' function -- something like if (!isset($this)) $skel = self::$skeleton; else $skel = $this->skeleton...??
It still makes life complicated and forces me to rewrite all functions to use a pointer to the desired array ($skeleton, $layers...), rather than directly access self::$layers or whatever.
I'm still not much used to all of this... It's really not my initial area of expertise. I think it's important that I get it right on the first try, which is why I haven't developed anything so far.
Waiting for opinions and ideas, then...!
I may have found a solution...
http://www.php.net/manual/en/language.oop5.overloading.php#object.call
Basically, set all functions to be private. Calling wetem::add will invoke __callStatic, in which I'll first check through the list of authorized function names, then if allowed, redirect to that function while passing self::$instance as the instance, while $object->add will invoke __callStatic which does the same, but passes $this as the param.
I'm not sure it'll work... But it seems... possible?!
F*ck! __callStatic (not __call) is PHP 5.3+ only... -_-
Okay, there may be a possibility that it "just works"...
Code: [Select]
(Of course, I removed the 'private' keyword for $skeleton.)
The first print_r gives me the main skeleton.
The second print_r gives me 'DELETED'.
The last print_r gives me the main skeleton.
So, it would seem that wetem:: acts just like a regular instance of wetem, and keeps the data associated to it.
Which is pretty good. And means I wasted more hours trying to fix a problem that didn't exist in the first place... :^^;:
Now, the only issue is that E_STRICT supposedly should/would return a warning when calling one of these, because it doesn't like to mix static and dynamic stuff.. But it doesn't give me anything.
Oh, bugger... Forget what I said.
Inside the $a instance, $this->skeleton gives me DELETED, while wetem::$skeleton gives me the main skeleton. I should have guessed...
So it's back to the isset($this) test on each function... Or giving up and using arrays for every instance. :(
Anyone..? I hate talking to myself all day... :whistle:
Regarding skeletons, I've been considering multiple ways of doing it these last few days, most of them 'unclean'.
So, the two that remain right now are these:
- the 'realistic' solution: wetem remains a singleton, but wetem::$skeleton becomes an array of skeletons. Same for wetem::$layers, etc. Has the advantage of being easy to transition. Can do wetem::render() to render the main skeleton, and wetem::render('message') to render a specific mini-skeleton. Drawback: not that it's necessary inelegant, but having a singleton to manipulate multiple objects can sound strange...
- the 'object-obsessed' solution: wetem becomes an actual object system, we'd then do $msg = new wetem('skeleton-message.xml'), or something like that. Then $msg->build(), then $msg->render(). Main advantage: it looks way better in the code... Main drawback: okay, I can't possibly imagine asking plugin authors to insert a global for $rootSkeleton (or something) and then call $rootSkeleton->add('sidebar', 'my_block') to add a block to the sidebar... This seems uglier to me than wetem::render('message').
I'm trying to figure out whether it's possible to have the best of both world, i.e. if wetem::render is called, then we automatically redirect to the $rootSkeleton object, and if $something->render() is called, render said object. I don't know whether that's possible right now... I could imagine storing the main skeleton inside its own static (or global?! meg...) variable, then relying on it if function render() doesn't find a qualified $this value. But, we'd have to do the same for add(), and so on...
So... Any opinions? I'm afraid I'm not in the best position to comment on object creation :P
Posted: February 6th, 2013, 03:48 PM
Adding to the question.
Both solutions are complicated IMHO...
- Staying static sort of feels like I'm from a procedural world (which is true), and that I'm trying hard to remain traditional while giving the appearance of working with an object.
- Going half static, half dynamic probably means I'm going to have to duplicate a lot of functions... One for mini-skeletons, one for the main skeleton. (Which I'm tempted to rename internally to 'backbone', dunno why :lol:) And that could be even more confusing. Just look at wetemItem: I'd have to rewrite it to address both the 'backbone' and any other skeleton. Because right now it's just acting like it's one big static skeleton. I'll give a try to mixing static and non-static functions and see how they behave when called dynamically and statically.
- Going fully dynamic would be the way to go, but as I mentioned earlier, I would absolutely hate having to force plugin authors to declare a global for backbone/root/main manipulation. I've given them power with so many methods -- I don't want this to be at the cost of simplicity in their main code. And don't get me started with $_GLOBALS['backbone']->build()... Alright? :lol:
---
Okay, it was too hard on me, I decided to immediately try for a simple version of the dynamic/static test I mentioned. Here's the code I tried... Note that all the class and method names are French synonyms of the word 'thing' :P
class truc
{
static function machin ()
{
echo 'Hello ', isset($this);
}
function bidule ()
{
echo 'World! ', isset($this);
}
}
error_reporting(E_ALL | E_STRICT);
truc::machin(); // Hello
truc::bidule(); // World!
$chose = new truc();
$chose::machin(); // Hello
$chose::bidule(); // World!
$chose->machin(); // Hello
$chose->bidule(); // World! 1I'm surprised that I'm not getting any crashes, or even any warning from PHP at this point..?!
This was done with PHP 5.3.4, downgrading to 5.2.9 gave me a 'parse error' crash on both $chose:: lines, meaning only PHP 5.3+ supports using a static call from within a dynamic object. Or something... More 'interestingly', $chose::$any_static_variable doesn't work in PHP 5.2.9 either, even though the php.net docs seem to indicate otherwise.
So, it seems there's something that... could be done, I guess... Regarding using 'wetem::add()' for the main skeleton and '$other->add()' for other skeletons without duplicating the 'add' function -- something like if (!isset($this)) $skel = self::$skeleton; else $skel = $this->skeleton...??
It still makes life complicated and forces me to rewrite all functions to use a pointer to the desired array ($skeleton, $layers...), rather than directly access self::$layers or whatever.
I'm still not much used to all of this... It's really not my initial area of expertise. I think it's important that I get it right on the first try, which is why I haven't developed anything so far.
Waiting for opinions and ideas, then...!
Posted: February 6th, 2013, 05:49 PM
I may have found a solution...
http://www.php.net/manual/en/language.oop5.overloading.php#object.call
Basically, set all functions to be private. Calling wetem::add will invoke __callStatic, in which I'll first check through the list of authorized function names, then if allowed, redirect to that function while passing self::$instance as the instance, while $object->add will invoke __callStatic which does the same, but passes $this as the param.
I'm not sure it'll work... But it seems... possible?!
Posted: February 6th, 2013, 06:27 PM
F*ck! __callStatic (not __call) is PHP 5.3+ only... -_-
Posted: February 6th, 2013, 07:46 PM
Okay, there may be a possibility that it "just works"...
error_reporting(E_ALL | E_STRICT);
print_r(wetem::$skeleton);
$a = new wetem();
$a->skeleton = array('DELETED');
print_r($a->skeleton);
print_r(wetem::$skeleton);(Of course, I removed the 'private' keyword for $skeleton.)
The first print_r gives me the main skeleton.
The second print_r gives me 'DELETED'.
The last print_r gives me the main skeleton.
So, it would seem that wetem:: acts just like a regular instance of wetem, and keeps the data associated to it.
Which is pretty good. And means I wasted more hours trying to fix a problem that didn't exist in the first place... :^^;:
Now, the only issue is that E_STRICT supposedly should/would return a warning when calling one of these, because it doesn't like to mix static and dynamic stuff.. But it doesn't give me anything.
Oh, bugger... Forget what I said.
Inside the $a instance, $this->skeleton gives me DELETED, while wetem::$skeleton gives me the main skeleton. I should have guessed...
So it's back to the isset($this) test on each function... Or giving up and using arrays for every instance. :(
Anyone..? I hate talking to myself all day... :whistle:
3703
Features: Forward thinking / Re: HTML5 support
« on February 6th, 2013, 09:20 PM »That's because div is a block, span an inline element. This was already invalid in HTML4, I think.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.
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.
Did they really do that? Why divide standards into HTML and XHTML in the first place? Just seems an odd thing to do :lol:
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..?
3704
Features: Forward thinking / Re: HTML5 support
« 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...?
- 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...?
3705
Features: Forward thinking / Re: jQuery support
« on February 6th, 2013, 05:52 PM »
Yeah, and even more amusing, there are more people asking that jQuery fixes it NAO!!!!11
These people probably wouldn't have noticed the bug without my report, though... ;)
But I understand how it is to read something and to immediately be upset because you realize you're concerned and you didn't catch it in the first place.
I'm thinking that the reason for the bug in the first place is that v2.0 was simplified by removing all IE hacks, but this particular one was marked as an IE hack when really it was a generic hack.
These people probably wouldn't have noticed the bug without my report, though... ;)
But I understand how it is to read something and to immediately be upset because you realize you're concerned and you didn't catch it in the first place.
I'm thinking that the reason for the bug in the first place is that v2.0 was simplified by removing all IE hacks, but this particular one was marked as an IE hack when really it was a generic hack.