SitePoint Sponsor

User Tag List

Page 11 of 17 FirstFirst ... 789101112131415 ... LastLast
Results 251 to 275 of 402
  1. #251
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Well, what about CSS? You have to style the link, not the direct element. Surely that's a disadvantage?
    It's not clear to me why it's a problem to style the link instead of the <li>.

    Quote Originally Posted by arkinstall View Post
    I'm pretty sure that existing browsers will have alot of problems, not just with this.
    Not sure how that is relevant.

    Quote Originally Posted by arkinstall View Post
    The web needs to move on, and wanting a backward-compatible spec is not just unrealistic,
    Why is it unrealistic?

    Quote Originally Posted by arkinstall View Post
    it can cause more problems than it solves.
    What problems does it cause?
    Simon Pieters

  2. #252
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    A new specification is a new specification. Whilst I agree that maintaining backwards compatibility does have its benefits, there are some issues that need to be considered. I'm sure they have, but hey I've started so I'll finish!

    Ok, say you drive a car (manual). You're used to pressing down the clutch with your left foot, shifting to first gear, pressing the accelerator a bit, lifting the clutch till you find the bite and releasing the handbrake, lifting the clutch and getting your foot down on the accelerator and you're off.

    Now, you've been doing it for years, so to your mind it's just a case of doing all steps without needing to think about it.

    What if, one day, two brand new car types came out. One used a joystick, and you drive simply by pulling back (the trigger for the rocket launchers at the rear, as standard ). So, you retrain your mind into using this new method and it won't take long, because everything's so new you learn it from scratch.

    The other car uses the same things as the original car, but the accelerator is now called the doodle, the clutch is now in the middle and the brake is now where the horn was. The clutch works differently now - the bite is right at the bottom and its definition has now changed a bit.

    This is actually going to be harder to learn how to drive. Not only do you have to do more than the joystick-controlled car, but you are used to this layout. You're used to having those three foot controls, but now they do different things.

    Basically my long-drawn-out point is that if you're in a new environment, you will learn things quickly and get used to it. If you're in an environment similar to what you're already used to, you're going to treat it as if it hasn't even changed and things are going to go wrong.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  3. #253
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,893
    Mentioned
    123 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Ok, think about it like this.

    What benefit is there to having the heading number?

    As far as I can see, the only reason was so that people could style certain headers, though that could be done with:
    [highlight=css]section section section h{

    }[/higlight]etc.

    But is there another reason, at all, to keeping the numbers that a good sectioning couldn't do?
    The benefit to having the heading number is that it makes it massively, massively easier for authors to ensure the correct style applies, the structure of the document is easier to determine, and the relative importance of different elements can be seen without needing to reconstruct the entire document context.

    What is the advantage to having to define section section section h {...} when h3 {...} does the job? Your proposal makes CSS mammothly complicated, and immensely more difficult for authors to ensure that headings appear at the correct level. And have you thought about how editors and CMS packages could cope with this? The level of authoring knowledge needed to nest <section>s is dramatically higher than that needed to pick <h1>, <h2> or <h3>.

    Apart from a hypothetical 20-level hierarchy of headings (which, as I said, is completely impractical and implausible), what would be the possible advantages of replacing all <hn> elements with a generic <h> element?

  4. #254
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,893
    Mentioned
    123 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by zcorpan View Post
    In HTML5 you can do <a href><ul> and <a href><div>.
    You're right, and that is a great advantage that pretty much negates any need to apply href to generic elements.

  5. #255
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,893
    Mentioned
    123 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by arkinstall View Post
    One thing I'm unclear on is the whole point of <nav /> -surely that's just renaming a <div />?
    It provides additional semantic information about the purpose of the section. By making the navigation section of the page programatically specified, you allow user agents (especially assistive technnology) to react to that and, eg, automatically skip <nav> elements unless instructed otherwise.

    There are plenty of inline and block elements that convey far less-useful information than this!

    You say that HTML5 has <h> but it's named <h1>... I'm not sure if that was a sarchastic remark or if you meant it!

    If you did, does that mean I can do exactly the same as my code above but with <h1 /> rather than <h />? In which case, most of my reasons for preferring XHTML2 are moot!
    In HTML5, you can use <h1> for every heading, with nested <section> elements to create the structure. Or any other level of heading. A document map is created from a combination of the number-leveled headings and the nested sectioning elements

    For example, the following three examples are equivalent in HTML5.

    HTML Code:
    <h1>
    <p>
      <h2>
        <h3>
        <p>
        <h3>
        <p>
      <h2>
      <p>
    HTML Code:
    <section>
    <h1>
    <p>
      <section>
      <h1>
        <section>
        <h1>
        <p>
        <h1>
        <p>
        </section>
      <h1>
      <p>
      </section>
    </section>
    HTML Code:
    <section>
    <h4>
    <p>
      <section>
      <h6>
        <section>
        <h1>
        <p>
        <h1>
        <p>
        </section>
      <h6>
      <p>
      </section>
    </section>

  6. #256
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by zcorpan View Post
    No; Atom does not have a doctype.
    That is because Atom and SVG are based upon XML, which is a subset of SGML designed to make the parser easier to use, one of these simplifications is the omitting of a DOCTYPE and the use of an XML declaration with the possibility of using XML Schema (though DTS's can be used). XML itself is not technically an SGML following language.

  7. #257
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,893
    Mentioned
    123 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by arkinstall View Post
    So this means one could use:
    Code html:
    <nav>
        <a href="/">Home</a>
        <a href="/etc">Et Cetera</a>
        <a href="/etc/etc">Et Cetera Et Cetera</a>
    </nav>
    ?
    I think that would be wrong, as <nav> elements must contain <li> elements. What you have written would be just as incorrect as having a <ul> element containing <div>s and nothing else.

    Think of <a> as you would <ins> - it contains inline content or block-level elements, but it can't be used as a block-level element itself.

    What you've written would be technically valid in HTML4, just replace <nav> with <div> - you can define div.nav a {display:block;} in your CSS - but it is bad practice as you should not have discrete <a> elements separated by no more than white space.

  8. #258
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stevie D View Post
    I think that would be wrong, as <nav> elements must contain <li> elements.
    No, <nav> does not need to contain <li> elements. <nav> is like <section>, not like <ul>.
    Simon Pieters

  9. #259
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Quote Originally Posted by cooper.semantics View Post
    If i'm not mistaken ie8 does not support xhtml QUOTE]

    You are not mistaken, it doesn't.

    Of course no browser supports HTML 5 - fortunately.
    Ummm. I can and have written HTML5 documents and for the most part they work all the way back into IE6, so long as you grant me a few lines of javascript (Nothing fancy, just a few "createElement" calls).

    Not 100&#37; of the HTML5 spec, but it's the semantically useful portions. (The snarky part of me wants to say "Better support than XHTML2 -- even 1.1 strict -- has" but that's not really relevant.)

    Oh, and as for "no professional would use it," have a look at this

    There are a lot of us who have given up on MS supporting XML, and have given up on the morass that is XHTML. HTML5 looks better to me than XHTML2; I certainly don't see a reason to keep walking down a trail that hasn't really taken me anywhere worthwhile.

    HTML5 seems cleaner and clearer to me. XHTML never delivered on the promises, and has been mired in questionable support for over a decade, now. How long do we give it before we call it a pipe dream and get back to work?

    SGML-derived tools always seem to get mired in complexity as we search for the One True Tag Scheme to make the whole thing make sense. I'm tired of waiting. You ever find it, give a shout and I'll come back and take a look.

    Of course, if you really want to continue to pretend that XHTML works, then there's always XHTML5, the XHTML variant of HTML5.

    To me, the directness of HTML5 is refreshing. You have a nav block on the page? use <nav>. You have an article divided in sections, with section headings? use the article, section and header tags.

    It's clean, clear and simple. I don't see a down side.

    Oh, and I like the header tags for styling far more than the numbered ones. They're much easier to style:

    article header { article head styles}
    article section header { section head styles}
    article section section header { subsection head styles }

    (BTW, if this doesn't immediately appear simpler to you, then you've never had to deal with h4's or h3's that mean different things in different contexts on the page, such as widget headers vs sidebar headings vs section headings in a document. Let's see, these widgets all use h3 as a heading. Why? <insert arbitrary reason here> Since the reason is arbitrary, and the numbering scheme is arbitrary, why bother pretending it means something? Call it a header and get back to coding. Numbered headings made sense when a web page was a single document. Look around you; there are a whole lot of complex, multi-document pages these days. Check the front page of Sitepoint and see how many documents are included on that one page.)

    Use header you don't need to keep track of some artificial numbering scheme, and further, you're spared fighting the constant religious war over whether you're allowed to jump a number (go directly to h3 from h1, etc.) and whether you can have more than one h1, or have an h3 without an h1, etc.

    As for CMS's, I can't speak for all of them, but Joomla handles HTML5 the same way it handles XHTML1 -- with lots of template overrides. I've written an HTML5 template for Joomla already. (I'd post the link, but the site isn't finished, yet. The template works, the content just isn't there and the domain published, yet.) There really is no reason most CMS's wouldn't handle HTML5 any worse than they'd handle a new XHTML spec.

    There's no SGML doctype for HTML5 because it's not SGML, and doesn't pretend to be. (need proof? Here's a direct quote from the draft spec: "...neither of the two authoring formats defined in this specification are applications of SGML..." Can't get much more direct an answer than that.)

    The valid HTML5 doctype statement is:

    <!DOCTYPE html >

    (Ooooooh. scary simple!)

    Personally, I find the acknowledgement comforting. AFAIK, no browser existing today is an SGML parser, or even comes close to obeying the rules for parsing SGML. So why keep up the fiction of SGML on the web?

    To me it's a matter of pragmatism. This is the way it is, and putting a tuxedo on a pig still leaves you knee-deep in pork.

    Look, is HTML5 perfect? Don't be silly. Of course not. But it's already got better support in existing browsers than XHTML2, and all the major browser makers are members going forward with it.

    You want to continue riding the XHTML horse? Go ahead. I'm not telling you to stop. But to try and crap all over HTML5 without making even the simplest pretense of studying it and understanding it is plain foolish.

    A lot of us are rethinking the basic premise of XHTML, and wondering if that is actually the road we want to take. So we're off playing in HTML5-land. So far, I think it's a better place, but it's still being built out, and yes, things could always turn ugly later.

    I just know that things are already ugly in XHTML-land.

    Pardon my length, but the nays have had the thread pretty much to themselves up to this point, so I had a lot of ground to cover.

  10. #260
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Ummm. I can and have written HTML5 documents and for the most part they work all the way back into IE6, so long as you grant me a few lines of javascript (Nothing fancy, just a few "createElement" calls).
    How lovely, so your design will break for anyone not having JavaScript enabled (poll's I have seen based on usability studies show this at approximately 8&#37; of people), also for those who do not have access to JavaScript functionality... so there go your mobile platform visitors (with exception of a few modern phones) and some of your disabled users. Remind me again why you would start implementing a technology which is not even finalised, has to rely on obtrusive scripting and in doing so violates accessibility recommendations? Not to mention the fact that search engines probably aren't even using the HTML5 specification to determine how those new tags should be used in ranking your content, so now your website is as redundant in principle as a Flash document.

    So basically around 10% of your visitors and every search engine will have their experiences damaged because you feel it is relevent to implement something in beta stage.

  11. #261
    SitePoint Wizard silver trophybronze trophy
    Join Date
    Jul 2008
    Location
    New York, NY
    Posts
    1,432
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    XHTML2 might never peak to the seams since the web actually is become(or always has been ) an unsemantic joke and caters to legacy browsers. Is this the webs fault? yes I feel it is... Everything boils down to money. For example google I presume caters back to IE5 and maybe even before IE5, who knows but my point being 'google' doesn't want to lose those users. They want as many people using their applications as possible....

    Will the web change? Yeah maybe 30 years from now when IE9/IE10 is out...

  12. #262
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    How lovely, so your design will break for anyone not having JavaScript enabled (poll's I have seen based on usability studies show this at approximately 8% of people), also for those who do not have access to JavaScript functionality... so there go your mobile platform visitors (with exception of a few modern phones) and some of your disabled users. Remind me again why you would start implementing a technology which is not even finalised, has to rely on obtrusive scripting and in doing so violates accessibility recommendations? Not to mention the fact that search engines probably aren't even using the HTML5 specification to determine how those new tags should be used in ranking your content, so now your website is as redundant in principle as a Flash document.

    So basically around 10% of your visitors and every search engine will have their experiences damaged because you feel it is relevent to implement something in beta stage.
    Amusing.

    a) IE6 isn't on any mobile phone that I'm aware of.
    b) It's not obtrusive scripting, fer pete's sake. It simply creates elements so other tags of that type are visible to the browser's rendering engine. The created elements aren't even attached to the document.
    c) No one who visits that site has javascript turned off. How do I know this? Because there are other elements of the site that are javascript dependent. (Among other things, it features a javascript engine to replay chess games.)

    The first thing any designer worth his salt understands is the audience for the site, and everything builds out from that. The audience delimits the tools, and the audience for this site uses js. The audience also rarely uses a web browser to replay games on a cell phone over the net. The most often used cell phone paradigm is downloading the games into the phone for replay there on a program expressly built for the purpose.

    (A real itch for me is to just let IE users see the design the way it is, and stop trying with all the filters and workarounds to make up for Microsoft's inability to build a real browser -- have they even managed to get the CSS1 property background-position: fixed working properly yet? -- but I live in the real world, so for now that's not an option.)

    Try to refrain from making comments about things you aren't familiar with, OK? It's certainly not helpful, and it doesn't show off your best side, Alex.

    Feel it necessary? No. Feel it useful? Yes. Just as I've implemented things from CSS2.1 in my designs. (CSS2.1 is still a draft spec, that hasn't been approved, after all. It'll remain a draft at least until July, yet, and maybe longer.) Frankly, I don't care about the status of the spec nearly as much as I care about browser support (what good's an approved spec if there's no support?) so once it's available in what I would consider the core browsers for a particular site's audience, it's time to crack open the bottle and let the goodness pour. I've also used things from CSS3, and that's just as "beta" as HTML5. (Hey wasn't there a Sitepoint Article about that not too long ago?) OK, maybe it's a little less beta, as it started in 2001 while HTML5 started in 2003. Still, after 6 years it's had time to thread its way into all but the most recalcitrant (yes, I'm looking at you, Microsoft) browsers.

    Oddly enough, it was Firefox that caused more problems for the design than IE, after applying the Resig shiv, but they weren't serious and took very little effort to debug.

    As I said, you want to stand by the XHTML tree, go right ahead. I certainly won't stop you. I have no faith in that particular path, but that by itself shouldn't stop you or anyone else following it. I just wasn't going to let what was largely uninformed attacks on HTML5 go by unanswered.

    And frankly, I don't see what the heartburn about HTML5 is. In fact, I see HTML5 as being more semantically valuable than XHTML. One example, I find the nav tag to be far more semantic than a class attribute attached to a list. It identifies precisely what this section of the page is all about. The structural sections of an XHTML page rely on attributes (and there's no consistency there, as sometimes they're class attributes and sometimes they're id attributes) for any semantic meaning, and there's no standardization from one site to another, while the HTML5 nav and header tags are consistent.

    When I first saw it, a couple of years ago, I was a little put off by it. But then I realized the basic advantage of HTML5 was that the builders were asking "why?" questions. We do a lot of things with XHTML because it's the only way that language will let us do them. Why do we mess with numbered headings, when it's the document context that should determine how they're styled, and not some arbitrary numbering scheme that is never followed consistently from site to site? Why don't we have a consistent naming convention for the navigation blocks that are present on 99.44% of the pages on the web?

    I know I'm just scratching the surface of some of the semantic possibilities in HTML5, and I'm looking forward to getting better at it. But to me HTML5 has more possibilities than XHTML, and delivers on them more simply. You don't think so, fine. Don't sneer at HTML5, spend your time coding XHTML sites that prove me wrong. I haven't seen any, yet.

  13. #263
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arlen View Post
    There are a lot of us who have given up on MS supporting XML...
    Microsoft already has had extensive support for XML for a long time now. Don't confuse XHTML support with XML support now.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  14. #264
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Arlen View Post
    Amusing.

    Try to refrain from making comments about things you aren't familiar with, OK? It's certainly not helpful, and it doesn't show off your best side, Alex.

    I just wasn't going to let what was largely uninformed attacks on HTML5 go by unanswered.

    You don't think so, fine. Don't sneer at HTML5, spend your time coding XHTML sites that prove me wrong. I haven't seen any, yet.
    Arlen, please try to refrain from making personal and deliberately offensive statements, you do not know me as a person, and you certainly have no reason to make statements about how I choose to create websites. I am certainly not sneering at the use of HTML5, while there are things I do not agree with there are elements of the specification which I think are of a vast improvement over HTML4. Making unfounded comments deliberatly constructed to insult me make you feel better but as you have no idea to what extent my coding abilities are, those kinds of personal attacks make you out to be quite petty and hurtful.

    My problem with what you said was your reliance on JavaScript and obtrusive coding, and that alone. No website should be forced to rely on a particular technology being enabled, especially with the ever increasing amount of security conscious individuals who choose to have scripting disabled. Just because the scripts are not actively splashed all over your source code does not mean it is free of being obtrusive, without JavaScript being enabled, certain parts of your website (and in this case, the elements within HTML5 you have chosen to address, possibly for the use of applying style) will inevitably be unable to function or visually render properly due to the non-support from older browsers with scripting turned off. This is by definition obtrusive.

  15. #265
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Well, now, "render properly" when you're talking about IE6 (which is separate from functionality) isn't something many of us worry about anymore. For instance, I've unfortunately been using a CSS expression (javajunk basically) to make a fixed footer for IE6 and under. Without it, the user does have the unfortunate rendering of the footer sticking in the middle of the page-- normally unacceptable because it interferes with functionality but I couldn't find a way around it (my fault/problem, I admit, tho the fixed footer was not my choice). But let's say it didn't interfere with functionality, there are other examples-- min-width is another-- where the rendering gets pretty poor, and we use javajunk as a crutch for the crippled browser. Which in general is a justified cause. He did say he was using the JS for IE6's failures. Is this not the same?

  16. #266
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Stomme, I have no problem with using JavaScript to add graceful functionality to a website, but when that website becomes entirely dependent on JS being enabled to function correctly, this is where I draw the line and it becomes obtrusive. For instance on a website I have been working on, IE6 does not support position fixed however if JS is enabled, the same functionality is given, but the main difference here is... if JS is turned off, IE6 will still render the website correctly, it will just be missing that fixed header functionality. Gracefully degrading code is one thing, having the entire style and / or functionality of a website dependant on having JS enabled is obtrusive and bad practice.

    Note: By missing, I do not mean unavailable, I just mean that the header will scroll with the page alike any other element.

  17. #267
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Please keep the discussion on topic and refrain from making personal jibes or comments please.

    This is an interesting discussion so please keep it amicable.

  18. #268
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    Arlen, please try to refrain from making personal and deliberately offensive statements
    Interesting. Alex makes comments about a site he's never seen and about an audience he's never analyzed, I ask him not to make comments about things he's not familiar with, and I'm being offensive. Pot, meet kettle.

    (That, BTW, was the only personal statement about Alex I made in the whole post. Go ahead, go back and read it, I'll wait. The rest were global statements, including a few using the unreferenced pronoun "you" which I thought was obviously referencing the HTML5 attackers collectively and which I'll try to refrain from in the future since it can be taken out of context and aimed somewhere else, and which Alex pulled out of context and decided must be personal. They weren't, but if he chose to take them that way, I'm not sure what I can do about it. Meanwhile, of course his sneering sarcasm -- "How lovely..." -- is deemed immune from criticism. I didn't, and don't, make statements about how he creates websites, despite his accusation that I did. In fact I said everyone should feel perfectly free to develop them in XHTML if they wish.)

    Since it appears I need to make it obvious, that's the last of this that deals with Alex directly. (If a Sitepoint mod thinks that was out of line, please feel free to delete it; I won't complain. I just felt I needed to deal with the bogus personal attack issue before getting on with the main points. If you disagree, it's your board, do what you want.) Meanwhile, back at the subject...

    Let's not conflate unobtrusive javascript with graceful degradation or progressive enhancement. Unobtrusive javascript simply means keeping the javascript out of the main html file, which I do. The concern about what happens with js turned off is more properly classified as part of graceful degradation. Not really a problem for me, since I generally hold to those principles as well; the main point of difference it seems is where the line is drawn at the end of the degradation. Some have an absolute line that all sites must meet, regardless of audience characteristics, while I let audience analysis decide where the line should be drawn. It's a valid difference of opinion, but it doesn't reflect on the validity of HTML5 as a specification. I used the template I built as a counter example to the lack of browser support for HTML5. It can be done for much of the spec, with very little more effort than it takes to get more "mainstream" markup to work. I haven't tested it, but I hear there's even a script to get the canvas tag working in IE.

    Is there "a growing number" of people with javascript turned completely off? From what I've seen, there's a new number in the mix that turn off scripts from another site, but not scripts from the site they're visiting. If anything, it seems to me the number of people with js turned on for the site they're visiting is growing, not shrinking. W3schools seems to agree with this assessment, showing js off is at the lowest point it's ever been, but they warn, and I agree, that all such statistics are not reliable. The only ones that matter are the ones for the particular site's audience.

    Yes, in some browsers (not all, just some) turning js off completely will change the position of some on-screen boxes. Note it won't necessarily "wreck the design," it won't cause the boxes not to appear, or to appear on top of other content, just change their position. "Not render properly" is, of course, a matter of opinion, again. To one who defines "render properly" as "exactly the same in all browsers," the answer is yes, it prevents it from rendering properly; to one who is willing to allow differences between browsers, the answer is not necessarily. Again, either opinion is valid, and neither one supports an objective claim against the HTML5 spec.

    But I think it would break graceful degradation only if the resulting change makes the site unusable. "Graceful degradation" doesn't mean the site has to look the same, just that it has to work, and should give a good user experience (not the same, mind, just a good one). Note also that turning off js will completely eliminate one of the reasons a person would come to the site (much the way turning off flash would obviate the reasons for visiting a flash games site). This elimination, BTW, cannot be controlled for. You either have js and *can* access the game, or you don't and cannot. There's no way to deliver that part of the content w/o js. It *requires* interaction. (I can remember having to support a browser not that long ago which turned off css support when you turned off javascript. Wonder what *that* would do to claims like this?)

    The browser support claims I've heard against HTML5 can also be made against XHTML strict, yet I haven't heard anyone say that spec is bad. (For the record, I don't think it's bad. I just don't think it's going to be fixed before full HTML5 support shows up, and at the moment, I think HTML5 is the better spec.)

    @logic_earth, yes, you're right. I meant XHTML. Even IE8 won't support XHTML strict properly. That means another what, 5 years at least, before we can expect to have it? (BTW, I haven't had a chance to test IE8, yet, but from what I've read, it appears there may be as much or more support in it for HTML5 than for XHTML strict, so nothing seems to have changed on that front.)

    I wonder how many people that has prevented from using XHTML strict? If it doesn't, why should that claim prevent you from using HTML5?

    Here's a partial document structure:

    Code:
    <body>
    <header
    ...
    </header>
    <nav>
    ...
    </nav>
    <article>
     <header>
    ...
     </header>
     <section>
     ...
     </section>
     <section>
     <header>
     ...
     </header>
     ...
     </section>
     <aside>
    </aside>
    </article>
    <footer>
    ...
    </footer>
    And here's another document structure:

    Code:
    <body>
    <div id="branding"
    ...
    </div>
    <div id="navigation">
    ...
    </div>
    <div id="content">
     <div class="contenthead">
    ...
     </div>
     ...
     <div class="sectionhead">
     ...
     </div>
     ...
    <div class="sidebar">
    ...
    </div>
    </div>
    <div id="footer">
    ...
    </div>
    Now, just for a moment, set your old (x)HTML habits and prejudices aside and tell me, which one looks like more semantic markup, more like a page or document structure should look? Which one seems more efficient?

    (The first one also allows for different styling of individual sections of the main article, while the second one would need extra div's for that, but that happens so seldom I didn't use it here. I'll leave it as an exercise for the reader to add the divs if the ability is required.)

    Note please that the HTML5 spec specifically allows for h1 tags inside header tags (the header is a block tag, which can encompass images, bylines, etc., as well as the heading) so there's no necessary impact on search engines for using the tags, and you avoid taking sides in the fights over how many h1 tags you can have in a document. Of course, you can either use the header tags themselves to style the text inside, or if the header is more complex, use them as part of the context for the h1.

    (And again, I wonder: Since one of the major aims of the Google gears project is to implement some of the HTML5 spec across browsers, and they are already showing instances of HTML5-based maps on the Palm, and HTML5 Gmail, do they really ignore HTML5 in their uber-secret page analysis?)

    Yes, it adds new tags. Oh horrors! Some new words to learn! Yes it abandons SGML (I have several opinions about SGML, but that's not really relevant here). So what? Why is that worth the extent of near-rage I've seen over the draft spec?

    We all use draft specifications, every day, because some/most of the browsers we want to support will support them, and we find ways (the idea occurs to me now, I wonder if Resig's shiv could be converted into an .htc file like so many other IE fixes can be?) to make them work even in the more benighted browsers. So obviously that idea alone isn't evil.

    One of the driving motivations behind HTML5 is the support of web applications, which implies a higher level of interaction on the page, one more reason why requiring js isn't by necessity a burden.

    Have a look at HTML5, and start questioning why you've been doing things they way you've always done them before. It's a paradigm shift, I admit. But I think it's a good one.

  19. #269
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Arlen View Post
    The valid HTML5 doctype statement is:

    <!DOCTYPE html >

    (Ooooooh. scary simple!)
    And also equally valid for HTML2+ or any version of XHTML. It doesn't identify the version of (X)HTML being used at all.

    Also there is the problem that HTML 5 itself defines an identical tag and so you have no way to tell then whether that tag is the SGML identifier or is meant to be the one defined as a part of HTML5.

    I guess the only time you'd be sure it is HTML5 is if you had both the SGML qualifier AND the HTML5 doctype tags both present at the top of your document.

    <!DOCTYPE html ><!DOCTYPE html >

    Then you know that the page is XHTML5 since the SGML doctype is followed by a tag that only exists in HTML5.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  20. #270
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    And also equally valid for HTML2+ or any version of XHTML. It doesn't identify the version of (X)HTML being used at all.
    Valid XHTML doctypes require a DTD to be specified, so that's out as a confusion factor, because there is no DTD referenced. It could be interpreted as an invalid XHTML doctype, I guess, but only if you ignore the "HTML" that's present.

    As for HTML2+, it shares the same syntax parsing rules as the rest of HTML, so what's the real impact, there?

    Quote Originally Posted by felgall View Post
    Also there is the problem that HTML 5 itself defines an identical tag and so you have no way to tell then whether that tag is the SGML identifier or is meant to be the one defined as a part of HTML5.
    OK, if the problem is with the XHTML5 variant, then the mime type rules. If the page is served as "text/html" it's HTML5. If it's served as "application/xhtml+xml" or "application/xml" it's XHTML5.

    But I guess the better question in that case would be "what are you doing about IE" since IE can't handle those xhtml mime types.

    If you need a sure-fire method for the browser maker to use, then if it's xml mime types but "html" in the doctype, it's XHTML5. If you're looking for a way for a human to look at the file and know, I think the presence of one of the HTML5 tags would be a giveaway, don't you?

    Note: Even XHTML5 isn't true SGML and isn't claiming to be. XHTML5 claims to be well-formed xml, which does not mean SGML syntax.

  21. #271
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Arlen View Post
    Valid XHTML doctypes require a DTD to be specified
    No they don't - the only things needed to identify XHTML is a MIME type of application/xml+xhtml and an xmlns attribute on the HTML tag. The SGML doctype defines the page as XHTML in accordance with SGML standards but isn't actually required when using the page in a web browser.

    In all the web languages so far only (X)HTML5 has defined a <!doctype> tag as a part of its language. HTML2-4 and XHTML are all validly defined using SGML and it is the SGML doctype that appears before the start of the (X)HTML that defines which variant of SGML that the author claims that the page is written in. Web browsers could use the doctype to actually parse the document according to the defined doctype but none of the popular browsers currently do. Just because the browsers ignore the SGML doesn't mean that it isn't useful for other purposes though.

    If (X)HTML5 is SGML them an optional SGML doctype should be valid at the start of the file (before the <!doctype html> that HTML5 defines). If it is not SGML then the people writing HTML5 have thrown away decades of knowledge about how markup languages should be defined making it 99.999% certain that they will end up with something that doesn't work (unless they end up following all the SGML rules and just don't tell anyone that they are following them in which case it should be possible to create a valid SGML doctype or schema for HTML5).

    The HTML 4 standard was adopted in 1997 and only now are browsers actually approaching full support of that standard (the most obvious issues are with IE8 and the object tag where you can't remove the border around the object and you can't overlap anything in front of the object). Other areas of HTML4 that browsers don't fully support are at least as minor as that. It seems reasonably likely that the release of IE9 will mark the point at which all browsers finally fully support hTML4 (particularly if as has been indicated IE9 uses a different rendering engine).

    In any case creating new tags doesn't solve the problem of existing tags not working correctly in some browsers since the new tags will just be implemented using the same processing as existing tags and so all the new tags that are intended to replace certain uses of the object tag will be just as broken as the object tag itself is since the obvious way that browsers will implement those new tags is to use the same processing for them as for the object tag equivalent from HTML4 since the browsers will need to support both HTML4 and 5. Only where the browser supports the correct HTML4 way of processing something is it reasonable to expect that a browser that supports HTML5 will support that equivalent correctly.

    Assuming that HTML5 reaches recommendation stage some time in the next 5 years then judging by how long it has taken for browsers to support HTML4 it will be a further 15 years or so after that before browsers fully support HTML5.

    Of course the other way we could work things is if someone were to create a translator to convert from a given version of (X)HTML that people want to develop in to the HTML4 equivalent that current browsers can understand. This would allow the full use of (X)HTML5 or XHTML2 now for all of your page source. You would then either feed your static pages through the converter before uploading them or attach the converter into dynamic pages so that it converts them immediately prior to sending them to the browser. If appropriate converters were made available then it would not be necessary to wait for browsers to start supporting your preferred markup language before you start using it, you'd simply use the appropriate converter to have your preferred language converted into the HTML4 that the browsers do support.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  22. #272
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    To be honest, implementing HTML5 at the moment isn't a good idea and, whilst it's great for proof-of-concept scrapwork on your localhost, it's too early for putting it on a live site - wait for recommendation first.

    However, I think that decent browsers will catch up with HTML5 specs pretty soon after it's finalized. Back in the 90s specifications weren't so important and browsers were more focusing on how they can stand out; now, funnily enough, they are battling to be the one which does it correctly and (in the end) to be the same!
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  23. #273
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by arkinstall View Post
    However, I think that decent browsers will catch up with HTML5 specs pretty soon after it's finalized.
    Unfortunately the problem is never decent browsers, it is almost always a case of trying to degrade gracefully for the browsers like IE6 which are being used well after their expiration date runs out. And as long as IE6 users choose to browser websites I have created, I will continue to provide support for it, even if that means having to leave a new mark-up language by the side until support for it increases to a reasonable level.

  24. #274
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by arkinstall View Post
    However, I think that decent browsers will catch up with HTML5 specs pretty soon after it's finalized.
    IE6 is eight years old and still the third most popular browser out there.

    If new browsers adopt HTML5 immediately after it is finalised it will probably be at least 10 years before browsers that don't support it drop low enough to be able to ignore them - particularly in view of how long IE6 has survived for (and remembering that at one point it was the browser with the best HTML4/CSS support).
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  25. #275
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Arlen
    Is there "a growing number" of people with javascript turned completely off? From what I've seen, there's a new number in the mix that turn off scripts from another site, but not scripts from the site they're visiting.
    Likely the "growing number" either comes from increasing downloads of NoScript, which unfortunately is browser-specific, and the increase of mobile phone users who don't have the ones who support scripting (or turn scripts off because they want their batteries to last longer than a few minutes : )

    Quote Originally Posted by Arlen
    Note also that turning off js will completely eliminate one of the reasons a person would come to the site (much the way turning off flash would obviate the reasons for visiting a flash games site).
    This is true, though I'm sure you're still careful here too: my colleagues rib me about "how blind people can insure their motor vehicles now, ha ha". Another example was a wedding photographer's website-- the blind don't drive and they don't judge photographs, but that doesn't mean they don't want to find the photographer's prices, times and contact information, nor that a blind parent wouldn't want to be the one to set up insurance for their scooter-driving child, or that they wouldn't want to learn more about the motorcycle school their neighbor's been going to lately. So even on a media or games site, it's still a matter of the basic page itself supporting as many user agents as reasonable, even if the media or the main reason visitors come itself isn't. HTML5 is indeed a wholly different document, not just a new media or new pack of scripts slapped onto a text document. Again, I'm not saying you or other HTML5 writers don't, I just wanted to bring it up.

    Quote Originally Posted by Arlen
    One of the driving motivations behind HTML5 is the support of web applications, which implies a higher level of interaction on the page, one more reason why requiring js isn't by necessity a burden.
    I saw a talk by Anne about some of the newer stuff re HTML5 (couldn't stay to the end, it went waaay too late because someone thought it was a good idea to have the SEO talk first, lawlz, that dragged on) and one of the things I did not like the smell of was the client doing basically the work of either Javascript (canvas and loading were two examples) or of what normally should be the back end (I can't remember them anymore but likely the changes with input, forms and other user input interaction)... and a lot of it was Neat-O sounding.

    *edit I won't claim this is new, as HTML indeed does behaviours in browsers, <marquee> and the workings of hyperlinks being as old as the sky...

    My thoughts partially came from my whole bias against Javascript (yeah yeah, I know). Most user agents can support it, if not all uniform or well. But it's still not on-par with CSS (as far as support) and has the ability to affect performance more than CSS does. Taking some load off the server and moving it to the client can in some instances be the better, faster deal, but first we'd want to have a very popular set of user agents who easily and correctly deal with this (if every user agent worked and worked well with Javascript there would never be any discussions of graceful degredation or designing w and w/o js at all, because js support would be as little consideration as HTML support).
    Second thought was security, which yes, can always be worked on and worked out. Taking some of the functions away from the server (putting more load and trust in the client) means new ways to infiltrate information (so surely there will be the usual army of nerds who will build in extra security into the browsers).

    I'm more comfortable with the idea of the clients having things spoonfed to them like a TV, and being the conduit between the user and the server, a sort of dummy terminal, but I don't suppose that's the future. The future seems to be web pages as text documents vanishing into the past and teh Interwebz becoming all applications and media. I'm likely to be one of the ones left behind-- I'm not a programmer and I'm not a media person. Damn! I'm too young to be old fashioned already!! But I'm still stuck in the mindset of "text document", text manipulation, text-based. My end is coming, though at least I can see it.

    So, we just need those physicists to concentrate their efforts on better battery power storage and management so mobiles can deal with these extra loads they as clients are being asked to do.


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
  •