If I am not mistaken, I believe this is why the grid systems were invented, like YUI, blueprint and 960.gs, to quickly mockup sites without the intention of actually using them in the final product…
Basically, people who use grids use them because, in their particular work environments, they believe non-semantic names are a small enough price to pay for quickly whipping out stuff that’s very flexible (can be used for multiple clients) with multiple developers who maybe don’t understand CSS at the same level and have clients who insist on “make that box blue” when “that box” doesn’t have the same type of content in it and is only “blue” because the client wants it to be. Because blue is his wife’s favourite colour or something. A dream he had after eating too much bacon and narwhals. Whatever. There’s no reasonable way to give bluebox a semantic name, and certainly no way of knowing when looking at the CSS or JS why that box is called what it’s called, because it’s called that based on someone’s whim. Not for content reasons, and not for semantic reasons, so giving that element a content-based or semantic name is very difficult.
I feel very lucky that I don’t work in such an environment, because I find that type of code to be smelly (codesmell) and of lower, cookie-cutter quality. If I worked somewhere where that’s what they had to do, I’d be forced to write like that too, and a small piece of my soul would die every day. Then eventually I wouldn’t care about code anyway, just grind out another page and make someone on XP using IE with a mouse and JS happy and go home and drown my sorrows in the whisky and wonder if I should get up the next morning.
Oh man I can just see a prospective employer using grids reading that and crossing my name off the list. Yoink!
Because it’s still in DRAFT? Draft being a word which means “not ready for real world deployment!” … that it loosens the structural rules to the point that any sort of validation is damned near meaningless letting people mix code willy-nilly, who cares if it’s impossible to maintain and highly likely to break? Or that if you look at it really from a markup standpoint it adds nothing but bloat and is one of the most nonsensical train wrecks of a specification since HTML 3 made FONT and CENTER officially part of the spec? That last part is particularly true if you bother understanding elements like numbered headings, lists, paragraphs, and even horizontal rules.
Though the folks around here can tell you, I could go on for hours with reasons that HTML 5 is best avoided until 90% of the new bloat is deprecated for HTML 6. I call 5 the new HTML 3 for a reason!
Personally, I have no plans to go past XHTML 1.0 Strict, as nothing I’ve seen of 5 from a markup standpoint offers me any benefit over that… which again <broken record>makes me suspect that’s why they’re slapping all the new javascript, CSS and other “gee ain’t it neat” stuff under HTML 5’s banner, as without those things it’s useless bloated rubbish that frankly I’m shocked ANYONE is dumb enough to want to even TRY to use!!!</broken record>
There are times I feel like John Adams, and Dickinson just said “To enjoy its protection and share in its benefits…” – as to me that’s about how much HTML 5 offers in terms of reasons to use it. To be frank: JUST like XHTML 1.1 and the proposals for 2.0 – neither of which offered any tangible benefits I could see either apart from making things massively bloated and needlessly complex.
Depends on the ‘employer’ – freelancing you just had the suits line up at your door. Going to work for the Keebler elves of web design shop where they crap out 20 pages a day so they can take the money and run looking for the next inexperienced nube to rape – then sure, good luck even getting in the door.
But as I’ve said a lot lately, don’t look for ethics in web design, where the average porn site has more core ethics than the majority of SEO, Design and Marketing for normal businesses online COMBINED.
Creating responsive images using the noscript tag | Head
The noscript tag is a bad idea if you have users with js-blocking plugins.
Any plugin that blocks Javascript means the browser may have Javascript on itself… meaning it will not render noscript tags, which are only rendered when the browser itself actually doesn’t support Javascript.
So using NoScript or the Web Developer Tool Bar I don’t tend to see noscripts since my browser does support JS. But the idea could still be used.
After a quick Google we discovered that it works because children of the <noscript> tag are not added to the DOM.
Hm. A problem indeed.
Filament group has some good stuff out there, I’ve noticed.
Hm. Was responding to another thread when I realised that
images who are backgrounds and loaded in the CSS with :hover are not downloaded from the server… until that :hover event.
I can maybe see some way of having JS call some kind of hover-like event for at least background images after it runs, assuming it’s only running because the user’s screen is wide enough that the script was loaded…
The important thing to understand that several technologies (seemingly unrelated but that is another topic) are under the umbrella or HTML5. There are several things under that umbrella that I would consider great and others are not. In particular all the new tags such as aside, section , etc – fail in my opinion, I just don’t use them. However, the new input types introduces – awesome especially email with how most mobile browsers handle it. The same can really be said for most the new form stuff introduced besides for the required attribute, which I think frankly sucks because its now very flexible – browser default style or nothing which is quit crude in ff5. Lets see… some of the other things oh… video handling – great, finally no need for flash, who wouldn’t like that. In regards to JavaScript enhancements under the “HTML5” umbrella geo location is sweet ( especially with mobile devices) and local storage seems pretty useful though I have yet to actually use that one, just read about it. So there are actually many things under the HTML5 umbrella that are pretty cool mainly its the new tags that are worthless.
My work flow over the past few months has been write HTML4, use the good things under the HTML5 umbrella that I need, then switch the doctype.
There is to much confusion of what quantifies something as “HTML5” really nothing is “HTML5” its all HTML in the end. There is no way to actually quantify the document as HTML5 besides for looking at the doctype and even that doesn’t necessarily quantify it as HTML5. People just like to say HTML5… that is really all it is.
besides for the required attribute, which I think frankly sucks because its now very flexible – browser default style or nothing which is quit crude in ff5.
It’s pretty much an on/off thing, though for where I’ve used it it’s been nice: we have some form inputs that people consistently missed filling in (and I am tempted to blame the ajax for this, since after someone fills in their postal code, the street and city are automatically filled in for them… but not their house number. And they don’t notice it sitting there because the rest was filled in for them… I even use Javascript to highlight it until it’s filled in, but “required” stops newer browsers from even going through the submit process if it’s empty).
It doesn’t seem to work with pattern though. Meh.
Autofocus however is a pox. At least until users can easily turn it off in their browsers, which so far they can’t.
Lets see… some of the other things oh… video handling – great, finally no need for flash, who wouldn’t like that.
Most examples I’ve seen still had Flash… in teh object inside the video tag as a fallback (and then with a download the video link inside that as a fallback)… tho it may depend on if you’re maybe writing for like an iPhone or something where you know a) Flash is pointless there and b) they have a video-ready browser.
Some of the updated DOM stuff is pretty cool. It’s about time they had a getElementsByClass() (and yeah, that one is part of the HTML5 spec), along with querySelector and querySelectorAll. The data-foo attributes are also nice, especially since they don’t actually rely on the browser understanding them. Browser can ignore them. data-foo is just for us to do local junk with.
then switch the doctype.
I’m too lazy to bother. The shorter doctype is nice to start new pages with simply because then I’m not copy-pasting, but otherwise… you can keep your old one if you want.
So about the doctype…I’m still using XHTML 1.0 mostly but because of some of the form attributes HTML5 had I used those on one of my forms pages and then switched the doctype to the HTML5 doctype. So in order to use any of the HTML5 features or specs I guess, you’d have to switch the doctype right? Because if you left the old doctype the page wouldn’t validate correct?
So in order to use any of the HTML5 features or specs I guess, you’d have to switch the doctype right? Because if you left the old doctype the page wouldn’t validate correct?
You don’t have to change the doctype unless you work somewhere where they insist on validation-for-validations-sake (some places do).
The point of the validator is to tell you where you’ve screwed up, but it’s not a smart tool and for example if the w3c validator claims my aria-attributes are invalid because I’m using an HTML4 doctype, I the developer ignore those, because they are not true errors. Same with vendor prefixes in the CSS validator.
Remember you can also tell the validator to override the doctype. In other words, if you would like it to test your page as if it were HTML5, you can choose that in the options on the validator, and then other than the warning that there’s a doctype override, you would in theory get validation results as if you had an HTML5 doctype.
You can also try validator.nu which by default is an (X)HTML5 validator. It might use WHATWG rules while the W3C one uses W3C rules, but anyone using something where two specs disagree with each other (and yes, they are not the same spec!) should be totally cool with validator disparities. It’s all draft still anyway.
And the validator is the only thing you need to worry about: browsers who support various HTML5 things or have an HTML5 parser only look to see that you are sending the document as text/html.
This means that nasty autocomplete is by default “on” in HTML5 browsers and this is retarded. The idea that I would have to update hundreds of older forms just to keep stuff like credit card numbers from being automatically filled from some user’s cache is kinda evil.
I’ve ordered stuff from public computers. I try to avoid it because they’re often not safe but, I’ve done it. Now the browser has my info in its cache. I know how to flush the cache but I don’t expect every other user to know that.
Autocomplete should default to “off” and those who want it on should then have to add it in manually… opt-in rather than opt-out. There are too many e-commerce forms floating around out there who don’t have someone to go around adding attributes to them because browsers have changed.
To get more back on topic, the Sass site has an article, SASS vs SCSS, which syntax is better which has some of the warnings (for example, the possibility of two much nesting if you don’t watch yourself) and whatnot
Yes, sorry for getting off topic. Just had to find out about that in regards to redesigning my sites responsively.
About the SASS vs SCSS I seem to remember that being mentioned somewhere in this thread but I can’t find it anywhere. What is that again? I read a little on that site you posted to link to…but I was trying to find in this thread where it was mentioned and how it relates to this topic on responsive web design.
That is easily worked-around - just give yourself an invisible element, (either off-screen, or zero size, or whatever you prefer) and set that element’s background image to whatever you need, then it will already be loaded when you need it for :hover
Or use a JS pre-loader script from 1990.
To force the thread back to the original question, Responsive design is a concept, not a template - if you choose to do it badly then of course there will be repercussions, but at it’s core it is by definition better than non-responsive design.
It depends on what you mean by that. The article’s position is that a separate mobile site is better than a “responsive” website, because it is better suited to deliver specific content for mobile users, like utilizing GPS etc etc. Not sure if you would consider that responsive design, but it doesn’t fit the definition given in the article.
then it will already be loaded when you need it for :hover
No, it’s the other way around.
We DON’T want the image loaded, unless the screen is large (because we are working on the assumption, however flawed, that small screens have crappy bandwidth and large screens are hooked up to some fat cables). Since someone set as background on :hover is NOT loaded (and so would have to see if that’s also true for :visited), we could have mobile users NOT load the image and make desktop users do some action to load the image. In other words, users choose to load.
It’s still a flawed idea but it was interesting. Crusty always says something like, use thumbnails and make users click them, but for designy content images that belong on a large screen, I can’t see people willing to do that much work really.
Separate mobile sites are a blind alley: does an iPad count as a desktop, or a mobile? It already has a better display than many netbooks, and if the new version gets a retina display then it will be higher res than many true desktop machines. Same question for the Galaxy Tab 10 inch tablet, 9inch tablet, 7inch tablet…
You kinda have to treat them as mobile since they have touch and no mouse…
Or, to look at it another way, delivering a seperate mobile site is basically browser sniffing - and we all know that isn’t a good idea, don’t we?