SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 36

Hybrid View

  1. #1
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)

    Moved over to HTML5

    I completely missed the earlier thread, I read 90% of it until my head hurt. I think it should be ok to start a related thread if we can keep it on track. There were valid points raised by each person who contributed to the last one.

    Nearly all HTML5 threads end up debating the usefulness of the semantic tags(section, article, header, footer, nav etc..). I find that almost pointless.

    Those tags are the least of HTML5 in my opinion and their use is hard to defend.
    Requiring js to style those tags in IE is a big deal, wrapping nav around a list that would suffice is a waste.
    But, if you'd like to use them I won't lose any sleep, I more put it down to personal coding preference.
    I've seen uses where those tags can make code look more readable, though I still don't see strong reasons to use them personally.

    Other tags, like samanime pointed out are quite useful like <time>, these provide valuable semantics to a page that HTML4 didn't. Again, reading code with these tags makes them more readable. The variety of tags isn't a problem in itself. It was aimed to pave the cow paths and implement semantics for things that people were coding over and again with meaningless tags like div/span.

    People who call these garbage don't understand why they were added.

    --
    Enough about the semantics already. HTML5 was designed for web applications. Let's talk about that instead.
    --

    The really interesting parts of HTML5 that set it apart are Forms, Rich Media(Audio, Video), 2D/3D Graphics(Canvas, WebGL, SVG - though not technically part of HTML5), Offline, and the other Javascript API's(localstorage, db, geolocation).. among others.

    • HTML5 Forms should be used - one strong reason is that using the new types enables mobile browsers to switch keyboards for the types. - There's heaps of great additions to HTML forms, validation, placeholders, speech input.
    • Rich Media is painful and inconsistent - but adding these to the specs is the right move, don't hate progress.
    • Offline should be used - when relevant to an application.


    The Javascript API's are the most of HTML5.

    • Geolocation Flipping Awesome! should be used - when relevant to an application.
    • WebSockets - Flipping Awesome! should be used - when relevant to an application.
    • Web storage - More processing is moving client-side, you're not going to stop it. This enables another level of interactivity and responsiveness to applications.
    • History API - make applications more responsive with partial page updates and keep your history.
    • 2D/3D Graphics are flipping awesome! Seriously, these are game changers for the web as a platform. Being able to build interactive animated graphics with SVG or Javascript pushes the boundary of what can be achieved - and is much of the reason that Flash is being replaced.


    Oh yeah, and everyone is on the same page with the doctype, use it.

    I'm bored engaging in arguments about those 5 debatable semantic tags, the point that HTML5 is to support Web Applications and richer experiences on the web.
    Not all web developers need to use these features, so HTML4 is fine. But if you're building a rich, interactive web application you'll want to look at some of these features.

    --
    When people ask if I use HTML5 or not I normally say "I just use HTML, HTML5 isn't an entirely new version, it's just a collection of new features, I use the parts that make sense."
    I've had people say "Oh, if you can use HTML5 that would be awesome", I understand the misunderstanding of what HTML5 is, just nod and say sure.
    It's strange that the general public should know about an HTML specification, or care

  2. #2
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    I should probably ask some questions to generate some discussion.. "Is HTML5 ready for prime time?" is the wrong question to ask because it's just a collection of features, some are well supported, other aren't at all, many require javascript polyfill's for consistent implementation. I just keep hearing people on the forum say don't bother with HTML5 & CSS3 and I don't think that's good advice at all.

    Which HTML5 features do you use?

    If none, then when?

    With browsers that push new releases frequently like Chrome and Firefox - do you only support & test the latest versions?

  3. #3
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by markbrown4
    Which HTML5 features do you use?
    I don't use the APIs, but that's mostly because I haven't built anything that would use them. I'd be okay with stuff like LocalStorage, History, video/audio with Flash fallback, because these things degrade well and mostly when Javascript tests for support for these things, it's usually correct (there are some things the browser will report back "Yup! I support this!" when it doesn't, arg). GeoLoc isn't HTML5 but similar, I have yet reason to use it.

    I use:
    • Shorter doctype: I can always tell the validator to pretend it's XHTML for finding stupid errors like unquoted attributes or unclosed li's/p's etc.
    • Shorter other things: since browsers' error rendering needed to be able to read charset="somecharset" because so many developers misplaced the quotes, <meta charset="utf-8"> works, so why not? I drop types of link elements linking to CSS files and I'll drop the type for Javascript except when I'm debugging (Firebug etc complain when there's no type).
    • ARIA isn't HTML5 but I use it, on HTML4, XHTML1, whatever. It's all good.
    • I've used <time> and <mark>, since both degrade to either inline elements of no value (most browsers) or to nothing at all in IE (totally acceptable, in my view). If they're seen, great. If not, *shrug*
    • Most of the new form input types. Color type is useless and horribly does not fall back well: the expected typed-in data is a hex value. Right, soccer mom's gonna know a hex value. And it's apparently not meant for e-commerce, which was the first thought I had for it: choosing the colour. But doesn't work that way, seems to be made for online PhotoShop or something really specific and weird. Whatever.
      Also CSSing and Javascripting the new input types makes things more code for parsers, yay: isntead of input[text] or input.type=text, you're now adding a bunch of things. So now it's either a class or a regex, and it wouldn't surprise me if this didn't slow a parser down somewhere.
    • I don't use the form validation much because the default error messages are horrid and don't help users. Overriding with Javascript sounds like extra work that could be avoided by just not having validation in the HTML and just have server-generated error messages on submit and possible Javascript validation on the front to catch people before they submit. Opera's "hey use a title for the error message and it'll get added to the error box" is super retarded, and hurts users who see title tooltips and screen reader users who generally hear titles on inputs. Plus the language issue.
    • I don't use stuff that should degrade well but don't, like <details>. Chrome's lack of keyboard support is bleh. Not sure what those guys were thinking. You can Javascript the heck out of it, but since it's supposed to be replacing "common" Javascript, might as well stick to good old Javascript and HTML4 in those cases.
    • I'm very careful with placeholder attributes, and generally don't use them. User testing shows people see things filled in and on a long form where users may be skimming, the input may seem "filled" and people love to assume a filled-in default is all they need, so oops. Autocomplete is unfortunately on by default. I find this a violation of user privacy and security and it seems one cannot set this OFF on the form?? but has to set it on every single input who might have the attribute?? Arg, what a horrid design choice. I hope they reconsider, if this is still the case... it's been a few months since I looked at it last. The developer should be adding it in, not having it in by default. Unfortunately many developers might not realise their forms are treated as HTML5 by browsers with the HTML5 parser no matter what the dev thinks s/he's writing. HTML5 guys say browsers should offer the user the ability to turn these things off, but so far, that's not been built.
    • No canvas: still needs accessibility work, but it's encouraging to see that some stuff's gotten done and it looks like making it accessible will be possible. But also, haven't had a need for it either. I'm not making games or interactive charts and graphs (but if I were, I'd prolly use raphael.js or flotr with a normal DOM instead).


    That "using the shiny new stuff makes your site future-proof" is a poor argument for most sites. The old stuff is not getting dropped, not for a decade or more. Chances are, your site is not going to last more than a few years, let alone a decade, without either vanishing or getting rewritten anyway.

    Quote Originally Posted by markbrown
    If none, then when?
    Each new thing: when it's stable, then when it's got enough support AND falls back well, doesn't increase more Javascript coding on the front end to "fix" new defaults, and is applicable to the site and actually improves the user's experience rather than just being the new shiny thing.

    I'm not a fan of polyfills in general. I'd rather a functioning site that looks a bit fuglier for older browsers than that older browsers have to download a bunch of extra stuff and run extra scripts for a performance-slowing poor imitation of native new things. But I suppose that depends on the client, the visitors, and what's going on.

    Quote Originally Posted by markbrown
    With browsers that push new releases frequently like Chrome and Firefox - do you only support & test the latest versions?
    Only if I have them. Like most users, I have periodic updates, and being on Debian using the Ubuntu release cycle (6 mos) I'm usually behind Windows users who update when the browsers do. This means I'm likely to be one of the last groups to update anyway, so if a bug was fixed I feel I'll probably have most users with teh bug-fix version, meaning maybe I can use something now. Same goes for CSS3 and ARIA stuff.
    IE needs stats from the users the site is serving. If there's IE6 or 7, even 8... I'll consider using less new stuff because I'll be spending the time building extra images or elements or whatever anyway. It's not like this stuff is going to stop working in the future so future-proof is not an issue.

    I don't even own a machine who has the drivers and capability of even doing WebGL. I'm thinking only people who've bought new machines anyway, or are web developers, have this. Most of the people I know who are not "computer people" have older desktops. If these are my users, I wouldn't think of using it then anyway. Nobody is going to go buy a new computer so they can see your WebGL. Unless you're giving them out for free :)

  4. #4
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    That seems like a pretty solid approach to me, I pretty much agree with everything you wrote, just a couple of points to clarify.

    GeoLoc isn't HTML5 but similar, I have yet reason to use it.
    Geolocation is part of HTML5.

    I've used <time> and <mark>, since both degrade to either inline elements of no value (most browsers) or to nothing at all in IE (totally acceptable, in my view). If they're seen, great. If not, *shrug*
    The elements are still available in IE, the only issue is that you can't style any of new semantic elements in anything less than ie9 without the js shim.

    Also CSSing and Javascripting the new input types makes things more code for parsers
    I might not have understood you correctly, but we don't need to worry about the browser coping to parse more tags & attributes.

    No canvas: still needs accessibility work
    Hmm, I don't know how important this really is - you can always provide hidden alt content that isn't visible on screen. But most of the uses of canvas I've seen don't really make sense translating to text, I wouldn't expect much being done about it other than a method for providing alt content.

    I'm not a fan of polyfills in general. I'd rather a functioning site that looks a bit fuglier for older browsers than that older browsers have to download a bunch of extra stuff and run extra scripts for a performance-slowing poor imitation of native new things. But I suppose that depends on the client, the visitors, and what's going on.
    You're right that it depends on the feature - if it's just visual reward we're talking about then I too don't always fill in the gaps with css/js for older browsers.
    But for many of the js api's a js polyfil makes sense and is necessary - e.g. json2, excanvas, svgweb, localstorage etc.
    The biggest reason to use them is to make the code much easier to write in a standard way. As time goes on I'm more willing to trade performance in older browsers with my own development performance - At some point we expect old browsers to behave badly with new code, or we just stop supporting them at all.
    I don't even own a machine who has the drivers and capability of even doing WebGL.
    Really? I haven't used WebGL myself yet but I hadn't actually thought about it requiring capable graphics cards to work. This is a very good point, I'll need to look into it.

  5. #5
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by markbrown
    Geolocation is part of HTML5.
    http://isgeolocationpartofhtml5.com/

    Like ARIA, it started as part of the HTML5 specs way back when. But it has been removed. This may not matter, especially when we've got people throwing regular JS and CSS3 in with "HTML5", but I'm being technical.

    Quote Originally Posted by markbrown
    The elements are still available in IE, the only issue is that you can't style any of new semantic elements in anything less than ie9 without the js shim.
    Only if I'm already using the shim. No reason to add this for elements who don't make a difference in browsers who can't read them anyway. With other elements like <header> and <footer> it matters more since they are meant to be block containers and for JS and styling reason they'll be used for DOM navigation, but <time> and <mark> don't and yeah, that's one of the reasons I'm more willing to use them: they degrade better.

    Quote Originally Posted by markbrown
    I might not have understood you correctly, but we don't need to worry about the browser coping to parse more tags & attributes.
    I mean in the way that there is now simply *more* code, period, in the instances where before you would have only either "input" or input[type=text] to style most of your inputs, and input.type=text for Javascript, now when there are more types, if you are doing code by types, you now have more code.
    I've been regexing them in my Javascript. It's not a big deal, but that didn't happen with HTML4 forms.

    Quote Originally Posted by markbrown
    You're right that it depends on the feature - if it's just visual reward we're talking about then I too don't always fill in the gaps with css/js for older browsers.
    But for many of the js api's a js polyfil makes sense and is necessary - e.g. json2, excanvas, svgweb, localstorage etc.
    Yes I meant mostly the visual stuff. Having Javascript imitate something that's using Javascript anyway when it is supported, isn't a big deal. You've already made some amount of commitment once you've decided you're going to use those APIs.

    Quote Originally Posted by markbrown
    Hmm, I don't know how important this really is - you can always provide hidden alt content that isn't visible on screen. But most of the uses of canvas I've seen don't really make sense translating to text, I wouldn't expect much being done about it other than a method for providing alt content.
    Canvas is being used to create forms and GUIs. Yes, the creators have said (mostly to themselves) that this is a mis-use of canvas. Too late, you don't create addictive things and then blame people for using them all the time.
    Anyway, with canvas there is no "alt". The only thing canvas has offered is a default content for browsers who don't know what <canvas> is, nothing more. It otherwise does not have a fallback... which makes the way <video> and <audio> tags work even more of a plus, when you realise you can nest <object>s and then more alter-children inside those... always something for the user, which is great. Canvas, no.

    The problems with canvas are: there is no DOM, so no way to programmatically know what elements are, objects are, states are, and where things sit.
    Things are then naturally unkeyboardable, cannot show keyboard focus, and cannot return states or settings or parents or children to the Accessibility Layers of the browsers running them. Screen magnification does not work, since things are built in pixels and there are no "objects" who have relationships with each other. Canvas is used mostly for interactive presentations: users do things, so plain text is not a suitable alternative. (I think this was what you meant? There are many other things that are accessible who also don't translate well to plain text, of course).

    Now they are working on this, and I think it was at CSUN there were some updates on some things working. http://wiki.whatwg.org/wiki/Canvas shows some of the things going on so far. Here's a bit of discussion also: http://lists.w3.org/Archives/Public/...2Mar/0230.html and some more, specifically hit testing: http://www.w3.org/wiki/Canvas_hit_testing
    Doug Schepers also had a proposal to merge the API of canvas and SVG somewhat as well... http://schepers.cc/retain-a11y-immediately#more-488

    Quote Originally Posted by markbrown
    Really? I haven't used WebGL myself yet but I hadn't actually thought about it requiring capable graphics cards to work. This is a very good point, I'll need to look into it.
    I think it was also a driver issue. That is, I went to the Chrome WebGL demo, the one with the fish tank and the sharks shooting lasers out of their eyes... I had a new-enough Chrome, but got a message that I didn't have a good enough driver. Could also be the video card. Changing that is pretty simple in a desktop... my machines are laptops.

    Find a machine you think is kinda old and find that Chrome demo and see what message it gives you.

    Somewhat off-topic, but there they go again: dev.w3.org/html5/status/issue-status.html#ISSUE-164 (hgroup... fight fight fight)

  6. #6
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    http://isgeolocationpartofhtml5.com/

    Like ARIA, it started as part of the HTML5 specs way back when.
    Neither ARIA nor geolocation was ever part of the HTML spec. (HTML5 now has a section on ARIA which augments the ARIA spec, though.)
    Simon Pieters

  7. #7
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Color type is useless and horribly does not fall back well: the expected typed-in data is a hex value. Right, soccer mom's gonna know a hex value.
    The user isn't supposed to type anything. The user is supposed to choose a color from a well (or whatever UI the browser thinks is best).

    Quote Originally Posted by Stomme poes View Post
    And it's apparently not meant for e-commerce, which was the first thought I had for it: choosing the colour. But doesn't work that way, seems to be made for online PhotoShop or something really specific and weird. Whatever.
    What do you want to use it for, specifically?

    Quote Originally Posted by Stomme poes View Post
    Also CSSing and Javascripting the new input types makes things more code for parsers, yay: isntead of input[text] or input.type=text, you're now adding a bunch of things. So now it's either a class or a regex, and it wouldn't surprise me if this didn't slow a parser down somewhere.
    I don't know what you're talking about here.

    Quote Originally Posted by Stomme poes View Post
    I don't use the form validation much because the default error messages are horrid and don't help users. Overriding with Javascript sounds like extra work that could be avoided by just not having validation in the HTML and just have server-generated error messages on submit and possible Javascript validation on the front to catch people before they submit. Opera's "hey use a title for the error message and it'll get added to the error box" is super retarded, and hurts users who see title tooltips and screen reader users who generally hear titles on inputs. Plus the language issue.
    Firefox has an attribute to override the error message. If that's what you want, you should push to get it added to the spec. Other than that, I don't see how setCustomValidity is harder than custom javascript validation which you say you would use instead...?
    Simon Pieters

  8. #8
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Like ARIA, it started as part of the HTML5 specs way back when. But it has been removed.
    Oh right, I guess they are removing the JS API's because it confused people.

    Only if I'm already using the shim. No reason to add this for elements who don't make a difference in browsers who can't read them anyway.
    No, that's not right. The text content is still visible - it's only that you can't style them in ie9<
    Code html5:
    <!DOCTYPE html>
    <html lang="en">
    <head>
    <meta charset="utf-8">
    <title>untitled</title>
    <style>
      time { color: #999 }	
    </style>
    </head>
    <body>
    <p>It was posted <time datetime="2011-11-12T14:54">a while ago</time></p>
    </body>
    </html>

    The problems with canvas are: there is no DOM, so no way to programmatically know what elements are, objects are, states are, and where things sit.
    That's not a problem, it's a design choice, but I do share the peeves and SVG does seem like a more natural fit with the other web standards.

    Canvas is being used to create forms and GUIs. Yes, the creators have said (mostly to themselves) that this is a mis-use of canvas. Too late, you don't create addictive things and then blame people for using them all the time.

    Anyway, with canvas there is no "alt". The only thing canvas has offered is a default content for browsers who don't know what <canvas> is, nothing more. It otherwise does not have a fallback... which makes the way <video> and <audio> tags work even more of a plus, when you realise you can nest <object>s and then more alter-children inside those... always something for the user, which is great. Canvas, no.

    Things are then naturally unkeyboardable, cannot show keyboard focus, and cannot return states or settings or parents or children to the Accessibility Layers of the browsers running them. Screen magnification does not work, since things are built in pixels and there are no "objects" who have relationships with each other. Canvas is used mostly for interactive presentations: users do things, so plain text is not a suitable alternative. (I think this was what you meant? There are many other things that are accessible who also don't translate well to plain text, of course).
    I think <canvas> is a lot like <img>, I don't think of it as an interactive document like you are describing.
    It's an <img> that you can draw pixels on, this is why I'm saying a static text description like alt="" may be the simplest accessibility option.
    SVG is in a similar boat - even though there's DOM there's not much point reading to a user that there's a bunch of shapes and lines

    Until they add support you can always do something like this:
    Code html5:
    <!DOCTYPE html>
    <html lang="en">
    <head>
    <meta charset="utf-8">
    <title>untitled</title>
    <style>
    .canvas-alt {
      border: 0;
      clip: rect(0 0 0 0);
      height: 1px;
      margin: -1px;
      overflow: hidden;
      padding: 0;
      position: absolute;
      width: 1px;
    }
    </style>
    </head>
    <body>
    <canvas></canvas>
    <p class="canvas-alt">Alt content</p>
    </body>
    </html>

  9. #9
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by markbrown4 View Post
    Oh right, I guess they are removing the JS API's because it confused people.
    Nope.
    Simon Pieters

  10. #10
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by zcorpan
    The user isn't supposed to type anything. The user is supposed to choose a color from a well (or whatever UI the browser thinks is best).
    Back when I was testing the new form inputs for some HTML5 slides I was making, Opera was the only browser who popped up a colour wheel (and it didn't work with keyboard, and it made the page jump/showed the colour selector at the top of the page on Linux but not Windows), but other browsers who had validation would insist the colour type input was "wrong" if you didn't type in a hex number. Bleh.

    Quote Originally Posted by zcorpan
    What do you want to use it for, specifically?
    There's only one form type I've ever used where I am selecting a colour. It's e-commerce. Items are generally offered in a range of things: sizes, types, colours. When I first saw there was a input type="color" I thought, oh okay, some way to add semantics or something to form inputs asking for colour, maybe to get around the issue where the same colour (say, "tan") gets a bazillion other retarded names, especially with textiles (sand, various types of rocks, types of animals, types of dried grass... they do get creative with their names for a colour like "tan"). I dunno. But the input clearly isn't made for that: the input allows users to visually select a colour from infinity, not from some limited, chosen set that a manufacturer has set.

    So since you can choose theoretically *any* colour, the only thing I could think of was something like, an online Photoshop app thingie. Except, I would expect if someone made such a thing, they would build in that tool the way they would need to build in all the other tools.

    So as an input it's pretty confusing and after I made my slides, I forgot about it and never used it again. Some new things seem to have broad application. Other new things... no idea.

    Quote Originally Posted by zcorpan
    Neither ARIA nor geolocation was ever part of the HTML spec. (HTML5 now has a section on ARIA which augments the ARIA spec, though.)
    I took the idea that geoloc was once part of HTML5 spec from comments by standardista type peoples (they could be wrong but I have no way of knowing this) and when I had a copy of Bruce and Remy's book (loaned it from a friend so don't have it any more; out of date anyway now, thinking of getting the new one) they have a section on "It's not HTML5 anymore but we're covering GeoLoc because it's new and cool and why not" and I thought it explained that the spec had been separated. But since I don't have the book right in front of me now, I have a doubt.

    And yeah, I've seen your spec proposal, but I didn't think that was intorucing ARIA to HTML5... instead, as I was reading the history of HTML5, it seemed this happened:
    -HTML was to stay dead, and XForms came out.
    -Examples of XForms I saw from 2005 had these neat-o aaa:required and "wairole" attributes in them... the beginnings of ARIA
    -When Mozilla, Opera and later Apple decided to continue working on HTML (not XHTML) forms, so before they went all out and said "let's make HTML work with apps", they incorporated the roles and attributes into the "new" forms.
    -That finished, they thought "why stop here? W3C isn't interested so let's just do our thing, now for web apps, see where we end up" and HTML went further.
    -Whenever this started becoming "HTML5", ARIA was baked-in (though at a still-early, unfinished state as even now some things are still being created and edited), while "HTML" did not have it (though if FF back then supported it, you could just add it and suck up the validator b*tchings).

    Correct me if I got something there wrong, because I wanted to give that history overview in the future sometime.

    So when I was on the (w3c) HTML5 editor's draft page that had the ARIA stuff and there was later a link to a separate section (regular WAI-ARIA stuff) it seemed like all HTML5 references to ARIA were now only the W3C WAI-ARIA page.


    Quote Originally Posted by zcorpan
    I don't know what you're talking about here. (input types)
    I've gone from CSS like
    input[type=text] {
    styles for everyone who's not a submit, radio or check, or basically, all the "type-in boxes" excepting password;
    }
    Or more usually, I'd do
    input {
    styles;
    }
    and just over-do with input[type=submit] or whatever.

    to now, if I'm going to use type selection,
    input[type=text], input[type=email], input[type=url], input[type=tel]... {
    select all the "type-in boxes", plus I'll add more for hover/focus etc...
    }
    (or other way, but listing other new types that aren't boxes)

    meaning either abandon using type for style selectors (which I ended up doing... adding classes kinda sucks and I thought "Here would be a great place for a regex! input[type=text|email|url|tel|number... etc]" but sadpanda) or just use them all. For Javascript, it's a regex. I set a pattern with all the types I'm going to hit and then do a .match on them.

    I figure if I do the list-every-type-of-input-comma-separated, not only could that be a lot of typing (not in my editor but anyways) but would probably be slowing down the parser (unless it goes left-to-right here? first finds inputs and then checks their types? That would be jawsome) more than when I hit all those inputs with a single type.

    Quote Originally Posted by zcorpan
    Firefox has an attribute to override the error message. If that's what you want, you should push to get it added to the spec.
    oooh! That would be nice! Also if autocomplete defaults off too. And autofocus! Is there a proposal for that?


    Quote Originally Posted by zcorpan
    Other than that, I don't see how setCustomValidity is harder than custom javascript validation which you say you would use instead...?
    Duh!! I completely forgot about those (and I think they were in Bruce and Remy's book)! We were manually using Javascript to push the errors offscreen or place abso-po'd messages on top of them to cover up, to add Dutch ones and something useful for "pattern" in. Doh.

  11. #11
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Back when I was testing the new form inputs for some HTML5 slides I was making, Opera was the only browser who popped up a colour wheel (and it didn't work with keyboard, and it made the page jump/showed the colour selector at the top of the page on Linux but not Windows), but other browsers who had validation would insist the colour type input was "wrong" if you didn't type in a hex number. Bleh.
    We have an open bug about fixing keyboard access with the color picker. Is the jump thing still reproducible?

    That other browsers hadn't implemented the color picker yet doesn't seem to be a problem with the spec.

    Quote Originally Posted by Stomme poes View Post
    There's only one form type I've ever used where I am selecting a colour. It's e-commerce. Items are generally offered in a range of things: sizes, types, colours. When I first saw there was a input type="color" I thought, oh okay, some way to add semantics or something to form inputs asking for colour, maybe to get around the issue where the same colour (say, "tan") gets a bazillion other retarded names, especially with textiles (sand, various types of rocks, types of animals, types of dried grass... they do get creative with their names for a colour like "tan"). I dunno. But the input clearly isn't made for that: the input allows users to visually select a colour from infinity, not from some limited, chosen set that a manufacturer has set.
    You can actually suggest a list of colors with <datalist>, but you can't restrict which colors the user can pick, short of making the control invalid if the user picks a color you didn't suggest. If you could elaborate a bit on the e-commerse use case (something concrete like "user wants to buy a T-shirt that is available in three colors" or whatever) I could maybe file a spec bug asking for supporting a <select>-like color picker.

    Quote Originally Posted by Stomme poes View Post
    So since you can choose theoretically *any* colour, the only thing I could think of was something like, an online Photoshop app thingie. Except, I would expect if someone made such a thing, they would build in that tool the way they would need to build in all the other tools.
    I don't recall exactly what use cases led to the addition of type=color, but I don't think it was restricted to painting apps.

    Quote Originally Posted by Stomme poes View Post
    I took the idea that geoloc was once part of HTML5 spec from comments by standardista type peoples (they could be wrong but I have no way of knowing this) and when I had a copy of Bruce and Remy's book (loaned it from a friend so don't have it any more; out of date anyway now, thinking of getting the new one) they have a section on "It's not HTML5 anymore but we're covering GeoLoc because it's new and cool and why not" and I thought it explained that the spec had been separated. But since I don't have the book right in front of me now, I have a doubt.
    Robert is wrong. I haven't read Bruce and Remy's book, though I'd expect Bruce to know the history.

    Quote Originally Posted by Stomme poes View Post
    And yeah, I've seen your spec proposal, but I didn't think that was intorucing ARIA to HTML5... instead, as I was reading the history of HTML5, it seemed this happened:
    -HTML was to stay dead, and XForms came out.
    -Examples of XForms I saw from 2005 had these neat-o aaa:required and "wairole" attributes in them... the beginnings of ARIA
    -When Mozilla, Opera and later Apple decided to continue working on HTML (not XHTML) forms, so before they went all out and said "let's make HTML work with apps", they incorporated the roles and attributes into the "new" forms.
    -That finished, they thought "why stop here? W3C isn't interested so let's just do our thing, now for web apps, see where we end up" and HTML went further.
    -Whenever this started becoming "HTML5", ARIA was baked-in (though at a still-early, unfinished state as even now some things are still being created and edited), while "HTML" did not have it (though if FF back then supported it, you could just add it and suck up the validator b*tchings).

    Correct me if I got something there wrong, because I wanted to give that history overview in the future sometime.
    I think ARIA was unrelated to XForms and WF2. ARIA did at first indeed have namespaced attributes (because that was believed to be the "right way" at the time), and was implemented as such in Firefox. But the ARIA people wanted it to work in text/html as well, so we worked together to move away from namespaced attributes to no-namespace attributes which would work the same in text/html and XML, and that's what we have today.

    The section on ARIA in the HTML spec was added much later, and is there to put restrictions on how authors are allowed to use ARIA in HTML, and to give default roles of HTML elements (so that e.g. <button> has role=button implied). The ARIA spec allows host languages to do this.

    Quote Originally Posted by Stomme poes View Post
    I've gone from CSS like
    input[type=text] {
    styles for everyone who's not a submit, radio or check, or basically, all the "type-in boxes" excepting password;
    }
    Or more usually, I'd do
    input {
    styles;
    }
    and just over-do with input[type=submit] or whatever.

    to now, if I'm going to use type selection,
    input[type=text], input[type=email], input[type=url], input[type=tel]... {
    select all the "type-in boxes", plus I'll add more for hover/focus etc...
    }
    (or other way, but listing other new types that aren't boxes)

    meaning either abandon using type for style selectors (which I ended up doing... adding classes kinda sucks and I thought "Here would be a great place for a regex! input[type=text|email|url|tel|number... etc]" but sadpanda) or just use them all. For Javascript, it's a regex. I set a pattern with all the types I'm going to hit and then do a .match on them.

    I figure if I do the list-every-type-of-input-comma-separated, not only could that be a lot of typing (not in my editor but anyways) but would probably be slowing down the parser (unless it goes left-to-right here? first finds inputs and then checks their types? That would be jawsome) more than when I hit all those inputs with a single type.
    Ah, OK. I see what you mean. It's more typing, but you don't need to worry about performance here, I'm pretty sure.

    In most cases you could use input:read-write { ... }. It matches text, url, email, password, the date/time controls, and number, if it isn't readonly or disabled. Do you want to select readonly/disabled fields as well?
    http://www.whatwg.org/specs/web-apps...tor-read-write

    Quote Originally Posted by Stomme poes View Post
    oooh! That would be nice! Also if autocomplete defaults off too. And autofocus! Is there a proposal for that?
    For autocomplete, see http://www.schemehostport.com/2011/1...ituencies.html

    For autofocus, the spec allows browsers to turn it off. If you want browsers to implement that, file bugs.

    Quote Originally Posted by Stomme poes View Post
    Duh!! I completely forgot about those (and I think they were in Bruce and Remy's book)! We were manually using Javascript to push the errors offscreen or place abso-po'd messages on top of them to cover up, to add Dutch ones and something useful for "pattern" in. Doh.
    Simon Pieters

  12. #12
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by zcorpan
    We have an open bug about fixing keyboard access with the color picker. Is the jump thing still reproducible?
    I had alerted Bruce to both the keyboard thing and the jumping thing. My current Opera was jumping but it's been bugging me for months now to update so I did before testing again. It seems fixed though I'm going to try on the other machine where it jumped first, but last test was on 11.62.

    Quote Originally Posted by zcorpan
    If you could elaborate a bit on the e-commerse use case (something concrete like "user wants to buy a T-shirt that is available in three colors" or whatever) I could maybe file a spec bug asking for supporting a <select>-like color picker.
    Thinking about it, the current technique of coloured checkboxes seems better. So long as they are actually checkboxes. It's just that e-commerce was my first thought. I otherwise have no idea why we'd have a special input type for selecting any colour in existence since it seems a very narrow use case.

    Also surprised that the CSS colour names (which are all mapped to specific #hex numbers) aren't counted. Say if someone types in "red", that #ff0000 would be filled in. And while I like #hex better than other types, I've heard people ask why no rgb or hsl or whatever instead. I assume it just made sense from a spec-writing point of view to pick something now and wait for people to suggest others after there's something working.

    I assume whoever introduced it to the spec knew of a good one. I'd like to hear it.

    Hm, thinking, I came up with another one: sites like Twitter where users can personalise their own pages, you have the option of selecting a background colour. I think that one would pop up a colour wheel, probably with Javascript since it worked on many browsers. Maybe that was what the submitter was thinking?

    Quote Originally Posted by zcorpan
    That other browsers hadn't implemented the color picker yet doesn't seem to be a problem with the spec.
    More that a browser not implementing a spec should *never* interfere with a user being able to use [the input]. See, browsers who don't support input type=email have no issues, and therefore were much safer in my book. It degraded better.

    Quote Originally Posted by zcorpan
    In most cases you could use input:read-write { ... }. It matches text, url, email, password, the date/time controls, and number, if it isn't readonly or disabled.
    Hm, :read-write sounds like what I want, the question is does that support come and go with browser support for various input types?

    I may use this for something I build where IE7 and 8 are not an issue. That was actually another issue I ran into: while IE7+ supports input[type=text], if you use a new type that IE doesn't support, while the "default" is "text", that doesn't seem to "count" for CSS or Javascript. Must only be browser behaviour. I ran in to the same thing when I had inputs who didn't list any type at all (again, since "text" was to be the default). The defaults weren't selectable criteria.
    So that was another reason for either dropping styling in older browsers + IE, or using classes, and regexing in Javascript. I'll have to see now if these "states" have a JS equivalent.

    Quote Originally Posted by zcorpan
    It's more typing, but you don't need to worry about performance here, I'm pretty sure.
    That's good to hear. Kangax has been doing some tests on selectors and things anyway, we're waiting for another blog post :)

    Quote Originally Posted by zcorpan
    Do you want to select readonly/disabled fields as well?
    For usability reasons I generally do *not* give those the same styling. It should be visually obvious that the input is different in some way. But if I did I assume I'd just comma-separate-add the :read-only one as well?

    Quote Originally Posted by zcorpan
    For autofocus, the spec allows browsers to turn it off. If you want browsers to implement that, file bugs.
    Will do. Ever try to use a page new to you while you're using a screen magnifier or a screen reader? Totally lost. Yet once a user is used to a page (like a search engine, or LinkedIn) they may want the autofocus... should be browser-side settings like font-size.

  13. #13
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    For things like forms I would think SVG (if images are necessary) would be the natural choice but it seems they are not, in the wild.
    I don't understand, for things like forms I'd expect <form>'s
    The examples I see of canvas are never static. Discounting even the games, users are meant to interact with it. Drawing on something, dragging something, selecting something... otherwise, you would just use... an img. You're not loading all that JS for a static picture.
    http://archive.dojotoolkit.org/night...s/circles.html
    I didn't say they were static, I said <canvas> was just a <img> that you can draw on with javascript.
    <-- a canvas example used in chart/graph software. It's not just showing data, but the point is also that users can manipulate data. This is how canvas is being used in the wild.
    I disagree, the point of the whole page might be that users can manipulate data, that's not the point of the <canvas> - it's purely for rendering flat images. You seem to think that's a design flaw, I think it was always it's intention.
    A simple example of what I'm referring to is entering data in a form in one part of the page, and a chart getting updated in a different part of the page.

  14. #14
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    There are a few kinds of HTML5. header, footer, section, nav are one type. canvas is another type.

    Even though I strongly disagree with your intro (see nav), I mildly disagree with you on canvas.

    canvas is one of those elements that can actually produce a full scale progressive enhancement. That is, it can replace the whole content, it can put it in a better visual shape, and serve it with the full interaction package content had in the first place, +1.

    All that if you can handle the complexity for the task. Which is huge, looking at the steps one need to take just for drawing a rectangle. The sole primitive shape. Also, using pixels, being "a resolution-dependent bitmap canvas", it doesn't help much.

    Which lead you to the conclusion that canvas if for rendering flat images. And here is where I mildly disagree. You can do that, with a few benefits over classic images, and over the hurdles of using just JavaScript on HTML elements like div, as canvas clones. But if that was the case, SVG would be easier and faster to implement, with better results, facing the same challenges for support and fallback.

  15. #15
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by itmitică View Post
    canvas is one of those elements that can actually produce a full scale progressive enhancement. That is, it can replace the whole content, it can put it in a better visual shape, and serve it with the full interaction package content had in the first place, +1.
    All that if you can handle the complexity for the task. Which is huge, looking at the steps one need to take just for drawing a rectangle. The sole primitive shape. Also, using pixels, being "a resolution-dependent bitmap canvas", it doesn't help much.
    I don't really understand what you're getting at here, but I'll try. Canvas, being just a bunch of pixels could be used for almost anything(replacing form elements for example). That's true but I don't think those types of uses will become popular because like you say it's hard to get anything done quickly with it's API, if there are easier methods people will use those. And the whole point of form elements is that the input device can choose a method of display that suits it's user. Mobile devices have been a great example of why we should just let devices handle data input.
    Canvas is not a "full interaction package" at all - It's just pixels you can draw on. There are no events on different parts of the <canvas> so if you want to interact with it you need to use the same old mouse / keyboard / touch events on other elements.
    These are the issues that stomme was pointing out with it - if you want to be able to interact with it you need to manage all of that complexity yourself outside of the <canvas>.
    Which lead you to the conclusion that canvas if for rendering flat images. And here is where I mildly disagree. You can do that, with a few benefits over classic images, and over the hurdles of using just JavaScript on HTML elements like div, as canvas clones. But if that was the case, SVG would be easier and faster to implement, with better results, facing the same challenges for support and fallback.
    Maybe there's confusion with my choice of words - All I've said is that <canvas> is an <img> where you can manipulate it's pixels with javascript. I never said you couldn't make animation with it or update the image in real-time.

    SVG is a collection of lines, shapes, text, images. Being part of the DOM and having it's own markup you can edit these objects independently in the markup, as well as interacting with them via events on the individual parts, or with javascript.

    There is overlap between the technologies and some things can be achieved with both - In those cases I'll normally go with svg unless there's performance issues. Of course, you can also render strings of SVG in Canvas so the lines get even blurrier.

  16. #16
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by ds
    LOCALSTORAGE -- because after years of people complaining about cookies storing information, now we're going to be able to store even MORE crap on a users machine. Possibly handy for apps, potential for abuse massive.

    DB -- ditto.

    GEOLOCATION -- I don't get the appeal/need for this. But then anyplace you should really 'need' geoloc you probably wouldn't have coverage anyways. Could be cute for making
    I'm optimistic about Localstorage & db, with more and more processing moving to the client it's only natural.

    Mobile is huge Jason, I find location based web services to be some of most engaging user experiences on the web.
    It's not just limited to mobile, but that's it's biggest use case.

    Because after twenty five years since I first encounted "ready for real world use" speech input, it has improved by leaps and bounds to where it's ACTUALLY ready for real world use -- NOT.
    Tried Siri yet? If not brilliant yet it will get there at some point, I think it's a natural progression that deserves an input type.

    NO MORE VENDOR LOCK-IN!
    I don't understand what you mean, the point of the sources is that they aren't locked in - you can use any formats supported by the browsers.
    If you mean that they shouldn't have allowed mp4's to play I don't think that's right, it's one of the most popular formats.
    Code html5:
    <video controls preload="auto" width="640" height="264" poster="my_video_poster.png">
      <source src="my_video.mp4" type='video/mp4'>
      <source src="my_video.webm" type='video/webm'>
    </video>

    Quote Originally Posted by itmitică
    Time will tell if content for canvas can be actually generated automatically by simple and interactive tools.
    There'll be great tools for this in no time. I'm liking the look of http://radiapp.com/

  17. #17
    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 markbrown4 View Post
    I don't understand what you mean
    That's very apparent from the rest of the post...

    Quote Originally Posted by markbrown4 View Post
    the point of the sources is that they aren't locked in - you can use any formats supported by the browsers.
    Emphasis mine -- Which means it's all about what formats the browser makers want to support -- as opposed to OBJECT where anyone could get off their tuchas and write a plugin to provide support for ANY format and introduce *shock* NEW FORMATS -- Not just the ones each browser maker feels compelled to add to the codebase.

    I'm not singling out ANY single format or even group of formats (like MP4) -- that's not what I'm even talking about -- I'm talking about vendor lock-in to whatever codecs each browser maker happens to feel like adding as opposed to letting anyone who wants to add a format simply make a plugin. That's a MASSIVE step backwards from OBJECT in terms of intent, freedom, and all the other things they seem to be claiming it's there to prevent. I've been saying that since the day I heard about the Video tag and the complete idiocy of hardcoding codecs into the blasted browser.

    In fact... OBJECT was supposed to replace even IMG for that reason; so new formats could easily be added (like jpeg2k back in the day, webm pictures today) without digging into the guts and codebase of each browser.

    They want to impress me, code in support for whatever codecs I happen to have support for installed on the host OS or through third party applications. Not to put too fine a point on it, but why are we dicking around with crappy slow codecs hard-coded into the browser, instead of just wrapping the windows media extensions for win users and embedding VLC into the browser for everyone else? Oh wait, then they wouldn't be able to try and shove MP4, Ogg or WebM down our throats when what the majority of content providers want to use is h.264...

    But of course, then Apple wouldn't be able to say "no flash for you" when it's FINALLY the king of online content delivery in a meaningful manner with actual *SHOCK* hardware acceleration -- but no, Apple would rather force you into either MP4, or their buggy slow pile of crap (at least on windows) called Quicktime.

    It's akin to the pissing and moaning done by the freetards over Mozilla considering adding h.264 support. Oh noes, NOT THAT, it's the end of the world... god forbid they add support for a codec content providers actually want to use, that there's existing hardware in place to provide REAL acceleration for, etc, etc...

    Which is exactly why it's delivering the EXACT OPPOSITE of all the claims those two tags are supposed to be about... the real reason being apparent to anyone who takes the time to look; it's all about browser makers being too lazy to sandbag plugins, get a unified plugin format, interface properly to the host OS for media, and pimping whatever codec they just so happen to have happy feelings in their nether regions over.

    It's funny, I hate flash on websites for things other than actual videos and games; and I'm no fan of Adobe, but at this point for video, I think we need to have someone tell Apple and it's users to go shtup themselves in terms of delivering video to them. Sometimes things become a monopoly because *shock* they work, when the alternatives are a absolute mess.

    OR maybe I'm just pissed that my Acer Revo I've been using as my media center the past couple years struggles to play 480p video in Theora or WebM, can BARELY manage MP4 480p playback off YT inside a browser unless I force it to use flash, can't manage Netflix in HD thanks to silverlight -- but can handle a 1080p blu-ray h.264 rip in MPC or Hulu in HD flawelessly?

    Oh yes, progress. That's what we have.

    (P.S. Remember, MP4 is more a container than a codec, unless you mean the really OLD Mpeg4 codec; NOT that mpeg codecs are exactly bleeding edge anymore in practical deployment -- what with blu-rays STILL using MPEG2 like a crappy 1984 laserdisc; when you could fit two blu-ray movies on a single dvd with maybe 1% data loss using h.264 or webm -- though h.264 is based on mpeg4... as was DiVx... gah, it's a mess.).

  18. #18
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by ralph
    As Stevie says, it would be really useful if you could signal to a screen reader which way to pronounce these. (I don't know how screen readers handle these, but I can well imagine the user gets fed either "Seeya" for CIA or "En-Ay-Ess-Ay" for NASA.)
    Sometimes they really screw up words. Generally you either hear a word mis-pronounced enough in the voice you usually use that you get used to it, or you hear something weird and you go back and spell the word out (and see if it's in upper or lower case) to figure out what it was.

    How a word is pronounced depends on the voices you have, the synth you have, and the language (and how well that language had been built). Like, I was getting pretty exited that NVDA was getting a new Dutch voice, but the guy who was helping on it, I'd have to ask him how that's going.

    You ought to hear VoiceOver say "Firefox", it's creepy. Veeerevux. Also wieeeb developers. Lawlz.

    Anyway I don't think how to pronounce a word belongs in the HTML. If it's a standard dictionary word it should be handled on the AT side.

    Quote Originally Posted by crusty
    We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....
    Not sure why HTML10 would need that added, we already have Schema :/ which I would only ever use if a client told me they had software that actually did something with it, since the whole adding all that itemscope prop etc stuff just seems like a lot of extra bytes for a reader who doesn't exist.

    Microformats are outside the scope of HTML though. Which may be a good thing. With attributes like the data-foo ones where browsers increasingly don't do anything with the attribute at all, but it's there for someone else (Javascript, desktop software) who may also be reading the HTML, it could open up possibilities (and confusion) and leave HTML alone.

    So anyway, back on topic: who else uses HTML5 stuff, and which stuff does you uses?

  19. #19
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,107
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Normally I rag on the tinfoil hat brigade, but really you just outlined the potential for abuse and why I don't like it. I don't want websites to be able to look at where I am unless I tell them... and even then the most I'd tell them is what town/zip code. I could MAYBE see it for the whole maps/directions thing, except IMHO that should remain client side operations as how most current GPS navigation systems work.
    That's exactly how it's implemented, it asks for permission.
    If you don't want to give it, it could be coded to prompt you for some location info that you would be willing to give, like a post code.
    I often forget that people even use numeric keypads for text input -- particularly for any sort of actual data form -- it's so uselessly awkward I really can't see wasting time worrying about them, particularly as moving forward mechanical keyboards on phones seems to be going the way of the dodo... but then the last mobile I owned with a mechanical slid in half sideways to reveal a full QWERTY so...
    Yes, touch screens are clearly dominating the market, there will still be mechanical keyboards around for specific things but they won't be the majority in the future.

  20. #20
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    In a lot of ways you outlined a hefty chunk of what's WRONG with HTML 5.

    Quote Originally Posted by markbrown4 View Post
    Other tags, like samanime pointed out are quite useful like <time>, these provide valuable semantics to a page that HTML4 didn't.
    Except is that type of semantics even warranted on 99% of the sites people are going to put it on? Does ANYTHING MEANINGFUL really care about the last microsecond of detail on the time. The TIME tag strikes me as being akin to TITLE attribute idiocy; where most of the time if you need TITLE, there's something wrong with the contents of the tag you are applying it to.

    ADMITTEDLY, there is the whole America vs. RoW time issue of what comes first, month or day; But the solution to that if you care is to spend the time to *shock* spell out the month. We have computers, we can do that automatically now. "j F Y" FTW.


    Quote Originally Posted by markbrown4 View Post
    Again, reading code with these tags makes them more readable.
    How so? Extra inline-level phrase-type elements doesn't make it more legible because it breaks up content that probably shouldn't be. So many of the existing tags go unused either out of ignorance (DEL,DFN,KBD,SAMP,VAR,TH,LABEL,CAPTION,LEGEND,FIELDSET), bashing them into 'specific roles' making them useless for anyone (ADDRESS), or people just being too stupid to figure out which witch is which (ABBR,ACRONYM) -- throwing MORE phrase, structural or special elements in is NOT the answer.

    Quote Originally Posted by markbrown4 View Post
    The variety of tags isn't a problem in itself. It was aimed to pave the cow paths and implement semantics for things that people were coding over and again with meaningless tags like div/span.
    ... missing the point of using them -- NOT changing the content's existing meaning. Natural language and formatted data so far as USERS are concerned shouldn't NEED extra semantic tags for each and every little stupid case. That's just making more work for developers for no real tangible benefit. We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....

    Putting many of the new tags squarely into the same bin as all that microformats asshattery -- except instead of abusing abbr we're making the spec more complex than it needs to be. It's like all this metadata crap many OS try to add to files that NOBODY actually has the time to bother filling out -- unless you can automated like with MP3's it's pointless. (trust me, as a former BeOS user I've seen it in action) -- Most DEVELOPERS can't even be bothered to use verbose names for ID's, classes or filenames, much less the cryptic "What the devil does that mean" normal people use for their files.

    Quote Originally Posted by markbrown4 View Post
    Enough about the semantics already. HTML5 was designed for web applications. Let's talk about that instead.
    Which is another hefty part of my issue with HTML 5-- what in blue blazes does that have to do with Markup?

    An HTML specification should be about writing markup -- a scripting specification should be about writing scripts -- a CSS specification should be about writing CSS.

    But they've thrown it all under HTML 5's banner because without those extra things, it would be meaningless rubbish that serves no point... and since you can use CSS3 and the new scripting WITH HTML 4/XHTML 1, what's the POINT?!?

    Quote Originally Posted by markbrown4 View Post
    The really interesting parts of HTML5 that set it apart are Forms, Rich Media(Audio, Video), 2D/3D Graphics(Canvas, WebGL, SVG - though not technically part of HTML5), Offline, and the other Javascript API's(localstorage, db, geolocation).. among others.
    Again, which has what to even DO with writing markup?!?

    Let's go down the list of these 'features'.

    AUDIO and VIDEO -- Redundant to OBJECT, locks us into supporting whatever pet codecs the browser maker wants to shove down our throats and locking out third parties from introducing their own to the browser... The fractionalization of video formats I predicted back when the Ogg whackjobs were touting VIDEO as the greatest thing ever has actually come to pass. There is no legitimate excuse for these to be new tags, or that the scripting that makes them desirable over object could not have been added to the existing tag. A new universal plugin format and forcing browser makers to sandbag their plugins (like chrome does) would have been MUCH more helpful.

    CANVAS -- Shouldn't even HAVE an element since it's JS only... and if you bother having capabilities detection you're already building it's context on the dom before adding it; at which point is one more createElement really gonna kill you? This would have been much more useful if it could be attached via script to ANY element.

    WEBGL -- This may someday actually be useful -- but JavaScript timers could REALLY use a massive overhaul to make this useful... though again this has WHAT to do with markup?

    SVG -- Remember when Adobe was the champion of SVG 13 years ago (since it's loosely based in part on Postscript)? Of course not! They torched it, pissed on the ashes and buried it in a deep dark place the MOMENT they bought out Macromedia. SVG is one of those 'pipe-dream' formats that fails to deliver on it's promises by being needlessly complex, needlessly verbose, and too difficult for the average person to even THINK about using despite it's alleged "XML simplicity". It's been around for as long as HTML; and it's gone NOWHERE for a reason. People are trying to use CANVAS instead because they can at least wrap their heads around it... which is sad given that CANVAS isn't exactly simple either.

    LOCALSTORAGE -- because after years of people complaining about cookies storing information, now we're going to be able to store even MORE crap on a users machine. Possibly handy for apps, potential for abuse massive.

    DB -- ditto.

    GEOLOCATION -- I don't get the appeal/need for this. But then anyplace you should really 'need' geoloc you probably wouldn't have coverage anyways. Could be cute for making

    Quote Originally Posted by markbrown4 View Post
    HTML5 Forms should be used - one strong reason is that using the new types enables mobile browsers to switch keyboards for the types.
    NOT even sure what that means... could you elaborate?!? "Switch keyboards?!?" on mobile?!? You've lost me.

    Quote Originally Posted by markbrown4 View Post
    There's heaps of great additions to HTML forms validation
    MAYBE if people would stop blowing 500k+ page loads on five input element forms, practicing separation of presentation from content and stopped resorting to hundreds of K of javascript for nothing -- resending the form populated wouldn't be the end of the world? I mean you're going to have to validate the data again server-side anyways.

    THOUGH, the inclusion of 'required' and others is welcome because if they aren't present/functional, big deal. Validation is one of the things I do welcome; BUT -- I'm worried about all the people who will think it can be trusted and fail to provide fallbacks.

    Quote Originally Posted by markbrown4 View Post
    placeholders
    For the people too lazy to bother using labels. Better than wasting javascript on some sort of garbage content swap that to be frank, strikes me as something that should be handled using ":target" in CSS instead of putting it in the markup; We're talking about a presentational effect performed on content that by all rights should be in a LABEL.

    Quote Originally Posted by markbrown4 View Post
    speech input
    Because after twenty five years since I first encounted "ready for real world use" speech input, it has improved by leaps and bounds to where it's ACTUALLY ready for real world use -- NOT.

    Quote Originally Posted by markbrown4 View Post
    Rich Media is painful and inconsistent - but adding these to the specs is the right move, don't hate progress.
    ... and if it isn't progress? If it stifles innovation by locking you into each browser makers favorite pet codec? If javascript's timers and response times needs complete overhauls to even make them viable for all the things the legacy formats handled? If it prevents content providers from even wanting to consider using it? (Lemme put it this way, you won't see Hulu or Netflix using them any time soon -- DRM is not EVIL people, it's only in the hands of companies like SONY...)

    Quote Originally Posted by markbrown4 View Post
    The Javascript API's are the most of HTML5.
    The most what?!?

    Though again, what's that got to actually do with writing HTML? NOTHING.

    Quote Originally Posted by markbrown4 View Post
    Oh yeah, and everyone is on the same page with the doctype, use it.
    Define 'everyone' -- as I think we have a different definition!

    Complete lack of versioning, no link to the defining document, completely discarding the mechanism that was put in place so that browsers could automatically support new doctypes -- that not one browser maker has gotten off their asses to implement properly? But no, let's go for this 'living document' crap, throwing out any chance at providing consistent baselines and readiness states. All it does is the lip service feel good "look we're using less characters" without taking the time to think about why the original was so 'large'. Besides, if the size of the doctype was causing a significant impact on how long it took to write a page, deploy it to users, or any of the other lame excuses used to justify said shortening, there's probably something disastrously wrong with the page it's being applied to.

    Again, you can tell nobody with an engineering background is even remotely involved in HTML 5's creation.

    Quote Originally Posted by markbrown4 View Post
    the point that HTML5 is to support Web Applications and richer experiences on the web. Not all web developers need to use these features, so HTML4 is fine. But if you're building a rich, interactive web application you'll want to look at some of these features.
    90% of which work just fine WITHOUT HTML 5 since there's nothing stopping you from using most of the new scripting goodies and css3 'gee ain't it neat' stuff in a HTML 4 / XHTML 1.0 document. The only things you lose in terms of the 'rich content' are AUDIO and VIDEO, which to be frank we need to start standing up to the W3C and Browser makers and tell them what we REALLY need to tell them.

    NO MORE VENDOR LOCK-IN!

    Which is funny since that's what they claim those new tags were added to fight... RIGHT. Apple must love it though, they've been all about vendor lock-in since they day they introduced the Lisa.

    Though to get back on track, you pointed out all the really useful bits of "HTML 5" -- too bad most all of them have NOTHING whatsoever to do with writing HTML. You take those away, and there's no longer even a reason to HAVE a new HTML...

    Bottom line, "Newer isn't always better" -- and when they have to hide their idiotic rubbish changes to the markup behind other specifications that have nothing to do with marking up content; well, does the term snake oil ring a bell?

  21. #21
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,881
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    How so? Extra inline-level phrase-type elements doesn't make it more legible because it breaks up content that probably shouldn't be. So many of the existing tags go unused either out of ignorance (DEL,DFN,KBD,SAMP,VAR,TH,LABEL,CAPTION,LEGEND,FIELDSET), bashing them into 'specific roles' making them useless for anyone (ADDRESS), or people just being too stupid to figure out which witch is which (ABBR,ACRONYM) -- throwing MORE phrase, structural or special elements in is NOT the answer.
    What was wrong with many of those was that they didn't have a sensible use-case. I do use some of them regularly, but things like <kbd>, <samp> and <var> were never going to be used outside of an extremely narrow scientific context, so they shouldn't have been built into the spec. Likewise, the difference between <abbr> and <acronym> is arbitrary and unnecessary - acronym is a subset of abbreviation, and it completely ignores the one useful distinction of initialism, which would have been helpful for screen readers.

    Paving the cowpaths is not such a bad idea. Where a significant number of real-world uses have been found for a particular element or property, it makes more sense to include that in the official spec than to leave hundreds of different home-made unofficial heath-robinson attempts as the only way forward.

    ... missing the point of using them -- NOT changing the content's existing meaning. Natural language and formatted data so far as USERS are concerned shouldn't NEED extra semantic tags for each and every little stupid case. That's just making more work for developers for no real tangible benefit. We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....
    Reduction ad absurdum. Computers are good at understanding natural language and figuring our what part of speech each word is, they don't need it to be programmatically specified. Being able to tell a computer a specific date/time, which a human reader would be able to infer, could be useful. If people want to use it then they can, if they don't want to then they don't have to. It adds to the potentiality of the language. As you are so fond of reminding people, HTML is about encapsulating meaning, not creating a particular mode of display. To that end, HTML is also being used for wider purposes, particularly on the mobile web, and allowing a richer interaction with other applications such as calendars is a natural direction to go in.

    GEOLOCATION -- I don't get the appeal/need for this. But then anyplace you should really 'need' geoloc you probably wouldn't have coverage anyways.
    On the contrary, it can be very useful for maps and directions, transport services (what time are the buses from my nearest bus stop(s)?), store locators, weather reports – all sorts of things. I think it would be great when I'm on my mobile (which is a bit slow and clunky when browsing a lot of sites) if it went straight to the most appropriate page for my location without me needing to type in and search for it.

    NOT even sure what that means... could you elaborate?!? "Switch keyboards?!?" on mobile?!? You've lost me.
    Some touch-screen mobiles switch between full text keyboard (or the traditional 0–9 number format text keyboard) and a purely numeric keyboard depending on the <input> type. If the device knows that I have to enter a number into a particular input, it's more helpful if it just gives me numbers and nothing else.

    THOUGH, the inclusion of 'required' and others is welcome because if they aren't present/functional, big deal. Validation is one of the things I do welcome; BUT -- I'm worried about all the people who will think it can be trusted and fail to provide fallbacks.
    A lot of the time, I really don't care if a form fails. If someone fills in a contact form and mistypes their email address then hard luck, they won't get a reply. I'm not going to set up a complex pattern match to allow for eejits who can't type tom@hotmail.com without messing it up, but if I can put type="email" on it nice and easily then that's a good solution – no effort to me, and it will help out the eejits with supporting browsers.

    The sort of people who will use HTML5 forms for essential validation were probably the sort who would use Javascript as their sole form security measure before ... not really worth worrying about them!

    Complete lack of versioning, no link to the defining document, completely discarding the mechanism that was put in place so that browsers could automatically support new doctypes
    Completely irrelevant. With the exception of quirks mode – which was never actually about the doctype anyway, because you can have standards mode or quirks mode with any of the doctypes, that was just a handy place to have the switch – browsers ignore the contents of the doctype. It doesn't matter if you tell the browser it's HTML3.2 and then put HTML5 tags in there, they will render it just the same. So what's the point of having a long and complex doctype that is mostly full of redundant information? Nothing. So KISS – all browsers need to know is that it's an HTML document, and they will deal with each and every element that comes up.

    But no, let's go for this 'living document' crap, throwing out any chance at providing consistent baselines and readiness states.
    What the 'living document' does is ensure that there can be some real world deployment within the next ten years. if we had to wait for the HTML5 spec to be finished and then for all browsers to catch up, we'd never be able to use it. And whether or not you approve of what HTML5 adds and takes away, you have to agree that that wouldn't be a sensible development strategy.

    Or to put it another way – if HTML5 was not a living document then you open up the possibility that existing elements could change their function, you reduce backwards compatibility. That's the only reason you would need versioning. And as soon as you do that, any page written in the new language becomes incompatible with older browsers that don't support it. We're too far down the line for that, rendering agents are ubiquitous and while it might be firming up some features we would rather not have had, we need the "pave the cowpaths" approach.

    I'm not saying I disagree with everything you wrote – I'm right with you on the stupidity of tying Javascript too closely with the HTML and on vendor lock-in for rich media – but HTML5 introduces lots of new possibilities as well, and it's far better to welcome them and look to see where they could be used beneficially than just to rant and rave (although you do that so well ).

  22. #22
    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 Stevie D View Post
    What was wrong with many of those was that they didn't have a sensible use-case. I do use some of them regularly, but things like <kbd>, <samp> and <var> were never going to be used outside of an extremely narrow scientific context, so they shouldn't have been built into the spec.
    Scientific context? I'll give you that for VAR, but the others, not so much.
    Code:
    <p>
      Type <kbd>CATALOG<kbd> to pull up a directory from AppleSoft Basic and it should return a listing like:
    </p>
    <pre><samp>DISK VOLUME 254
    A 002 HELLO</samp></pre>
    KBD is for text to be entered by the user -- SAMP is for sample output... Programmatic/computer related perhaps, but not what I'd call 'scientific'...

    Though you want to talk 'narrow context' I'll give you that for ADDRESS, which has been so completely shoved into a narrow and specific role that if you restrict it to what it's supposed to be for, you'll never use it on a website.

    Quote Originally Posted by Stevie D View Post
    Likewise, the difference between <abbr> and <acronym> is arbitrary and unnecessary - acronym is a subset of abbreviation, and it completely ignores the one useful distinction of initialism, which would have been helpful for screen readers.
    Not quite sure where you get either of those as they are grammatically two entirely different things... and initialism is just acronyms without the periods -- ooh.

    Quote Originally Posted by Stevie D View Post
    Reduction ad absurdum. Computers are good at understanding natural language
    Laugh... since when?!? Joke, I'm assuming you miss-spoke.

    Quote Originally Posted by Stevie D View Post
    and figuring our what part of speech each word is, they don't need it to be programmatically specified. Being able to tell a computer a specific date/time, which a human reader would be able to infer, could be useful. If people want to use it then they can, if they don't want to then they don't have to. It adds to the potentiality of the language.
    In other words, let's throw away one of the driving mantras we've been told the past decade -- write for people, not for computers. It's content micromanagement...

    Quote Originally Posted by Stevie D View Post
    As you are so fond of reminding people, HTML is about encapsulating meaning, not creating a particular mode of display. To that end, HTML is also being used for wider purposes, particularly on the mobile web, and allowing a richer interaction with other applications such as calendars is a natural direction to go in.
    Seems much like microformats before it -- to me at least, to be a waste of code, waste of time, for some mythical data scraper type user agent which has yet to materialize, and likely never will.

    Quote Originally Posted by Stevie D View Post
    On the contrary, it can be very useful for maps and directions, transport services (what time are the buses from my nearest bus stop(s)?), store locators, weather reports – all sorts of things. I think it would be great when I'm on my mobile (which is a bit slow and clunky when browsing a lot of sites) if it went straight to the most appropriate page for my location without me needing to type in and search for it.
    Normally I rag on the tinfoil hat brigade, but really you just outlined the potential for abuse and why I don't like it. I don't want websites to be able to look at where I am unless I tell them... and even then the most I'd tell them is what town/zip code. I could MAYBE see it for the whole maps/directions thing, except IMHO that should remain client side operations as how most current GPS navigation systems work.

    Quote Originally Posted by Stevie D View Post
    Some touch-screen mobiles switch between full text keyboard (or the traditional 0–9 number format text keyboard) and a purely numeric keyboard depending on the <input> type.
    I often forget that people even use numeric keypads for text input -- particularly for any sort of actual data form -- it's so uselessly awkward I really can't see wasting time worrying about them, particularly as moving forward mechanical keyboards on phones seems to be going the way of the dodo... but then the last mobile I owned with a mechanical slid in half sideways to reveal a full QWERTY so...

    Quote Originally Posted by Stevie D View Post
    A lot of the time, I really don't care if a form fails. If someone fills in a contact form and mistypes their email address then hard luck, they won't get a reply. I'm not going to set up a complex pattern match to allow for eejits who can't type tom@hotmail.com without messing it up, but if I can put type="email" on it nice and easily then that's a good solution – no effort to me, and it will help out the eejits with supporting browsers.
    I agree partly on the "let's not bend over backwards to help the re-re's" but a server side check of a e-mail is pretty simple, and should be done just so you don't fill up your DB with trash or send a pointless e-mail to yourself.... and since you're going to check it anyways, is it really that hard to re-send the form populated?

    Quote Originally Posted by Stevie D View Post
    Completely irrelevant. With the exception of quirks mode – which was never actually about the doctype anyway, because you can have standards mode or quirks mode with any of the doctypes, that was just a handy place to have the switch – browsers ignore the contents of the doctype. It doesn't matter if you tell the browser it's HTML3.2 and then put HTML5 tags in there, they will render it just the same. So what's the point of having a long and complex doctype that is mostly full of redundant information? Nothing. So KISS – all browsers need to know is that it's an HTML document, and they will deal with each and every element that comes up.
    ... which is PART of the problem, hence my saying "completely discarding the mechanism that was put in place so that browsers could automatically support new doctypes" since if it's not already present the file/data linked to in the doctype is supposed to be downloaded and parsed to help build the page... if the browser makers had gotten off their asses and implemented doctypes properly fourteen to fifteen years ago, we could introduce all those fancy new tags HTML 5 wants and they'd just work, all the way back.

    The problem isn't the doctype being too long, the problem is browsers ignoring it and failing to use it for what it's FOR.... as such throwing some stupid lip-service for backwards compatibility at it is NOT the right answer. HTML 5 is full of these types of idiocies -- where instead of solving the problem (let's ride Microsoft's ass about not implementing OBJECT properly) they throw up their hands and introduce something new for no good reason.

    Quote Originally Posted by Stevie D View Post
    What the 'living document' does is ensure that there can be some real world deployment within the next ten years. if we had to wait for the HTML5 spec to be finished and then for all browsers to catch up, we'd never be able to use it. And whether or not you approve of what HTML5 adds and takes away, you have to agree that that wouldn't be a sensible development strategy.
    Sorry, the engineer and social observer in me sees that as the same type of idiocy as credit; a pay more later for something we can't afford now attitude. It's the "we want it NOW, NOW, NOW!" attitude that to be frank, is a hefty part of what real world is tanking the economies of first and second world nations.

    In other words, the EXACT same idiocy that led to there even being a 'quirks mode' for browsers in the first place! Jumping the gun on non-finalized constantly under revision specifications is how you end up with such scenarios. Oh noes, it might take a decade or more to implement; the problem with that is what exactly?!? If what we have now works... I'm not seeing the issue apart from the 'ooh, new and shiny' crowd clamoring for things before they're ready... assuming they should ever be ready or adopted in the first place.

    ... which describes most everything markup related in HTML 5 in a nutshell, and a hefty chunk of CSS3.

    Quote Originally Posted by Stevie D View Post
    Or to put it another way – if HTML5 was not a living document then you open up the possibility that existing elements could change their function, you reduce backwards compatibility.
    Gehugafugah?!? That's the OPPOSITE of what strict versioning does...

    Quote Originally Posted by Stevie D View Post
    That's the only reason you would need versioning. And as soon as you do that, any page written in the new language becomes incompatible with older browsers that don't support it.
    Unless of course in terms of markup there was say... a mechanism in place.... like say... a doctype with a link to the structural rules of said new language; that browsers would bother to parse before building pages... I know, crazy idea. Couldn't possibly have anything like that.

  23. #23
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,112
    Mentioned
    448 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by deathshadow60 View Post

    StevieD: "the difference between <abbr> and <acronym> is arbitrary and unnecessary - acronym is a subset of abbreviation, and it completely ignores the one useful distinction of initialism, which would have been helpful for screen readers."

    Not quite sure where you get either of those as they are grammatically two entirely different things... and initialism is just acronyms without the periods -- ooh.
    An acronym is a kind of abbreviation, as is an initialism, so they are a subset, as Stevie says. Initialisms and acronyms can both be written with or without periods. The difference is that an initialism is pronounced as a series of letters (like CIA) while an acronym is pronounced like a word in its own right (such as NASA). As Stevie says, it would be really useful if you could signal to a screen reader which way to pronounce these. (I don't know how screen readers handle these, but I can well imagine the user gets fed either "Seeya" for CIA or "En-Ay-Ess-Ay" for NASA.)
    Facebook | Google+ | Twitter | Web Design Tips | Free Contact Form

    Forum Usage: Tips on posting code samples, images and more

    Forrest Gump: "IE is like a box of chocolates: you never know what you're gonna get."

  24. #24
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....
    I don't see that happening. We have lists to save us from that. In fact, we have lists to save us from everything.

    After all, a phrase is a list of words:

    Code:
    <ul>
     <li role="personal" class="pronoun">I</li>
     <li role="verbaux" class="present">can</li>
     <li role="verb">see</li>
     <li class="pronoun">it</li>
     <li role="adverb">now</li>
    </ul>
    Right. All that remains now is to float them. Done. A little bit of right margin for each, a few :after to put punctuation in place. Done. Here you go. HTML10 saved.


    But I do agree with you Jason that some parts in the HTML5 specification aren't looking to be practical also, but are there for the novelty hype part. Time will tell if content for canvas can be actually generated automatically by simple and interactive tools. Like it's the case for SVG.

    Some parts of HTML5 keep the simplicity in place, as it should be, since that's what HTML is about: easy and affordable. canvas has a hard time keeping up with that. The rest, as you said, is more JavaScript then HTML. It doesn't need a 5 for it. It works very well without it.

    Maybe they should've called it Web5.0.1.

  25. #25
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,881
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by itmitică View Post
    After all, a phrase is a list of words:

    Code:
    <ul>
     <li role="personal" class="pronoun">I</li>
     <li role="verbaux" class="present">can</li>
     <li role="verb">see</li>
     <li class="pronoun">it</li>
     <li role="adverb">now</li>
    </ul>
    Sorry, but you're a week to early for that


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
  •