SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 87 of 87

Thread: HTML5 Renamed!

  1. #76
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,788
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by zcorpan View Post
    HTML is not a programming language.
    Exactly. HTML is a markup language and there is a standard for defining markup languages called SGML. If following standards is important (as those who developed HTML2, 3.2, and 4 considered it to be) then that standard should be followed in developing the markup language.
    Stephen J Chapman

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

  2. #77
    SitePoint Member
    Join Date
    Feb 2011
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The benefits from using XHTML are mostly unknown, even to those using it. Ask anyone why they are using it, and you would get the usual myths around accessibility on mobile phones, cleaner code, and even SEO related benefits.

    You may find the following interesting, posted by Ian Hickson on the WHATWG mailing list.
    > 7. The XHTML 5 spec says that "generally speaking, authors are
    > discouraged from trying to use XML on the Web". Why write an XML spec
    > like XHTML 5 and then discourage authors from using it? Why not just
    > drop support for XML (XHTML 5)?

    Some people are going to use XML with HTML5 whatever we do. It's a simple
    thing to do -- XML is a metalanguage for describing tree structures, HTML5
    is a tree structure, it's obvious that XML can be used to describe HTML5.
    The problem is that if we don't specify it, then everyone who thinks it is
    obvious and goes ahead and does it will do it in a slightly different way,
    and we'll have an interoperability nightmare. So instead we bite the
    bullet and define how it must work if people do it.
    source: http://lists.whatwg.org/pipermail/wh...ry/009517.html

    The main benefits from using XHTML is, as i understand, the ability for web designers to combine XHTML with other XML based languages, such as svg. But now that HTML integrates some of this extendibility, the need to use XHTML stands out even less.

    As for what the future holds.. Well i strongly believe in living standards, and i think they will, for the most part, replace the old version models.

  3. #78
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan View Post
    HTML is not a programming language.
    Quote Originally Posted by felgall View Post
    Exactly. HTML is a markup language and there is a standard for defining markup languages called SGML. If following standards is important (as those who developed HTML2, 3.2, and 4 considered it to be) then that standard should be followed in developing the markup language.
    I apologize for using incorrect vocabulary, but I think Stephen has succinctly restated a key issue. In 1997, we had developers marking up their pages in HTML 3.2. In Dec. 1997, HTML 4.0 was released. Each of these standards defined a set of features. Developers sitting around having a beer had a shorthand way of talking about a large scale feature set. Developer one can say something to developer two who responds "You're wrong, because of XYZ." Developer one responds "Oh no. I'm talking about HTML 4.0". Developer two concedes "Oh. Well, of course in HTML 4.0, I thought you were talking about 3.2."

    1) When the standard changes everyday, we can no longer use it as a communication tool like this. This is the entire point of a STANDARD.

    2) I see no way in which version numbers had any impact on the speed with which WHATWG or W3C did anything. Removing them will certainly not speed anything up (in fact, if this is simply a way of masking how little progress has been made, it will slow the development of HTML.

    3) Carrying this idea through, in what way was HTML less "living" and growing and advancing with version numbers then it is without them?

    4) If verions numbers are so detrimental to advancement, why isn't anyone else dropping versioning? If unversioned standards "live" in some way that versioned ones don't, why do Intel and Motorola chips have model numbers? That's just holding them back from making incremental progress and changing the chip architecture every day/week. Why don't Windows and Mac drop version numbers? Isn't it more fun to buy software for "Mac OS" or "Windows" and just hope that it will run on your computer? Versioning is a communications tool and is used by all good "living" projects. WHATWG is doing nothing to make the standard any more living than it always has been. They're only dropping the version number that people need as a point of reference.

    Quote Originally Posted by zcorpan View Post
    Acid2 could have been written the same even if CSS had been a living standard. Acid5 can also be written against the HTML spec just fine. Just choose parts of the spec that are stable when writing the test. Acid2 and Acid3 required thought and coordination anyway, and needed bug fixing afterwards. Case study: http://ln.hixie.ch/?start=1137799947&count=1

    So I'm not at all convinced that frozen snapshots are at all helpful in writing Acid tests. (You are aware that it's the same person who edits the HTML spec as who wrote Acid2 and Acid3, right?)
    ACID2 could have been written the same, but who would care. ACID2 unquestionably played a roll in finally driving MS to update their browser to versions IE7 and 8. It was THE benchmark for CSS2.1 compliance.

    ACID5 can only check for "HTML compliance as of Thursday Oct. 5th 2012 at 2pm" or something similar. By 3pm, when a new change is released... Who cares.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  4. #79
    SitePoint Member
    Join Date
    Feb 2011
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There won't be a need to refer to HTML as a certain number, since HTML also deals with old supported elements, and describe how they should behave, (while still encouraging the separation of content from style for new pages).

    If you ever felt you had a "need" to refer to section'(s) of HTML as "HTML5", then you may not even need to talk about these features in the first place. You could effectively refer to the sections in the spec, that is however not common practice by strangers to the spec.

    Are you on the hype wagon, or the practical uses wagon? You could refer to such features as simply "new features of HTML", arguing that its easier to say "HTML5" is subject of a fundamental change to the English language, I.e shorting of phrases. Which also occurs all the time, (whether officially recognized by dictionaries or not). Such eventually ends up with their own listing anyway, so whats the problem?

    You could look at things from a marketing view. Inventing a new, shorter phrase for "new features of x" could potentially make you famous.

    Developers are usually interested in specific features, such as the manifest file, the ability to use client-side localStorage etc.

    Quote Originally Posted by Chroniclemaster1
    If verions numbers are so detrimental to advancement, why isn't anyone else dropping versioning? If unversioned standards "live" in some way that versioned ones don't, why do Intel and Motorola chips have model numbers? That's just holding them back from making incremental progress and changing the chip architecture every day/week. Why don't Windows and Mac drop version numbers? Isn't it more fun to buy software for "Mac OS" or "Windows" and just hope that it will run on your computer? Versioning is a communications tool and is used by all good "living" projects. WHATWG is doing nothing to make the standard any more living than it always has been. They're only dropping the version number that people need as a point of reference.
    Someone has to make a first step, and what may work well for software and hardware, may not work that well for web standards, which often consists of smaller edits over time. It would be hilarious if people used same argument about other innovative ideas.

    The changes applied to standards can potentially be minor changes. For example, we don't want to increase the version number just because we add or remove a element. Rather potential new elements are often just silently supported by browsers, while we would otherwise be stuck waiting for the W3C to pull them self together.

    You could also look at the sections, or individual features as "patch IDs", where each element has its own section, describing how its used, and how it should behave. Some patches are removed, others are added, etc..

    Another important argument, is that you often hear web-designers talk of the new features like, "I can't wait until HTML5 becomes recommendation", when in fact many features can already be safely implemented, (often including the very features that people are waiting for).

    Hopefully that cleans up a few things in this thread, because its largely a mess.

  5. #80
    SitePoint Addict
    Join Date
    Nov 2006
    Posts
    206
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    I'd go with FRED. But it needs to stand for something. Fashionable Really Excellent Document is my suggestion.
    Perhaps it could be FrED: Frantic Electronic Data



    On a more related note:

    I've never combined an XML document to an HTML document, probably because I was never shown for what reasons I would do so. (read: the need wasn't apparent)

    It's probably also because I tend to render things using a prehypertextprocessing language :P
    Please...Never describe anything to me using foo and bar.

  6. #81
    SitePoint Member
    Join Date
    Apr 2009
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think this change is good. But it will take some getting used to.

    We've been telling clients that HTML 5 is the way forward but also to hold of on using it due to browser incompatibility. (This is now changing so we will start recommending soon) So now we need to explain more clearly that HTML is HTML5 just rebadged.. Sigh..

  7. #82
    SitePoint Member
    Join Date
    Feb 2011
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I read this entire thread. Very interesting indeed. As I enter college classes this fall for Computer Science, I am finding a huge interest and excitement for the future of web development. I read the book about html5 written by Bruce Lawson (I definitely recommend it) "Introducing HTML5".

    I see what zcorpan is saying about keeping everything in the spec to make sure the creators of the web browsers are required to support the "features". This is, however, a double edged sword. Yes the browsers will be required to support, but NEW pages will also be made using these depreciated features. Vicious cycle much?

    I am a HUGE fan of the way a lot of the tags in HTML5 have been cleaned up. I find the "no quote" to be a logical adjustment. Lets face it, quotations are semi redundant. For example:
    Code HTML4Strict:
    <html>
    <p class=... class2=...> ... </p>
    </html>
    Could you not just argue that anything directly following the = and ending with either a space or > accomplish the same thing? While allowing for a much cleaner syntax.

    As someone that uses a bit of PHP, any way to lower the amount of quotations needed is a major plus in development. It's always those pesky punctuation marks that cause trouble.

    Ultimately though, I believe and agree that having a number that can be referred to (html 5) is much better in terms of setting a standard. But I also think that this should be <!DOCTYPE> tag. I think the doctype should be a solid, strict standard depending on what you specify. I also agree that you should not have a page if not valid properly (within reason).

    If I start a document with <!DOCTYPE HTML5>, then it should follow the current HTML5 spec. If the page is not valid, then it should output the errors at the top of the page like a .php file would.

    Of course, this would require a tag for turning error reporting on/off. But the key thing here is not to display the invalid page, therefore forcing stricter development practice and making the web a better place.

    You could always add the <!DOCTYPE HTML> as a catchall standard. This could always be clarified by the browser by a "banner" on the top of the page saying something like "Doctype Not Specified!".

    I will say this also. It appears that the IE family causes some of the most problems in terms of HTML advancement, something that hopefully is worked out over the coming years.

    Just my 2c (a big one at that). First post also, looks like a great forums for discussion.

    -Xdga

  8. #83
    SitePoint Member
    Join Date
    Dec 2009
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    what i want to know is when are we going to get a php, html, pearl, cgi, Ruby, js combo?
    Really how long is it going to take to just combine all of them into one big pile of coding standard and let the good times roll?

    Also i want to be able to have a menu that when users hover over an item a hand slides from the side, then on click, the hand clicks the button and loads a dynamic page that makes calls to a database. I want to do this without having to use flash, php, html and js as a translator between them. Just one code. just one doctype to do it all. Its all i want. its what we need. it what Fred should have been.

    html(5 fred) do your thing. oh wait it still can't. so now what do i do? also do you know how hard it is to find a free host for testing sites that support every little feature you need?

  9. #84
    SitePoint Enthusiast
    Join Date
    Jul 2010
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Xdga View Post
    Ultimately though, I believe and agree that having a number that can be referred to (html 5) is much better in terms of setting a standard. But I also think that this should be <!DOCTYPE> tag. I think the doctype should be a solid, strict standard depending on what you specify. I also agree that you should not have a page if not valid properly (within reason).

    If I start a document with <!DOCTYPE HTML5>, then it should follow the current HTML5 spec. If the page is not valid, then it should output the errors at the top of the page like a .php file would.
    A browser always will (and always has) followed the latest standards - and will always be backwards compatible. So you can include a valid HTML5, HTML4.01 and HTML3 document and it will still work exactly the same. You've never needed to tell the browser what version you're using, and I don't see the point in doing so now?

    (As an aside, <!DOCTYPE html> is only there for legacy reasons related to how IE used to render the box model)


    Of course, this would require a tag for turning error reporting on/off. But the key thing here is not to display the invalid page, therefore forcing stricter development practice and making the web a better place.
    Displaying HTML error messages on the top of a websites is a very, very bad idea. Not only will it stop any future work (what if you want to use a new tag, but your user is using an old browser which doesn't understand it?) but it will break a lot of old sites

    Any HTML changes must always be backwards compatible for this very reason. It's why browsers will always continue to ignore things is doesn't understand

    Any displaying errors in general is always a bad idea. Even in php, displaying errors to the user is a bad idea

    You could always add the <!DOCTYPE HTML> as a catchall standard. This could always be clarified by the browser by a "banner" on the top of the page saying something like "Doctype Not Specified!".
    Because the user doesn't care or need to know about the fact you've not added an arbitrary number

    I will say this also. It appears that the IE family causes some of the most problems in terms of HTML advancement, something that hopefully is worked out over the coming years.
    As true as it is that Internet Explorer being in stagnation has caused problems in the past, Microsoft have done a lot of work on HTML and CSS (and always have), and Internet Explorer 9 is an extremely good browser. I'd go far as to say that IE7 is also a reasonable browser, and I rarely have problems with it

    Just my 2c (a big one at that). First post also, looks like a great forums for discussion.
    Welcome to Sitepoint!

  10. #85
    SitePoint Member
    Join Date
    Feb 2011
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not always the best at explaining my ideas (I often beat around the bush).
    But to paraphrase and explain my key points, here goes:

    I can see the counterpoint to enforcing strict coding. Legacy support would be bad, I understand that is a HUGE downside. But, in terms of evolving the web, I simply see no other way to ensure new methods are being used. I have to disagree with the transitional\fallback approach. Although it doesn't encourage old methods, it makes it all to convenient to code the same way you did 10-20 years ago when you began your career doesn't it? or just simply loading the page with so much fall back code that the performance degrades thus defeating the purpose to begin with.

    Any transitioning should be on the part of the browser. Web browsers should be updated often, in fact the times we live in they should be constantly auto-updated. Old websites do not need to be "broken", the browser should just simply make it clear that the current page you are viewing doesn't follow standard.

    Doesn't it appear to be somewhat of a paradox that you want a "living" and evolving standard, yet so insistent on allowing old ways to work just as well. Stunts the evolution process greatly when there is no dire need to evolve does it not?

    As far as error reporting, anyone that has done a mediocre level of PHP coding would be aware that the error reporting is typically disabled for the end user and used only for the means of debugging during development.

    ps:
    On a side note, something that made me chuckle earlier was a website that had the following disclaimer: "Web accessibility guidelines of the World Wide Web Consortium (W3C) were consulted to make this site accessible for all students." So I load up the page using Chrome (my browser of choice), only to be greeted with a wonderful JS popup informing me that I am using an "unsupported browser". I was loling and considering being ornery and reporting the issue. But for what it's worth the page appeared just fine.

  11. #86
    SitePoint Enthusiast
    Join Date
    Jul 2010
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Xdga View Post
    I can see the counterpoint to enforcing strict coding. Legacy support would be bad, I understand that is a HUGE downside. But, in terms of evolving the web, I simply see no other way to ensure new methods are being used. I have to disagree with the transitional\fallback approach.
    That's because you don't need to ensure new methods are being used. You shouldn't use the new bits of HTML just because you can. The first ever website is as good as standard HTML5 - it's not about using the newer standards, it's all about writing websites well

    (Even the <b> and <i> tags are still valid HTML, they just aren't often used correctly)

    Although it doesn't encourage old methods, it makes it all to convenient to code the same way you did 10-20 years ago when you began your career doesn't it? or just simply loading the page with so much fall back code that the performance degrades thus defeating the purpose to begin with.
    It's not about writing code with 10 year old methods, it's about there still being a lot of code written 10-20 years ago still being around today, and it not being cost effective to rewrite the code

    Any transitioning should be on the part of the browser. Web browsers should be updated often, in fact the times we live in they should be constantly auto-updated. Old websites do not need to be "broken", the browser should just simply make it clear that the current page you are viewing doesn't follow standard.
    Yes, browsers *should* be updated often automatically. But in the real world, they aren't. Progressive enhancement and graceful degradation techniques ensure that your website will work in any browser no matter how old it is

    Doesn't it appear to be somewhat of a paradox that you want a "living" and evolving standard, yet so insistent on allowing old ways to work just as well. Stunts the evolution process greatly when there is no dire need to evolve does it not?
    Not really, I'm not aware of anything that the working group hasn't been able to do because of the "don't break stuff" rule

    On a side note, something that made me chuckle earlier was a website that had the following disclaimer: "Web accessibility guidelines of the World Wide Web Consortium (W3C) were consulted to make this site accessible for all students." So I load up the page using Chrome (my browser of choice), only to be greeted with a wonderful JS popup informing me that I am using an "unsupported browser". I was loling and considering being ornery and reporting the issue. But for what it's worth the page appeared just fine.
    That's the problem with including warnings to users for using "old browsers". It will inevitably break in a few years, and if coded well it doesn't matter anyway

  12. #87
    SitePoint Member
    Join Date
    Feb 2011
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I guess after much thought and a very interesting watch of the presentation vid from Bruce Lawson (http://my.opera.com/ODIN/blog/2011/0...b-presentation). I can see where they are coming from, and given the origins of HTML5 the current direction and rhetoric from the WHATWG seems logical. The backwards compatibility is the basis of HTML5 which changes everything.

    I still believe there are a LOT of improvements that can be made to the spec such as the well known drag and drop issues. Also the <DIV> vs <SECTION> debate.

    But one thing I find VERY interesting is aparently the openness to join the WHATWG. I will definitely look in to joining this group to share my ideas if possible.

    It's amazing what interesting debate can come out of such a simple topic with regards to a version number. I will have to say I really don't care what it is called. At the end of the day you can combine PHP,JS,HTML... just refer to it as "Web Development" your situation and or career would determine what standards you follow. Hobbyist may mean you are loosely following standards if any at all, professional would likely mean you are in the loop and following cutting edge standards if you catch my drift. But you are all developing documents for the web, thus Web Developers regardless of your markup.

    ps: If anyone can lend more information on how to properly join the WHATWG to share ideas, I would greatly appreciate it.


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
  •