SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 58
  1. #26
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,273
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Obviously I do think backward compatibility is important but a javascript fix to fix an issue with one browser (a browser that's held back standards long enough already) isn't that bad of a solution. I'd prefer it if I didn't need to apply a javascript fix but I think it's worth the effort to use it.
    I think doing corners with CSS is much better solution than trying to do it with images or javascript.
    Why? Just curious.

  2. #27
    SitePoint Member
    Join Date
    Jul 2010
    Location
    Bolton - UK
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Why? Just curious.
    For the first quote because it's future proofing the sites. The move will have to be made eventually so why hold back on the account of a browser which has held back standards long enough already when there's a solution available that will get it working even in that browser.

    There's no point waiting until it comes out of draft as that won't be for years if not decades. Why not at least use some of the new features such as the new form types which degrade for the non supporting browsers? If we can provide a better experience for those using newer browsers why shouldn't we?

    I can understand that people will see having to use javascript for older IE users (when using the new elements) as a bad solution but that'll have to be a decision for every web developer to make for themselves. For me personally I don't see it as much of an issue but obviously others will.

    For the second quote: Using images for corners is incredibly messy for a start, I spent a long time about 3 years ago looking for various solutions to rounded corners and all of them were horrid. I ended up selecting a javascript based solution but I don't see why anyone wouldn't use CSS3 corners if they are developing a site nowadays.

    It's better imo to provide a good solution to the majority of users which degrades nicely to everyone else than a bad solution for everyone. Why punish users of newer browsers for staying up to date with features when you can give them a better experience using the latest standards?

  3. #28
    SitePoint Wizard bronze trophy
    Join Date
    Oct 2001
    Location
    Vancouver BC Canada
    Posts
    2,029
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rjs37 View Post
    On the website I'm developing at the moment I've decided to go the HTML 5 route...
    Excellent

    This is just what I was looking for. Please feel free to post any ideas you have for workarounds. Also, if you find areas where HTML5 clearly provide an advantage in some way come back and post it. I'm extremely comfortable working in xhtml but I'm pretty sure it's just a matter of time before enough momentum builds to push HTML5 into our development world. As Stomme poes has mentioned, some ads are already specking out HTML5 and CSS3 in their requirements.

    Cheers and good luck with your project.
    Andrew Wasson | www.lunadesign.org
    Principal / Internet Development

  4. #29
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rjs37 View Post
    For the first quote because it's future proofing the sites. The move will have to be made eventually so why hold back on the account of a browser which has held back standards long enough already when there's a solution available that will get it working even in that browser.
    If you don't mind a giant bloated javascript that tends to break other scripting, often breaks other workarounds to get elements behaving right int the first place, and in general bloats out the code you send to EVERYONE regardless for something that frankly, you CAN USUALLY ALREADY DO IN HTML 4.

    Besides, it's not "future proofing" to be implementing a specification that COULD CHANGE AT ANY TIME. FUTURE PROOFING is using what works and is a recommendation in the here and now, because there's no "expiration date" on HTML 4 -- it's not like browsers are going to stop supporting it just because of some new specification that throws all the progress of 4 out the window.

    Quote Originally Posted by Rjs37 View Post
    There's no point waiting until it comes out of draft as that won't be for years if not decades. Why not at least use some of the new features such as the new form types which degrade for the non supporting browsers? If we can provide a better experience for those using newer browsers why shouldn't we?
    Which is where I think people fail to grasp that these new features are in said browsers for TESTING, NOT deployment -- that's the difference between "DRAFT" and "RECOMMENDATION". It's like the CSS3 browser specific prefixes, by definition they mean "for testing", "not for use on production sites".

    It's the SAME MISTAKE people made using IE5's CSS2 implementation, which was done BEFORE it was out of draft and BEFORE they up and decided to use a box model that wasn't compatible with the only browser that had tried to implement the draft at the time.

    ... and we're still paying for said mistake TODAY in terms of keeping IE backwards compatible.

    I can understand that people will see having to use javascript for older IE users (when using the new elements) as a bad solution but that'll have to be a decision for every web developer to make for themselves. For me personally I don't see it as much of an issue but obviously others will.

    Quote Originally Posted by Rjs37 View Post
    For the second quote: Using images for corners is incredibly messy for a start, I spent a long time about 3 years ago looking for various solutions to rounded corners and all of them were horrid. I ended up selecting a javascript based solution but I don't see why anyone wouldn't use CSS3 corners if they are developing a site nowadays.
    Inconsistent rendering cross browser for a start? Poor anti-aliasing behavior that often looks worse than jpeg artifacts? The need for something a wee bit more complex than just making a corner round?

    Though admittedly, that's why I'm a LOT more interested in CSS3's border-image property... NOT that I would try to deploy anything using that right now -- it's tons of fun to play with to see what we MIGHT be able to use SOMEDAY.

    Images for corners is only as messy as you make it... I often laugh hysterically when I see people doing fixed width websites and STILL end up using 9 separate images to do the job of one.

    Quote Originally Posted by Rjs37 View Post
    It's better imo to provide a good solution to the majority of users which degrades nicely to everyone else than a bad solution for everyone. Why punish users of newer browsers for staying up to date with features when you can give them a better experience using the latest standards?
    ... and when it's not a good solution, is worse than the older way of doing it... much less "punish WHAT?"... deploying "for testing" versions that could change at any time? Just because it's in there doesn't mean you should be using it on production code.

    But again, people just want to repeat the same mistakes that were made with IE5 -- this time out it's just gecko and webkit's turn. (At least Opera has the decency to give us the REAL CSS3 properties)

    I have yet to see a HTML5 based site that was worth a flying furry 4channer. MOST of what I've seen is the same garbage we've been seeing for the past two decades; idiocy like non-breaking spaces in empty elements, splash pages, and 50k of markup doing 10k's job. Might as well have a splash page with nothing resembling content on it while at it -- as it's in that same class of "sleaze it out any old way".

  5. #30
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Rjs37
    I know I'm currently in the minority there but there we go. Likewise I'm using some of the new CSS3 styling to provide a better experience for those using newer browsers. I think doing corners with CSS is much better solution than trying to do it with images or javascript.
    Nothing is stopping you from using CSS3 with a HTML 4.01. HTML5 isn't necessary to use many of the features of CSS3 that help to promote cleaner mark-up such as; rounded corners, gradients, etc. Just make sure you degrade properly or perhaps use something like CSS PIE – additional bloat I know but its a great solution to keeping the integrity of a design in tact in <=IE8 w/ some restrictions of course. That said I haven't noticed any unexpected cross-browser inconsistency on browsers that implement CSS3 in some form. A short while ago I was very against CSS3 and thought many of the things are stupid, such as rounded-corners. However, even with the varying implementation across browsers its nice not to clutter mark-up with presentational crap to achieve a certain effect like the empty element with absolute positions or excessive wrapping to apply rounded corners – yuck! Now I tip my hat to CSS3 for providing a way to achieve just about any effect regardless of how convoluted or unnecessary it may be without resorting to adding presentational mark-up.
    The only code I hate more than my own is everyone else's.

  6. #31
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,273
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Crusty
    (At least Opera has the decency to give us the REAL CSS3 properties)
    Aha, but they actually do have -o properties. It's just that you see them a lot less because people don't write so much for Opera.

    Poor, poor Opera. Only gets any love in former Soviet States and Southeast Asia. : )

  7. #32
    SitePoint Member
    Join Date
    Jul 2010
    Location
    Bolton - UK
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    If you don't mind a giant bloated javascript that tends to break other scripting, often breaks other workarounds to get elements behaving right int the first place, and in general bloats out the code you send to EVERYONE regardless for something that frankly, you CAN USUALLY ALREADY DO IN HTML 4.
    Giant bloated javascript? Have you even looked at the shiv? Besides you can use google's minifed version and that way you don't even need to provde it yourself.

    Quote Originally Posted by deathshadow60 View Post
    Besides, it's not "future proofing" to be implementing a specification that COULD CHANGE AT ANY TIME. FUTURE PROOFING is using what works and is a recommendation in the here and now, because there's no "expiration date" on HTML 4 -- it's not like browsers are going to stop supporting it just because of some new specification that throws all the progress of 4 out the window.

    Which is where I think people fail to grasp that these new features are in said browsers for TESTING, NOT deployment -- that's the difference between "DRAFT" and "RECOMMENDATION". It's like the CSS3 browser specific prefixes, by definition they mean "for testing", "not for use on production sites".
    I can understand that argument when talking about new elements but what about simply using html5 to improve your website's functionality? What about improving your site's SEO? e.g. look at the picture below

    EDIT: Sorry can't hotlink to the image, if you google "Xenforo" you'll probably see one titled "Welcome to XenForo! | XenForo Community" underneath that within the <cite> tags you'll see some breadcrumbs, they link back to their respective sections on the forums. I've not even spent time looking into that yet myself but surely that will be beneficial for SEO?

    Xenforo is pretty new forum software, they're using html5 microdata and Google is already picking that information up. If you can provide a better experience without harming your other users then surely there's no argument against that.

    What is the harm in at least using the new doctype and using the progressive enhancements like the microdata above, new form input types etc. By simply using the number input type where you expect numerical data you'd automatically be making your site more phone/tablet friendly. You'd still want to validate the entry yourself but the more of that behaviour that's done by the browser the better in the long run.

    Quote Originally Posted by deathshadow60
    It's the SAME MISTAKE people made using IE5's CSS2 implementation, which was done BEFORE it was out of draft and BEFORE they up and decided to use a box model that wasn't compatible with the only browser that had tried to implement the draft at the time.

    ... and we're still paying for said mistake TODAY in terms of keeping IE backwards compatible.
    I'd disagree with that. Things are very different imo with how they were then. Now you have several mainstream browsers mostly singing from the same hymn sheet. And they're the ones setting the pace. Something only makes it in if multiple browsers implement it.

    There are several bits of the new CSS 3 syntax that can be implemented now with safety that the syntax won't be changing. Such as box shadow and border radius. You don't need to put the vendor prefixes in even. They're all (the main browsers) either supporting or going to be very shortly the same vendor less syntax. Obviously if you want to ensure it'll work in a slightly older version of Firefox or safari then you can put the prefixes in too but the syntax for those examples won't be changing from the current recommendation. I'm sure of that much.

    Quote Originally Posted by deathshadow60
    ... and when it's not a good solution, is worse than the older way of doing it... much less "punish WHAT?"... deploying "for testing" versions that could change at any time? Just because it's in there doesn't mean you should be using it on production code.
    The huge majority won't be changing, development is changing though and surely we should be looking to make use of the latest developments coming through. Especially when we can do quite a lot of without causing any harm to the users of older browsers. I'm not trying to force anyone to switch to HTML5 but I certainly think it's naive to exclude the entire package without taking advantage of the positive aspects of it.

    If you'd prefer to carry on using HTML 4, Tables, or whatever you're currently using then there's nothing stopping you.

    Quote Originally Posted by oddz
    Nothing is stopping you from using CSS3 with a HTML 4.01. HTML5 isn't necessary to use many of the features of CSS3 that help to promote cleaner mark-up such as; rounded corners, gradients, etc. Just make sure you degrade properly or perhaps use something like CSS PIE – additional bloat I know but its a great solution to keeping the integrity of a design in tact in <=IE8 w/ some restrictions of course. That said I haven't noticed any unexpected cross-browser inconsistency on browsers that implement CSS3 in some form. A short while ago I was very against CSS3 and thought many of the things are stupid, such as rounded-corners. However, even with the varying implementation across browsers its nice not to clutter mark-up with presentational crap to achieve a certain effect like the empty element with absolute positions or excessive wrapping to apply rounded corners – yuck! Now I tip my hat to CSS3 for providing a way to achieve just about any effect regardless of how convoluted or unnecessary it may be without resorting to adding presentational mark-up.
    Why even go that far? Why not simply use CSS3 to progressively enhance the site for users of modern browsers? Re-producing everything pixel by pixel so things look exactly the same in every browser is firstly painstaking plus unnecessary. Why resort to using CSS Pie just to make sure that you keep your rounded corners in IE 8? They won't even realize the corners are meant to be rounded.

  8. #33
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,273
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Re-producing everything pixel by pixel so things look exactly the same in every browser is firstly painstaking plus unnecessary. Why resort to using CSS Pie just to make sure that you keep your rounded corners in IE 8? They won't even realize the corners are meant to be rounded.
    Same here. When I use CSS3 stuff, it's minor and I don't try making it work in older browsers... why make those users download a steaming pile of JS just for goofy looks?

    But I do check that I'm not relying on those features in the older browsers. For example, if I use rgba() for a background, I make sure IE and everyone else old gets a solid background colour as well... contrast reasons.

    Similarly when I have "buttons" and I'm using images... usually I can also get away with adding a background colour behind the image, so users without images get similar contrast and feedback.

    re data- attributes:
    John Resig has an interesting blawg about them.
    Sounds like HTML5 trying to imitate microformats lawlz. I had forgotten about these: they are in Bruce and Remy's book as a "these are not in the book because no browser supports them yet", though I guess I'm not surprised the Googles are trying to keep up with the new stuff.

  9. #34
    SitePoint Addict EarlyOut's Avatar
    Join Date
    Mar 2011
    Location
    Sector R
    Posts
    280
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rjs37 View Post
    Why resort to using CSS Pie just to make sure that you keep your rounded corners in IE 8? They won't even realize the corners are meant to be rounded.
    Good point. In the case of corner-rounding, when it fails (older browsers), it doesn't break the layout, so it's not worth a lot of agony.

    In fact, I don't worry too much about things being slightly different in IE7 - you know, element positioning being "off" by a few pixels, and so on. Sure, the page may not look exactly the same, but as long as it's pretty close, who cares? IE7 users are now accounting for something in the low single-digit percentages of my site visitors, and they're not getting a "bad" experience, just one that isn't pixel-for-pixel identical to what other visitors see. IE8 probably has a long life ahead of it, however, because WinXP will be around for a long time.

  10. #35
    SitePoint Member
    Join Date
    Jul 2010
    Location
    Bolton - UK
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Same here. When I use CSS3 stuff, it's minor and I don't try making it work in older browsers... why make those users download a steaming pile of JS just for goofy looks?

    But I do check that I'm not relying on those features in the older browsers. For example, if I use rgba() for a background, I make sure IE and everyone else old gets a solid background colour as well... contrast reasons.
    In the case of the html 5 shiv it's a little different. If you don't use it then IE stops you from styling any of the new elements. i.e. if you put in your css that the text color of your header should be blue IE would ignore it completely unless you use a bit of javascript to essentially register the element with the DOM (to my basic understanding). There's a difference between pixel differences and functional differences. If IE behaved like the older versions of the other browsers then it wouldn't need the javascript fix. In CSS the respective elements (header, footer) need to be set as being display block but that's the only issue with using the new element in the other browsers (except for PS3 as I found out last week).

  11. #36
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,273
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    In the case of the html 5 shiv it's a little different. If you don't use it then IE stops you from styling any of the new elements. i.e. if you put in your css that the text color of your header should be blue IE would ignore it completely unless you use a bit of javascript to essentially register the element with the DOM (to my basic understanding). There's a difference between pixel differences and functional differences. If IE behaved like the older versions of the other browsers then it wouldn't need the javascript fix. In CSS the respective elements (header, footer) need to be set as being display block but that's the only issue with using the new element in the other browsers (except for PS3 as I found out last week).
    And I refuse to force people to need scripts for their user agent to read markup. YMMV

    Prolly why I'm more ok with CSS3 stuff than HTML5 stuff

  12. #37
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Rjs37
    Re-producing everything pixel by pixel so things look exactly the same in every browser is firstly painstaking plus unnecessary. Why resort to using CSS Pie just to make sure that you keep your rounded corners in IE 8? They won't even realize the corners are meant to be rounded.
    Over 50% of the audience is in IE and the integrity of the design relies heavily on rounded corners w/ opacity. Besides CSS PIE is actually very simple use. Furthermore, its much easier to implement CSS PIE than explain the technical aspects to marketing/sales/higher-ups using IE. Its never a good thing when you need to explain to none-technical people that the browser they know well is not going to provide the same experience as one they do not. Avoiding that conversation as much as possible keeps me sane. I rather work harder to make keep the integrity intact than need to deal with defending "graceful degradation" to a majority of people who are going to be viewing the site in a degraded form. That isn't always the case, but many times it is.
    The only code I hate more than my own is everyone else's.

  13. #38
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,273
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    and the integrity of the design relies heavily on rounded corners w/ opacity.
    Guess I'm a function-over-form kinda girl. I would agree with you if the client was a large brand like Adidas or Audi who use their web sites purely to push their global brand, where tiny stupid cutesy things like opacity really did matter somehow (not that CSS would have any involvement anyway... those people are such suckers for Flash/Silverlight it's not funny).

    Beyond that: ffffffffp. I've not seen a case where a lack of rounded corners or opacity made a site less usable or marketable, just maybe ugly.

    But I'm willing to change my mind if I see such a site.

  14. #39
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Well I'm not the one making the designs, but implementing. Its my job to get "as close" to designers vision as possible. Coming from a design background myself I try my best to keep the integrity of the design in tact, even if that means adding some additional code to the mix, so be it. When some people might say no I generally try my best to get things looking as envisioned by the designer.
    The only code I hate more than my own is everyone else's.

  15. #40
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,273
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I'll go to lengths to get something I want visually, so I understand that. If it's a bit of extra markup, it's prolly going to end up in my live code.

    I kinda like to draw the line at asking people to consume more bandwidth, make extra requests on my (or whomever's) server, just for teh Pretteh. I know lots and lots of people do though. Developers differ. Plus, I don't currently have to slave away for some graphix d00d right now, so I can haz freedomz.

  16. #41
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rjs37 View Post
    Giant bloated javascript? Have you even looked at the shiv? Besides you can use google's minifed version and that way you don't even need to provde it yourself.
    The shiv is cute at 2k minimized, even if (laugh) it runs a javascript IE conditional when they say to include it with a IE conditional in the markup (what the?!?)... but it's 2k of .js and 100 bytes of markup (the latter sent to EVERYBODY) that I very much doubt would be made up for by any "savings" of using the extra useless wrapping elements it actually implements. Much less the drag it places on page load since it has to create a bunch of new elements on the DOM. (and user elements are always many times slower than system ones).

    But my idea of bloat and other people's often diverge -- since my ideal target size for a single page on a site is 70K, with 140K as my 'upper acceptable limit'.

    Quote Originally Posted by Rjs37 View Post
    I can understand that argument when talking about new elements but what about simply using html5 to improve your website's functionality?
    How so, with what? In terms of MARKUP (as opposed to all the crap they're calling HTML 5 that has NOTHING to do with HTML) I don't see any improvements except a couple of form things I'd STILL have to code server side.

    But then, I rarely have a single page's markup break 16k... so sending to the server and recieving back usually takes as little time as client side validation unless it's something monstrous like a forum post or blog comment... Neither of which usually NEED client side val.

    Quote Originally Posted by Rjs37 View Post
    What about improving your site's SEO? e.g. look at the picture below
    I don't see that as an improvement; But then I actualy do this CRAZY thing called "proper heading orders" instead of the "vomit up tags any old way" method.

    Quote Originally Posted by Rjs37 View Post
    EDIT: Sorry can't hotlink to the image, if you google "Xenforo" you'll probably see one titled "Welcome to XenForo! | XenForo Community" underneath that within the <cite> tags you'll see some breadcrumbs
    WHAT THE **** are breadcrumbs doing inside a CITE tag?!? Though I think I found the site you mean -- damned if I can find any CITE tags on it. What I do see is a useless ID attribute on the HTML tag (/FAIL/), classes on it (double /FAIL/), use of a BASE tag (what is this, 1997?), Noscript wrapping a style embed (wow, that's stupid - if that's a script only element make it with the bloody script instead of sending it to everyone!) and I'm not even past the first five lines. Whole bunch of pointless bandwidth chewing meta "properties", nonsensical heading order (first heading on the page is a h3), heading around a non-heading element (that login is NOT a structural heading), empty span with a class on it for christmas only knows what, triple digit div count doing a couple dozen's job, endless nested spans on those breadcrumbs for what should be a list, blockquotes around elements that aren't quotes, article tags around post entries (which I wouldn't consider articles), fieldset outside a form around non-form elements...

    ...and that's before we talk the crappy uselessly undersized fixed metric fonts, serif fonts on content making it even HARDER to read, and color contrasts below legibility norms.

    NOT exactly blowing my skirt up, and anyone who thinks that's good SEO or semantic markup needs to go back and learn what those MEAN!

    Which is why much like many other forum softwares of late, the default skin sucks down 40 malfing K of markup to deliver 4.4k of content -- showing they need to go back and learn some HTML -- or at least that as George Carlin said "not every ejaculation deserves a name"... Which is to say not every blasted element needs a DIV or SPAN around it and a class on it. Would REALLY help if they stopped using presentational classes and ID's and bothered saying what things ARE.

    Just to give you an example, this:
    Code:
    	<fieldset class="breadcrumb">
    		<a href="misc/quick-navigation-menu?selected=node-2" class="OverlayTrigger jumpMenuTrigger" data-cacheOverlay="true" title="Open quick navigation"><!--Jump to...--></a>
    			
    		<div class="boardTitle"><strong>XenForo Community</strong></div>
    		
    		<span class="crumbs">
    			
    				<span class="crust" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
    					<a href="http://xenforo.com/" class="crumb" rel="up" itemprop="url"><span itemprop="title">Home</span></a>
    					<span class="arrow"><span></span></span>
    				</span>
    			
    			
    			
    				<span class="crust" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
    					<a href="http://xenforo.com/community/" class="crumb" rel="up" itemprop="url"><span itemprop="title">Forums</span></a>
    					<span class="arrow"><span>&gt;</span></span>
    				</span>
    			
    			
    			
    				
    					<span class="crust" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
    						<a href="http://xenforo.com/community/#official-forums.1" class="crumb" rel="up" itemprop="url"><span itemprop="title">Official Forums</span></a>
    						<span class="arrow"><span>&gt;</span></span>
    					</span>
    				
    					<span class="crust" itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
    						<a href="http://xenforo.com/community/forums/announcements/" class="crumb" rel="up" itemprop="url"><span itemprop="title">Announcements</span></a>
    						<span class="arrow"><span>&gt;</span></span>
    					</span>
    				
    			
    		</span>
    	</fieldset>
    Is one giant steaming pile of ineptitude for what should probably simply be:

    Code:
    	<ul class="breadCrumbs">
    		<li><a href="/">Home</a></li>
    		<li><a href="/community/">Forums</a></li>
    		<li><a href="/community/#official-forums.1">Official Forums</a></li>
    		<li><a href="/community/forums/announcements/">Announcements</a></li>
    	</ul>
    All that extra crap is just pointless wasteful bloat that actually makes the page HARDER to use!!! Especially since search engines aren't exactly in a tearing rush to implement that "itemtype" nonsense. Fat bloated useles BULL! Especially that annoyingly bloated scripting for nothign jumpto train wreck. (all to do what accesskeys menus in Opera and Blazer have been doing since 1998)

    EVEN IF you wanted the itemtype crap in there, that's STILL not "a bunch of anchors and spans" it's a list of choices, and there's NO reason for that extra arrow span apart from coder ineptitude.

    As illustrated by that even with the CSS3 stuff on there, it's a fat bloated 563k of javascript, 125k of CSS (FOR WHAT?!?!) and even after compression sucks down 248k alltogether...

    To again, deliver 4.4k of plaintext. Yeah, I'm SO impressed there.

    Quote Originally Posted by Rjs37 View Post
    Xenforo is pretty new forum software, they're using html5 microdata and Google is already picking that information up. If you can provide a better experience without harming your other users then surely there's no argument against that.
    Is it picking up the "microdata" (which I'm not actually seeing on the page), or just the relevant text on the page? I'm a firm believer that extra information NOT displayed to the user is likely going to get slapped down and restricted to the same point as previous data marking attempts like the keywords meta.

    Quote Originally Posted by Rjs37 View Post
    What is the harm in at least using the new doctype and using the progressive enhancements like the microdata above, new form input types etc.
    the HTML 5 "validation" is a joke since it's one giant tranny doctype making code debugging harder, it's bloat that the average user will NEVER see, it's taking time concentrating on stupid extra elements instead of focusing on what you should REALLY want the search engines to work with -- the CONTENT. Microcode in particular reeks of the same idiocy as "microformats" -- useless bloat that quite frankly if the content with a semantic tag doesn't convey enough information, there's something wrong with the content! (See my opinion of the title attribute in 99% of the cases people use it)

    Quote Originally Posted by Rjs37 View Post
    I'd disagree with that. Things are very different imo with how they were then. Now you have several mainstream browsers mostly singing from the same hymn sheet. And they're the ones setting the pace. Something only makes it in if multiple browsers implement it.
    It just reeks of the same stupidity to me -- back then it was "well IE's the only browser that matters" -- oddly enough making it the SAME arguement if everyone supports it. NOT that everyone is implementing things the same way.

  17. #42
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,273
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    There's just one point I'll disagree with you here, Crusty:
    article tags around post entries (which I wouldn't consider articles)
    I didn't read the "posts", but the HTML5 guys do consider blog posts to be candidates of <article> tags. <article> isn't a very "big" tag. Any group of information that you could conceivably syndicate (get thrown onto another site somewhere) can be an article. It doesn't have to match the definition of "article" as in, an entire newspaper article, or even a newspaper column. Someone's blawg of two paragraphs and a header could be an <article>.

    The "microdata" is only seen in the source, as "data-*" attributes. I know Google does show microformat data (when searching a product, you may see star ratings, reviews, dates, and other things as little submenus in the search results), but I dunno if they really do also see these new data-* attributes. But if they do, they would be treated the same as vcard/hcard/blah blah microformats.

  18. #43
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    There's just one point I'll disagree with you here, Crusty:
    I can see the reasoning I guess on those -- but article around blockquote on EVERY SINGLE ONE? (The blockquotes are the real whiskey-tango-foxtrot)

    Those are not quotes... It just comes across as more "let's slap every tag on the planet around simple elements and call it semantic" -- who cares what those tags actually mean.

    About two thirds of the tags used in that forum skin serving no reasonable purpose. (fittting well with it's 500+K of javascript for NOTHING useful)

  19. #44
    SitePoint Member
    Join Date
    Jul 2010
    Location
    Bolton - UK
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    WHAT THE **** are breadcrumbs doing inside a CITE tag?!? Though I think I found the site you mean -- damned if I can find any CITE tags on it. What I do see is a useless ID attribute on the HTML tag (/FAIL/), classes on it (double /FAIL/), use of a BASE tag (what is this, 1997?), Noscript wrapping a style embed (wow, that's stupid - if that's a script only element make it with the bloody script instead of sending it to everyone!) and I'm not even past the first five lines.
    I'll just resolve the confusion I caused by mentioning the cite tag. I was talking about on google's listing, it shows the xenforo breadcrumb links within a cite tag (green text under the description). The fact that google is picking up that information and using it to show a linkable breadcrumb structure for the site is an interesting thing to see.

    I'm certainly not saying that their syntax is perfect (there does seem to be a lot of waste e.g. a header element around a div with an id of header) but likewise it's nowhere near as bad as you're making it out to be. Plus the js isn't doing 'nothing' they're actually providing a better experience (imo at least) for the user but I guess we can forget about doing that and just concentrate on the markup?

    Besides I wasn't even posting the link to have it's syntax analysed I was just giving an example of one of the other things that can be done with html 5.

  20. #45
    SitePoint Wizard bronze trophy
    Join Date
    Oct 2001
    Location
    Vancouver BC Canada
    Posts
    2,029
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the clarification Rjs37. Those are some pretty interesting points that would have been overshadowed if you hadn't clarified them.

    The cite tags are nothing new on Google listings however your point is that rather than just having a typical single link to a page as is usually the case, Google has provided a breadcrumb to the Xenforo site. Each leg of the breadcrumb goes to a different url on the Xenforo listing which matches the breadcrumb on the page referenced in the search engine result. That is interesting and something I hadn't seen before. I did a few other searches that I thought might come up with a similar cite breadcrumb structure. I didn't spend long on it but Xenforo is the only one I've seen so far.

    * Interesting that Google is using HTML5 markup too.
    Andrew Wasson | www.lunadesign.org
    Principal / Internet Development

  21. #46
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rjs37 View Post
    I'll just resolve the confusion I caused by mentioning the cite tag. I was talking about on google's listing, it shows the xenforo breadcrumb links within a cite tag (green text under the description). The fact that google is picking up that information and using it to show a linkable breadcrumb structure for the site is an interesting thing to see.
    Sorry to say I think that has NOTHING to do with any of that extra markup bloat.

    Why do I say this... because my steaming pile of 7 year old code-rot from before I embraced strict manages that without any of that nonsensical bloat.

    So... I think not. That data is likely coming from somewhere else... or just from the text being there on the page.

    Also, I'm not seeing any CITE tags in the code there either... though it's interesting how google isnt' even bothering with external sheets on static CSS for pages where that CSS shouldn't vary. You'd think they of all companies would at least TRY to leverage caching models... same for the static scripting.

    that's kind-of funny, in ten minutes worth of changes they could probably cut their bandwidth use by a third just by using "LINK" and "SCRIPT src="

  22. #47
    SitePoint Wizard bronze trophy
    Join Date
    Oct 2001
    Location
    Vancouver BC Canada
    Posts
    2,029
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Sorry to say I think that has NOTHING to do with any of that extra markup bloat.

    Why do I say this... because my steaming pile of 7 year old code-rot from before I embraced strict manages that without any of that nonsensical bloat.

    So... I think not. That data is likely coming from somewhere else... or just from the text being there on the page.

    Also, I'm not seeing any CITE tags in the code there either...
    I think Rjs37 mentioned that he's not championing that particular HTML5 markup and I hoped to avoid a HTML5 vs HTML-else debate however what Rjs37 pointed out about the use of microformats in the breadcrumb is undoubtedly factual.

    * The citation markup is on the Google SERP so you won't see it in the Xenforo markup.

    If you examine the breadcrumb markup on the Xenforo site you can't help but see the microformat. Look for "itemtype=". There's some more information here that explains why it works with Google. ( Caution, the colours on that site will hurt your eyes )

    HTML Code:
            <span class="crumbs">
                
                    <span itemtype="http://data-vocabulary.org/Breadcrumb" itemscope="itemscope" class="crust">
                        <a itemprop="url" rel="up" class="crumb" href="http://xenforo.com/"><span itemprop="title">Home</span></a>
                        <span class="arrow"><span></span></span>
                    </span>
                
                . . . 
                
            </span>
    Andrew Wasson | www.lunadesign.org
    Principal / Internet Development

  23. #48
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by awasson View Post
    however what Rjs37 pointed out about the use of microformats in the breadcrumb is undoubtedly factual.
    Then how is a site WITHOUT any of that fat bloated useless bull managing the exact same effect in it's SERP.

    Much less said "microcode" is idiotically redundant to the markup itself -- needing to use an extra attribute to say an anchor with an href is the URL? An extra span just to say that the text inside the anchor is the title?

    Itemscope, itemprop, and itemtype are useless pointless bloated BULL -- hard to believe such idiocy comes from the same people who want to stamp out versioning and use a lip-service doctype.

    Though at least the site you linked to's examples does it PROPERLY with a bit less of that idiotic endless span for nothing manure.

    Though this:
    <span itemprop="title">HTML 5</span>

    has to be the DUMBEST thing I've seen out of the HTML 5 spec yet. OMG, the text inside an anchor is it's title? NO, REALLY? WHO'D HAVE GUESSED?!?

    Take their example:
    Code:
    <ul class="breadcrumb-trail">
       <li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
          <a itemprop="url" rel="up up up" href="/index.html">
             <span itemprop="title">HTML 5</span>
          </a>
       </li>
       <li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
          <a class="nobr" itemprop="url" rel="up up" href="/tags/index.html">
             <span itemprop="title">HTML Tags</span>
          </a>
       </li>
       <li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
          <a itemprop="url" rel="up" href="./">
             <span itemprop="title">HTML <a href> Tag</span>
          </a>
       </li>
       <li itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
          <a itemprop="url" href="#examples#">
             <span itemprop="title">Examples</span>
          </a>
       </li>
    </ul>
    What nimrod thought that was a good idea? Probably the same dumbasses who slap classes on every LI when they all receive the same property. Talk about your bloated redundant bs garbage coding for NOTHING.

    If they had half a brain, they could PROBABLY have just used ONE property, something like list-type="breadCrumbs" that goes on a UL... saying ALL anchors inside it are "urls" (again, no, really?) and all content inside anchors are *SHOCK* the text for the anchor.

    It's this type of idiocy that explains WHY I think HTML 5 is the biggest steaming pile of garbage released as a web specification. It's a bunch of bloated redundant NONSENSE!

  24. #49
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Actually -- hah, their links in the SERP do NOT match their code... like, at all. their home page gets better results, and it doesn't even have that microcode nonsense in it.

    In fact, I can find NO correlation between their google result and any of that extra code. Or is that because I'm an opera user and not getting their new bloated slow as molassas javascripted nightmare they throw at FF/Chrome users? Sad when google is forgetting what made them successful in the first place.

    Nope, tried FF, same... the results on a google search do not make ANY use of ANY of their "microcode".

  25. #50
    SitePoint Wizard bronze trophy
    Join Date
    Oct 2001
    Location
    Vancouver BC Canada
    Posts
    2,029
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Then how is a site WITHOUT any of that fat bloated useless bull managing the exact same effect in it's SERP.
    It doesn't.... I've looked.

    Quote Originally Posted by deathshadow60 View Post
    Actually -- hah, their links in the SERP do NOT match their code... like, at all. their home page gets better results, and it doesn't even have that microcode nonsense in it.

    In fact, I can find NO correlation between their google result and any of that extra code. Or is that because I'm an opera user and not getting their new bloated slow as molassas javascripted nightmare they throw at FF/Chrome users? Sad when google is forgetting what made them successful in the first place.

    Nope, tried FF, same... the results on a google search do not make ANY use of ANY of their "microcode".
    Prove it... Quit being such an obnoxious windbag and find SERPS that cite an ordered breadcrumb as shown in the SERP for Xenforo.

    What I'm looking for is the cite markup in green on the 4th line:




    Which relates to the breadcrumbs on the page that was linked from the SERP:




    Are you seeing anything similar here?

    Also don't make foolish blanket statements like you're an expert on Google and microdata... Stating that Google's cite markup on its SERP don't match the markup of Xenforo's breadcrumbs, means nothing. That's not the way parsing information works. I haven't parsed microformatted markup like this myself but I would suspect that it is very similar to parsing XML which I have a lot of experience with. When you parse all you're going for is the data... You strip the rest and then output it any damn way you want.

    Do you think Google retains the format of anything when they index it?
    Andrew Wasson | www.lunadesign.org
    Principal / Internet Development


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •