SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 64
  1. #26
    SitePoint Member
    Join Date
    Jun 2011
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    All though this is a nice attempt. You should keep in mind that you have to continue this learning. Otherwise this will bear nothing.

  2. #27
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    The global structure of an HTML document

    Is not, has not, nor ever has been part of the HTML 4 or 3.2 specification as a valid attribute on META.
    That's not relevant.

    Quote Originally Posted by deathshadow60 View Post
    Does NOT work in Opera, Does NOT work in Webkit, Does NOT work properly in IE (though it tries)...
    Please show me your test case where it doesn't work.
    Simon Pieters

  3. #28
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Interesting history of HTML specs though, as formatted web pages:

    HTML 2 - 11k (flat)
    HTML 3.2 - 122k (+32k of images)
    HTML 4 - 53k (+3k images + 3k CSS)
    HTML 5 - 4,824K (+601k images +2k CSS)

    Oh yeah, some real "improvements" there. When a specification goes from the size of the Declaration of Independance to larger than the KJV with a ribbon bookmark, it MAY be time to consider it a wee bit overcooked.
    Part of the problem of the older specs is that they were too ambiguous and left a lot of things open to interpretation of the browser makers, thus giving us the mess where you have several browsers rendering the same things in different ways. Of course, measuring how good a specification is by the filesize of the document that describes it is some pretty stupid logic right there, but I only see more specification for edge cases as a good thing.

    Also, FYI, CVS/Subversion has no minimum size of project that it can cater for, and proves just as useful for a single document as it does a whole project.

  4. #29
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    Part of the problem of the older specs is that they were too ambiguous and left a lot of things open to interpretation of the browser makers
    You mean the entire POINT of HTML? Device Neutrality? The reason for strict being to move all the ambiguous stuff out of the markup in the first place?

    Putting the blame ENTIRELY on how browsers allow elements to receive CSS instead?

    Quote Originally Posted by Stormrider View Post
    thus giving us the mess where you have several browsers rendering the same things in different ways.
    You mean the original POINT of HTML 1, 2 and 4 strict -- the thing people got away from with the disaster called 3.2 that it seems HTML 5 wants to bring back? The whole idea being to say what things are and let the user agent best determine how to show them -- or with 4 strict using CSS to tell the user agent (browser for you normals) how to show it?

    Quote Originally Posted by Stormrider View Post
    Of course, measuring how good a specification is by the filesize of the document that describes it is some pretty stupid logic right there, but I only see more specification for edge cases as a good thing.
    JUST talking markup we're talking 115 tags and around 40 valid attributes... As such we're talking 14k of text per element -- that's BULL. Especially since as HTML should have NOTHING to do with appearance all you need to do is say "this tag has these attributes and means this". When you need twice the size of the Declaration of Independance to describe a HTML tag, you need to go back and learn how to write. When your specification for something as simple as HTML is three times the combined total technical documentation of a US Military fighter jet, and 100 times the size of the US Constitution WITH the amendments...

    But then, I used to write technical manuals for Marstek -- where I learned the rule "if it takes you more than a page to explain it, you're explaining it wrong".

    Which is just part of why I say HTML 5 is crafted for the people still vomiting up 3.2/4 tranny and never grasped the point of strict, the advantages of separation of presentation from content, etc, etc...

    If you even use the word "rendering" in regards to HTML, you have missed the POINT of HTML 1, 2 and HTML 4 strict and are basically still in "transition" from 1997 to 1998... and you're laying the blame on the wrong part of the specification's lap. (the problem being elements like tables and inputs do not receive CSS the same way, browsers don't render named border styles the same way, etc, etc... that's not HTML's fault!)

    Quote Originally Posted by Stormrider View Post
    Also, FYI, CVS/Subversion has no minimum size of project that it can cater for, and proves just as useful for a single document as it does a whole project.
    Well no, REALLY? Completely missing my meaning in that it shouldn't be complex enough to NEED the software assist. That it is ends up just another indication of what a bloated useless train wreck NOBODY is going to take the time to understand.

    ... and to think the framers of HTML 4 called 3.2 "uselessly large".

  5. #30
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,598
    Mentioned
    411 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    I used to write technical manuals for Marstek -- where I learned the rule "if it takes you more than a page to explain it, you're explaining it wrong".
    Indeed. Part of the problem with HTML5 is that even the creators of it don't actually seem to understand it. Like what <nav>, <section>, <article>, <header>, <footer> and <aside> are actually for. (Everyone seems to have a different opinion about it, but it shouldn't be a matter of opinion.) It's no wonder everyone else is so confused.

  6. #31
    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 ralph.m View Post
    Indeed. Part of the problem with HTML5 is that even the creators of it don't actually seem to understand it.
    Well they obviously failed to grasp the point of STRICT or concepts like separation of presentation from content -- why should their comprehension of their own nonsense be any different?

    Of course when it's over 2 megabytes when converted to plaintext, who the devil is even going to remember any of it, much less comprehend it or even take the time to read it?

  7. #32
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    As I said though, rather a lot of that is instructions to browser makers on how to handle different elements, unambiguously, not everything in there is needed to USE the language

  8. #33
    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 Stormrider View Post
    As I said though, rather a lot of that is instructions to browser makers on how to handle different elements
    Which gets away from the concept and point of HTML 1, 2 and 4 Strict, and sounds a HELL of a lot like HTML 3.2 -- Since the default handling of HTML elements without explicit instructions from CSS should be ENTIRELY at the discretion of the user agent. If you're going to dictate how the elements work without CSS to the user agents, that SOUNDS like a return to presentational markup and all the crap STRICT was trying to get rid of. (and part of why XHTML 1.1 was doomed to failure as it too had that same shortcoming and philosophical failing -- trying to turn markup into something it's really not meant for)

    It's only when stylesheets are on the table that said behaviors should matter... but that's part of my problem with HTML 5... it's not JUST covering markup, they're slapping every other blasted specification out there under it's banner -- which of course is where all the useful stuff actually is. CSS3, the new scripting elements, aria, etc, etc, etc... Basically all the stuff that has NOTHING to do with markup.

    Which is what HTML is SUPPOSED to be about. Of course, if you took all that stuff away from HTML 5 it would be a rather pathetic, puny and pointless thing.

    Let's face it, all the really cool "HTML 5" stuff has nothing to do with HTML -- CSS3, the new scripting controls and scripting related elements (which is why for example I say canvas shouldn't even exist as a tag and should be added by scripting not markup), etc, etc... That's where the cool and useful stuff is.

  9. #34
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Since the default handling of HTML elements without explicit instructions from CSS should be ENTIRELY at the discretion of the user agent
    What a load of rubbish! The visual rendering of them maybe, but not how to handle the elements and how they should function.

  10. #35
    Mouse catcher silver trophy
    Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,830
    Mentioned
    110 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Which gets away from the concept and point of HTML 1, 2 and 4 Strict, and sounds a HELL of a lot like HTML 3.2 -- Since the default handling of HTML elements without explicit instructions from CSS should be ENTIRELY at the discretion of the user agent. If you're going to dictate how the elements work without CSS to the user agents, that SOUNDS like a return to presentational markup and all the crap STRICT was trying to get rid of.
    Sorry, but I think you're allowing your anti-5 prejudice to get in the way of rationality here...

    The tight specifications are around default presentation, behaviour, role and meaning of each element. They are not about how to get the visual presentation that you want using HTML, they are very clear that that is what CSS is for (with the exception of the blasted <font> tag). I don't see how a system that gives consistent implementation across different browsers can be a bad thing.

  11. #36
    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
    The tight specifications are around default presentation, behaviour, role and meaning of each element.
    I see not the distinction between default presentation or behavior, and presentation as a whole. The first two you list have no business in a HTML specification if working to the original intent.

    ... and frankly if it takes more than an average 5k of plaintext to explain the element in a specification format for BOTH browser makers and the people *shock* actually expected to use this shlock, there is something HORRIBLY WRONG with what's being implemented; ESPECIALLY with 99.99% of tags sharing the same grammar/syntax. The biggest distinction between them being unique non-common attributes, is it inline-level or block-level, what can it contain, what can it be contained in, as inline can it accept block parameters (img and textarea for example), and what is the tag FOR semantically.

    Anything beyond that has no business in a markup specification where we are allegedly supposed to be saying what things are, not how they appear.

    ... and would give you around 500k total, not 2.3 megabytes. Of course if like tags were actually combined down and some sensible content management were implemented, someone kicked whoever it is that has the love for cryptically vague legalese where it really hurts... it would probably be even less than that.

  12. #37
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    I see not the distinction between default presentation or behavior, and presentation as a whole. The first two you list have no business in a HTML specification if working to the original intent.

    ... and frankly if it takes more than an average 5k of plaintext to explain the element in a specification format for BOTH browser makers and the people *shock* actually expected to use this shlock, there is something HORRIBLY WRONG with what's being implemented; ESPECIALLY with 99.99% of tags sharing the same grammar/syntax. The biggest distinction between them being unique non-common attributes, is it inline-level or block-level, what can it contain, what can it be contained in, as inline can it accept block parameters (img and textarea for example), and what is the tag FOR semantically.

    Anything beyond that has no business in a markup specification where we are allegedly supposed to be saying what things are, not how they appear.

    ... and would give you around 500k total, not 2.3 megabytes. Of course if like tags were actually combined down and some sensible content management were implemented, someone kicked whoever it is that has the love for cryptically vague legalese where it really hurts... it would probably be even less than that.
    Dude, you're free to fork the spec and throw out everything you think doesn't belong in "HTML". As someone who works for a browser vendor, I know everything is needed to be defined (I don't care if it's in a spec called "HTML" or if it's split across several specs). Here's one fork you might be interested in, although I'm sure it's still way to much detail for you to be satisfied. HTML5 &mdash; Edition for Web Developers
    Simon Pieters

  13. #38
    SitePoint Zealot
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    HTML 2 - 11k (flat)
    HTML 3.2 - 122k (+32k of images)
    HTML 4 - 53k (+3k images + 3k CSS)
    HTML 5 - 4,824K (+601k images +2k CSS)
    Sorry if i don't get the point here. But what does images and css have to do with html5? I mean the images and css are there for the presentation. More images because nobody wants a site that looks like it was looking before 15 years (expect deathshadow60 )

  14. #39
    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 Glasspoole View Post
    Sorry if i don't get the point here.
    OBVIOUSLY... You completely missed the entire point of the section you quoted.

    Those are the sizes of the W3C pages FOR THOSE SPECIFICATIONS, as in how big the pages are... In other words HTML 4 required a tenth the images to explain itself that HTML 3.2 did, while HTML 5 requires 200 times as much. The initial numbers is how many K of markup (html) those specifications take -- meaning that from HTML 4 to HTML 5 they've grown the spec to over 90 times the size.

    Though that's unfair -- with HTML 4 they had the common sense to break it into separate pages and I'm only listing the main page -- instead of HTML 5 where they've dumped everything into one massive document that brings the fastest browsers on bleeding edge machines to their knees.

  15. #40
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    ...and the fact that the spec is all on one page means the whole language is rubbish how exactly?

  16. #41
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,598
    Mentioned
    411 Post(s)
    Tagged
    6 Thread(s)
    Off Topic:

    Quote Originally Posted by zcorpan View Post
    Here's one fork you might be interested in, although I'm sure it's still way to much detail for you to be satisfied. HTML5 &mdash; Edition for Web Developers
    Wow, that's really nicely written. Thanks for pointing to this.

  17. #42
    SitePoint Zealot
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah ok now i got it. Sorry...

  18. #43
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Though that's unfair -- with HTML 4 they had the common sense to break it into separate pages and I'm only listing the main page --
    So it's a completely useless comparison.

    Quote Originally Posted by deathshadow60 View Post
    instead of HTML 5 where they've dumped everything into one massive document that brings the fastest browsers on bleeding edge machines to their knees.
    HTML5 is also available as a multipage version, BTW. And HTML4 has single page versions in plain text, postscript and PDF.

    So let's compare the plain text versions.

    HTML4 - 792,282 bytes
    HTML5 - remove the listing of the inline cross-references, 3,137,665 bytes

    But this is still not a fair comparison. HTML5 replaces HTML4, XHTML1 and DOM2 HTML. Furthermore, HTML4 deferred parsing to SGML while HTML5 specifies parsing itself, so you need to compare HTML5 to SGML+HTML4+XHTML1+DOM2 HTML. I'll leave it as an exercise to the reader to find plain text versions of the other specs and sum up their sizes.
    Simon Pieters

  19. #44
    SitePoint Member
    Join Date
    Jun 2011
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Check it out HTML review from W3Schools Online Web Tutorials

  20. #45
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,233
    Mentioned
    47 Post(s)
    Tagged
    1 Thread(s)
    Bleh, W3Schools.
    W3F00lz.com

  21. #46
    Community Advisor ULTiMATE's Avatar
    Join Date
    Aug 2003
    Location
    Bristol, United Kingdom
    Posts
    2,158
    Mentioned
    45 Post(s)
    Tagged
    0 Thread(s)
    Thanks for posting that before I saw it. W3Schools is a liability to Web Development and use of it should never be encouraged.

  22. #47
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Bleh, W3Schools.
    W3F00lz.com
    Wish they had contact info somewhere on the site (or if there is I'll be damned if I can find it) -- I love the concept but they have some inaccuracies that just make them look foolish. (and some omissions).

    Of course that the page is an accessibility train wreck

    Still love the concept because yes, W3Schools is a mix of web rot, bad methodologies and outright misleading of nubes.

    Need something like that for Dynamic Drive while we're at it.

  23. #48
    SitePoint Enthusiast polyhedra's Avatar
    Join Date
    Nov 2011
    Posts
    84
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Lightbulb

    basically i've have been teaching myself html/css and now html 5. Throughout school i've seen kids using macintosh and linux ubuntu, and all these computer can browse the web that's coded in HTML5. So why choose not use html5, you can also use http://www.modernizr.com/ to ensure maximum presentation vaue right?


    "The facts that Internet Explorer has inferior support for what are standard, contemporary selectors within the CSS 2.1 specification. So what happens sometime in the murky future when Microsoft distributes a more modern browser--one that supports all of these features? Theoretically nothing, if all selectors and effects are supported equally-- this hypothetical version 7 of Internet Explorer for Windows would simple render the page as Mozilla and other browsers currently view it, and the world is a wonderful place."

    D.Shea,E.Holzschlag, D. S. (2005), Pg.211 . The Zen of CSS Design. Peachpit Press.

  24. #49
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,598
    Mentioned
    411 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by polyhedra View Post
    all these computer can browse the web that's coded in HTML5. So why choose not use html5, you can also use http://www.modernizr.com/ to ensure maximum presentation vaue right?
    It's similar to the debate over whether a life support machine should be used to keep someone alive. Some say yes, some no. Modernizr is a life support system, and it seems to work, but I don't understand why you'd use that when in most cases HTML4 provides everything you need. Some proposed HTML5 elements may change before this version of HTML is finished, too.

  25. #50
    SitePoint Enthusiast polyhedra's Avatar
    Join Date
    Nov 2011
    Posts
    84
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Arrow

    i actually noticed exactly that while trying to figure out the <time> tag, that they were considering changing it. So yes, they might change tags by the end, but, they still will be useful in HTML5 right?


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
  •