-
• #2
Oh, and this work will include a pixel perfect iphone style too, as well as a pixel perfect android style.
-
• #3
PM'd
-
• #4
the forum looked screwed up in linux on both firefox and chrome,
The menu bar at the top goes right down the screen
ive tried to attach a screen shot, but the forum doesnt seem to like uploads from linux either.
1 Attachment
-
• #5
No jQuery?
-
• #6
the forum looked screwed up in linux on both firefox and chrome,
The menu bar at the top goes right down the screen
ive tried to attach a screen shot, but the forum doesnt seem to like uploads from linux either.
See: http://www.lfgss.com/thread4490-23.html#post1323713
No jQuery?
No, it's bloated. Well, too much of it isn't used by the forum (so why have it?) and the selectors are slow (in comparison to using ID's)... jQuery is for the lazy.
IF I use it, it will only be because the code I write exceeds the size of jQuery + jQuery code AND that jQuery proves to render as fast AND that I manually strip things out of jQuery that I won't use.
This will be a labour of love, and jQuery has bloated... I want smaller requests, quicker code.
PM'd
Received. Once I've worked with wayne on the design I'll get back to you.
-
• #7
Received. Once I've worked with wayne on the design I'll get back to you.
Cool.
-
• #8
@VB - I'll drop you a PM when I get into work.
-
• #9
As before, I'm available for this as the front-end architect.
Are you upgrading vBulletin? -
• #10
I'll be upgrading vbulletin to version 4 (though it's still missing some things), but more importantly I'll be gutting every piece of code that produces anything that outputs stuff to the browser.
I'm basically wanting to produce a near perfect, fast as hell, HTML5 website. The motivation is what I have seen from making minor tweaks, every time I shave 100ms from the page load time for the average user, a few percent more people engage with the website and take part in forum stuff. If it ultimately boils down to just making the site faster, then the best way to do this is to really research and go nuts about wiping out HTTP calls, producing HTML that renders fast, produce JavaScript that only does the bare minimum... and basically strip out everything that isn't helping the site perform fast whilst looking good.
-
• #11
What's the point of going HTML5 when the spec is still subject to internal changes? It seems rather a fruitless pursuit to go for compliance with a (- long way to go -) yet to be finished standard. I think you should just keep the whole thing focused on your main objective: for LFGSS to be faster, and sexier (but not at the expense of speed).
-
• #12
I am unsure about the HTML 5.0 stuff because IE7 and 8 won't be able to render the new elements in HTML 5.0 as they have don't understand what they are. I have been told conflicting things from devs as to how/if HTML 5.0 will render in older browsers.
However using XHTML 1.0 Strict / XHTML 1.1 does force these browsers to render in "standards mode" and solves most of the problems with these older browsers.
Even though IE6 usage might be declining, IE7 and 8 have the share of the market between them and shouldn't be ignored.
Also if the Markup and CSS is clean, moving to HTML 5.0 once these old browsers have gone to the way of dodo shouldn't be too difficult.
-
• #13
Semantic markup. It's not that I want full HTML5 support, but rather that I want to reduce layout/structural HTML in favour of descriptive markup.
Example, instead of
some textI'd rather have some text. The latter actually describes what is inside it, the former doesn't and requires additional class matching in the browser.I'd like to have something that is transitional, and very ready for a strict HTML5 when the time comes, but for the meantime I'm fine with shifting some of this to CSS so that the HTML can be made more semantic.
LFGSS is XHTML already, but I want to remove the garbage HTML... so much of it is still based on HTML2 or 3 techniques (i.e. table layouts, lots of nesting), and I want an HTML5 approach to show through as this actually results in less nesting... the sooner I can close a top-level nest the quicker a browser can layout and render that part of the code and the sooner something appears on the end users screens.
So my HTML5 quest is about taking what is really good about HTML5 and that which is supported or possible in XHTML making it available now so that we get those benefits.
If you look at LFGSS, the entire page is wrapped in a table. Were that to go it would perform the render way faster.
-
• #14
This discussion is total
Geek points for those who get it. -
• #15
I'm happy to help out with HTML and JS stuff. I haven't done anything with HTML5 yet but it seems fairly straightforward.
-
• #16
XHTML without the correct mime type is considered harmful, and with the correct mime type leads to endless complication with browsers showing and XML validation error in case someone somehow managed to not close a tag.
-
• #17
XHTML without the correct mime type is considered harmful, and with the correct mime type leads to endless complication with browsers showing and XML validation error in case someone somehow managed to not close a tag.
LFGSS:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
W3C:
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/HTML compatible XHTML 1.0 may be sent with the “text/html” mime type (note that this applies to 1.0 only, not 1.1 or anything which comes after).
Oh yeah... LFGSS is XHTML 1.0 Transitional.
Actually I only use transitional as some parts of the site (markup from the BBcode engine) I cannot guarantee, let alone things like the YouTube embed.
Most of the non-thread pages are already XHTML strict, but I leave them as transitional and v1.0 so that I don't have to change the mime-type on some pages and not others.
I do tend to know what I'm on about and this will be done the right way. With religion, arguing, finely honed pixel alignments, a nice design, etc.
-
• #18
I do tend to know what I'm on about and this will be done the right way.
Amen brother.
-
• #19
http://hixie.ch/advocacy/xhtml
Not that it matters much, but xhtml 1.0 is tag soup when sent as text/html, no matter whether set to strict or transitional. At least browsers think it is.
-
• #20
I'm currently doing what the specs say is cool and it's wrong?
And then I propose to do exactly what hixie.ch proposes also, and yet rounce thinks that's wrong too?No bloody winning.
I will go HTML5, it will be nice.
-
• #21
I'd do that as well. I think it's fine to do whatever works. Just pointing out that when you're thinking about XHTML and the future you might as well go HTML instead.
XHMTL even with text/html mime type poses problems with user generated input that I haven't seen solved in a really elegant way. Someone is just bound to not close and img tag somehow.
As soon as application/xhtml+xml comes into play the problems are just ridiculous. Try using google ads for example, or anything that uses document.write ... NOPE
HTML 5 is fairly failure tolerant, and you can just use the new elements as it stands. Worst case scenario is that browsers interpret it as tag soup. Same like with XHTML.
Features like canvas already works in a lot of browsers.So yeah, just trying to be helpful, not saying you don't know what you're on about ...
-
• #22
Why Should I Care What Color the Bikeshed Is?
"The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."
Source: FreeBSD mailing list
-
• #23
http://hixie.ch/advocacy/xhtml
Not that it matters much, but xhtml 1.0 is tag soup when sent as text/html, no matter whether set to strict or transitional. At least browsers think it is.
Almost everything on that page is total and utter horseshit.
I have been doing this for a living for 12 years, and experience has taught me that xhtml 1.0, with the correct doctype (transitional in the case of this forum because we need the target attribute on links in posts) and proper, lean, semantic HTML is actually the best way to guarantee that all browsers render your documents as similarly and as standards compliant as possible. User agents when given the correct doctype actually switch rendering modes to a standards compliant one. It's also a mature standard and all issues with those renderers have long since been documented, along with any workarounds. Its maturity also puts the onus on browser makers to support our code, rather than for us to support their quirks. The very high level of detail in the XHTML standards also ensures that it is future proof. The issue about PCDATA script and style tag content is irrelevant because if I design the code we will not be putting any inline script or style tags in at all. All CSS and JS belongs in external files, which can be separately cached for much longer intervals. Incorrect xml grammar in forum posts is irrelevant because the forum does not allow people to put HTML in - just BBCode, and the (x)HTML generated is up to us.
I'd love to have a play with HTML5, but I don't think this is the right project to do it. It's just an internet forum. Simpler is better and less is more. And anything less than comprehensive browser support is unacceptable. Tried and trusted is the way to go. So much time and effort will go to fixing errors caused by unfinalised specs incomplete browser support, and so forth, that any benefits are outweighed by the problems.
-
• #24
^ repped
-
• #25
Yes, there are variations of the XHTML doctype that don't trigger quirks mode.
However, there are also variations of the HTML 4 doctype that are as good in triggering standards mode.Future proof, now that's a much more difficult statement. XHTML 1.0, especially when we're talking transitional, is very different from XHTML 1.1 or even 2.
XHTML 1.1 will have to be served as application/xhtml+xml, and that will pop up with a nice "not well formed XML" error if you miss out a self closing tag.
As soon as we move to HTML 5, how is the fact that you should remove the slash from all self-closing link tags, script tags, brs etc an indication that XHTML 1.0 is future proof? Unless you use the XML serialzation of HTML5 maybe, but I didn't look into that much, but again it's served with application/xhtml+xml, meaning a strict validation by the client and hence an error message instead of a page if there's a single mistake in.
While I agree that it is possible to do a standards compliant XHTML site and make sure everything is valid etc every time someone user generated content goes in, it also is a big pain in the ass that OTHER PEOPLE ON THE TEAM might forget about standards.
Large content managed sites that don't just use BBCode are something that I work with on a daily basis since a long time, and the outcome is exactly what hixie brings up: Invalid sites that claim to be XHTML. Thanks to copy & paste, negligence and all that.By it's nature HTML4 and HTML5 are forgiving standards. XHTML on the other hand is designed to cop out early when served with application/xhtml+xml and otherwise just a lowercase approximation of HTML 4 in xml.
You might think it's horse shit, but unless you have a very harsh sanitization or a validation facility on every bit of content, then I'd suggest you stick with nice semantic HTML and are in a good position to then move on to HTML 5 and it's new tags and functionalities like CANVAS and VIDEO.
Just my 2p.
I really really loathe the way that LFGSS looks.
It bugs me.
I also loathe the way that vbulletin makes a page, that bugs me too.
Things I don't like about the invisible stuff:
Things I don't like about the design itself:
Now, big daddy wayne is knocking up some design mockups to help produce a solid look and feel, but then it needs to be implemented.
I will not be able to do everything myself, so what I am looking for are people who are truly obsessed about perfect, minimalist HTML(5) and JavaScript to help me produce an incredible front-end and description of wayne's design.
Ultimately, I want to use CSS image sprites, perfect reduced JavaScript (no framework ideally... jQuery is still 50KB), perfect descriptive and semantic HTML, clean and readable source.
The holy grail is for each page to weigh less than 80KB in total (all assets) and to only require the minimum number of HTTP requests (which is 4 requests: 1 for HTML, 1 for JavaScript, 1 for CSS and 1 for the image sprite).
If you have these skills and this talent and want to help then I'd really appreciate it. And whilst LFGSS isn't yet profitable beyond a few pounds I am definitely willing to help pay/reward contributions from my personal pocket as this stuff haunts me.
Why is this a big deal? Because I'm interviewing people for jobs, and they're googling me, and keep saying "Oh, you run that cycling website" and I realise that as a dev/architect the code on this site doesn't really represent the top notch, it's just what I purchased off the shelf and hacked in my spare time... so I really really want it to be referencable, top notch and to make interviewees realise that I'm actually good at this stuff.
I am very happy to give work references to anyone who wants to help and wants to put this on their CV. The output should be good enough for you to want it on your CV.
So... is anyone interested?