[QUOTE=deathshadow60;4623952]IF you are going to use that giant train wreck of incompatible garbage from a specification not even out of draft,[/quote]Wait, what’s incompatible?
[QUOTE=deathshadow60;4623952]you should also NOT be using set_timeout or the system timer to synchronize scripting to the video since the two can very easily be thrown out of sync the moment there is buffering involved, or changing the time index with the player you’ll end up having to write in javascript as well.
The appropriate thing to be syncing to is the .currentTime property on the player element.[/quote]That’s what I suggested, no?
[QUOTE=deathshadow60;4623952]For example, if your markup was:
<video controls id="myVid">
<source src="foo.ogg" type="video/ogg; codecs=dirac, speex">
Your browser does not support the <code>video</code> element.
</video>
you’d be using this in the script to figure out the current playback position:
[/quote] I guess you made a typo there, currentTime is not a method.
[QUOTE=deathshadow60;4623952]Though that code should probably be put in a function that is only called when the “timeupdate” event fires for that object.[/quote]timeupdate is only guaranteed to be fired every 250ms which may or may not be good enough for syncing purposes.
[QUOTE=deathshadow60;4623952]NOT that I can understand why you’d be wasting your time on a specification not even out of draft, that undoes ALL the progress STRICT gave us of making simpler markup, and has little to no consistent cross-browser codec support… Do yourself a huge favor, and stick with flash.
But that just goes with my total distaste for HTML5 as a whole.[/QUOTE]
I wish I could understand better why you have this distaste.
That’s actually one of the few useful additions in HTML 5.
DATALIST finally supplies the combo box form field that has been available to use everywhere else except on the web.
At the moment the only way to create a combo box is to use an input text field and use JavaScript to attach a list to it. The DATALIST element will attach the list to the text input field in the HTML without the need for the JavaScript.
You can’t create a combo box starting from a select as there is no way to add the ability to type your own value into a select field.
The example I usually use is a club where almost all the members live in Australia but where there are a couple who live overseas. The 99.9% who reside in Australia can select their state from the selection list while the couple who live in the USA can type their state into the field since it isn’t one that is listed. Being able to select an entry is far more convenient than having to type it in and a combo box is ideal for when most but not all entries will be one of a very small number of alternatives. It also avoids the problem of people abbreviating the input in different ways for what is supposed to be the same value.
Funny, maybe it’s because I’m in the US and we have fifty states, but whenever someone uses a select for that it pisses me off. It’s like “just use a text input” - I wouldn’t even want to waste the bandwidth on a select for a TWO LETTER field.
But then I remember the usability guide for Borland TPW (precursor to delphi), that basically said avoid having tComboBox with more than 12 options, or you’re just going to annoy the end user. That kinda stuck with me since yeah, it pisses me off whenever I land on a site that has… your example.
I guess I would like to type it in there - but at that point I’d also like to not waste time having the select in the first place on that. I come across the state field on a US website as a select, my gut reaction is “***** **** what the **** nimrod thought a SELECT was a **** good idea here?”
But that probably stems from breaking flow. Selects SUCK when using the keyboard, and since ‘state’ usually gets wedged between two text inputs; CITY and ZIP, it’s an annoyance at best, miserable **** /FAIL/ at web design at worst.
I guess I’ve never understood the combo-box in the first place as I’ve never had an application that warranted it’s use - if you’re going to let people type in whatever you want, what do you need the list for? - To me the entire point of having a list is to restrict what people can choose… you want the ability to add new options, that’s what an entirely different form on a different page is for.
Unless of course you’re building one of those miserable accessibility /FAIL/ on choosing a birthdate using a dropdown - but again at that point just use a damned input[text] instead of a select.
With the entire basis on which HTML 5 is built being quicksand compared to the rock that HTML 4 is built on it would probably be easier to scrap HTML 5 and start over.
We could start with HTML 6 being defined as HTML 4.01 strict with all the tags that XHTML 1.0 lists as mandatory being made mandatory and the closing slashes in the singleton tags being made optional. The definition would of course be SGML so as to follow the markup standards that HTML 5 abandoned. We could then add those tags and attributes that are proposed for HTML 5 that are actually useful additions such as <datalist> and <canvas>.
It doesn’t matter what garbage that the browsers decide to support and they may very well find HTML 5 a useful standard for what they want to actually build into their browsers but for those actually interested in developing easy to maintain web pages the entire concept of HTML 5 is a very poor quality garbage.
That the same standards are being used both by the browser developers to determine what they should support (which includes all types of garbage so as to try to make sense out of web pages written by any hobbyist) and professional web designers/developers (who want a standard that does things the most effective and efficient way) is the biggest cause of the disagreements over what should be in the standard. The web developers did a big cleanup of the HTML standard in developing version 4 and now the browser developers want to put all the garbage that they need to support back into the standard because they still need to support it even though only hobbyists ought to be using it.
At the very least HTML 5 needs to distinguish all of the tags such as <embed> and <iframe> that browsers need to support that should not be considered to be a part of the standards that anyone actually writing web pages should use.
I would suggest you file separate bugs for each change request. And please do. At best, the spec is changed as you request. At worst, you get a response from the editor explaining why the spec is as it is (and you can still escalate the request to overrule the editor’s decision).
Inside the class declaration it’s a property - once that class is assigned to a variable becoming an object, it’s a variable. The ONLY difference between a variable and a property once initialized in most any language I’ve ever dealt with is scope, and what base on the heap it’s an offset from.
IF the object method used by the compiler was to trap that crap like you suggest, it would be the most bloated convoluted mess you might as well go back to using line numbered basic so far as speed is concerned.
THOUGH, I will admit I wouldn’t be surprised if the total train wreck that is objects in C syntax languages did such a thing given how horribly objects are shoehorned into them.
In case you couldn’t tell, I’m a Modula/Smalltalk guy who started out working in assembly (on the 4040)… I can do C, but really objects in C++ and similar implementations are such a convoluted mess I often wonder why anyone would work with it by choice.
In any case, a class (aka object declaration) is nothing more than a complex ‘TYPE’ - like STRUCT or Modula/Pascal’s RECORD (which is why object pascal is so much more intuitive than C++). When you assign your class to a variable that variable becomes a pointer to where on the heap enough memory has been allocated for all properties… just like variables are, because that’s all they are at that point, variables; a pointer reference on the heap to enough memory to fit the TYPE… or to another pointer (or pointer/size pairing) in the case of untyped languages like PHP.
… and since I would kind-of assume any browser you would be working on would be in C++, what I said applies… though having peered my head into the codebase of gecko, I’d not be surprised if they have made everything more complex than it needs to be on that subject.
Somehow I think saying “we don’t need this tag” on 95% of the new tags wouldn’t qualify as a ‘bug’… and probably be shouted down pretty hard… Though that could just be my experience with online bug trackers like bugzilla colouring my opinion.
Besides, I’ve got the best “bugfix” out there for HTML5 - it’s called HTML 4 STRICT and/or XHTML 1.0 STRICT.
I agree that 50 is too many for a select in most cases. My example only has eight in the select and the input field for the 0.1% of people where none of the eight apply. There are plenty of other possible situations where you could have say three to ten options that apply 99.9%+ of the time where you want to allow it to be typed in for that remaining 0.1% and that’s where a combo box comes in handy.
It does. (For instance it declares <applet> as obsolete i.e. authors must not use.) It just happens that the WG disagrees with you about <embed> and <iframe>. Again, file bugs…
currentTime is not a variable, it’s a property. In the impl, it could just as well be causing an internal event on setting so that it acts exactly like you envision a method would.
It’s intended for implementing the video controls with javascript (which I guess is sort of syncing, but not the caption kind of syncing, just UI kind of syncing).
It represents a section with navigation links. Yes, I think that’s a semantic element.
I guess I’m not going to convince you on the complexity. Maybe you need to implement it in a browser and try to make it work with all web sites to appreciate that it’s actually a pain in the neck.
Not only do the majority of browsers in use have zero support for it - at least 40%+ of the public is unlikely to have support for it for at least six years. (since IE9 isn’t even going to be available for win mobile or XP/earlier just as IE7 isnt’ available for 2k/9x)…
But even if you look at the browsers that DO support it, you can’t even rely on the same codec being available on all of them - though thankfully it’s starting to look like VP8 to the rescue.
Odd, you know, I think I might be blind to one-line responses or something It’s like I’m automatically assuming they’re a “Me Too” response.
TS/DR?
Uhm, it should be on the player element - or am I thinking some other value since how else do you pull the time index of the VIDEO and not just the completely unrelated system timer… – edit – OH, my bad, it’s a float, not a function. So used to that sort of thing being a function… Though since that means it’s writeable I’m wondering what the overhead is on that instead of a function since that means polling the variable.
True that, so it would depend on the desired granularity. Good for a position control, not so good for sync for realtime animations (though probably more than adequate for things like highlighting boxes, comments or even subtitles)
… and that barely scratches the surface of my issues with it. HTML5 and CSS3 in their current state are cute toys to play with to report bugs and see what we might be able to use on production websites a decade from now - that’s what DRAFT MEANS!.
That’s not really true. All browsers have partial support, including browsers that existed before HTML5, since HTML5 defines defacto stuff that existed before it. Ignoring that, lots of stuff has been and is being implemented in browsers (for instance <video> has been shipped in Safari, Chrome, Firefox and Opera), but I think you know this so I’m not sure why you say there’s zero support. Ignoring that, stuff that hasn’t been implemented yet doesn’t fit my definition of ‘incompatible’…
I guess we’ll see.
Yeah, the codec issue is a pain in the neck. Let’s hope everyone will agree on VP8!
Heh.
I think there shouldn’t be any performance difference between calling a method and getting a property.
Yep.
Please continue to play with it and report bugs. If you do that, we can start using it in production sites sooner.
Some replies to your article:
nav is pretty clearly useful for people with ATs – you can skip to or skip past the navigation without the author providing skip links.
dialog was dropped (wasn’t convincing it was solving any problem).
We’re trying to make object work the same across all browsers. We’re not there yet, but we’re getting there…
It would be a bad idea to use object for video and audio – it is already overloaded with too much functionality (that’s why it doesn’t work the same across browsers!). With new elements, it’s possible to provide a useful DOM API.
I don’t see what’s bad about making embed valid.
target is useful for submitting a form to an iframe. Or for opening links in new tabs (I know, I hate it as well, but people are going to do it, the question is whether we should punish people who want to validate and make them jump through workaround hoops to fool the validator, which is what happens in practice).
There are use cases for <style scoped>, like mashups, rapid prototyping, styles that really are local…
The ‘prepend the word form before every attribute on a input’ was done for compatibility – Opera found that supporting <input action> broke pages out there, so we changed it to <input formaction> (which IMO is clearer – the attribute changes the action of the form, not the input itself).
I agree that adding more stuff makes the language harder to learn (since there’s more to learn), but everything’s there for a reason. Every added element and attribute has a use case backing its reason for existence. (If there isn’t, it should be removed.)
bugzilla 915 is about a presentational feature (that HTML5 doesn’t even support in its user agent requirements). I thought you were against presentational features?
You’re right that HTML5 will take a long time to finish.
You still need to poll currentTime even if you use the timeupdate event if you want to sync with the video. Or am I missing something?
No, that’s not how it’s implemented. There’s no inherent difference implementation-wise from having a method setTime() and a settable property currentTime. Or am I missing your point?
Yeah, I know polling isn’t optimal. currentTime wasn’t designed for syncing. The spec doesn’t have any API designed for syncing yet, but it’s in the works (see timed tracks). Right now, you want to sync, polling currentTime is the only option.
Skip links are a work-around for the lack of a semantic element in HTML. Now that we have <nav> (well, in a few years when it’s supported), we don’t need skip links. By your argument we shouldn’t have <h1> either since we can provide the same functionality with a skip link…
I thought I explained that…
Wow, it sounds like you have no idea what object does.
It’s:
a fallback mechanism
an image
an iframe (that can be navigated)
a plugin, dynamically updating the DOM interface and blocking scripts that try to access it until the plugin is loaded (REALLY a pain in the neck for implementors, I should know), being careful to not try to load the plugin too early until all param elements are declared, being careful to pass the parameters for the attributes on object in markup order and script insertion order, and not miss the detail that a parameter PARAM:null should be sent to the plugin between the attributes and the param elements… (I could go on)
a form control
dynamically changing to any of the above at the whim of scripts
It’s not ‘piss simple’.
No, the point of strict was to obsolete presentational HTML 3.2 features that could be implemented using CSS at the time HTML4 was being specified. embed isn’t browser-specific, it has been cross-browser compatible for ages.
<img> is redundant with <object>. Should we remove <img>?
It’s not the case that anything new is going to be broken anyway. If a tag is not used on the web, introducing it doesn’t break anything. Opera shipped support for <input action>. It broke pages, so we had to change to something that doesn’t break pages. It really is that simple.
No, that’s not the reason. You’re not helping us getting on the same page by being silly.
align=“” is not presentational? Ok.
Maybe it’s not prioritized?
No comment.
I’m still not sure what the crap is. Could you make a list of things you want removed?
The difference between polling and event driven. Polling is always slower for the player itself as it has to check that value on every iteration for unexpected changes if you write to it. A function call like setTime() could put the new value on an event stack, meaning the event handler would only process the change when neccessary instead of checking for it every time it goes to render a frame.
Event Driven > Polling when it comes to overhead, even when sometimes event driven is more code; the trick being only to call the extra code when you have to instead of calling the smaller code every single time… programming 101, optimize INSIDE the loop. (trust me, I’m trying to implement an event driven trigger on a analog resistor array instead of polling digital inputs on a Teensy++ right now… )
If you are using NAV, isnt’ that the same as providing skip links? Net change zero. Honestly that one feels like the same thing as the people who put <div id=“header”> around their h1/logo/menu for no good reason – instead of actually getting rid of the unneccessary code they made up a tag to justify the waste… pretty pathetic.
Wow, sanity.
Then what the **** do we even need EMBED, VIDEO and AUDIO FOR?!?
… and that couldn’t have been done on object WHY? Object is piss simple and doesn’t have ANY of the headaches AUDIO and VIDEO are introducing - I’d love to kick IMG to the curb as it is and would have years ago if IE supported it properly without quicktime installed. It’s in no way “overloaded” with functionality; anything that isn’t fixed text content goes in a OBJECT tag - simple. Moronically so for the site developer and code-wise in the browser shouldn’t take anything more complex than a nested switch for embedded functionality and a plugin poll for externals.
Browser specific tag redundant to object. Redundant tags are bad - that’s the entire POINT of STRICT.
Or tell the people who want that behavior to go shove it up their rectum… Which I also believe is one of the points of STRICT.
You mean wasteful code, defeating the point of using CSS in the first place, and **** that should be handled by saying what the element IS not how it appears so CSS can actually handle it? (IN THAT ORDER!)
But I say the same thing about most CSS frameworks - bloating yourself out with presentational classnames defeats the point of using CSS in the first place; You take your trash libraries like YUI or Grid960 - one might as well go back to using HTML 3.2 for all the sense it makes.
So nevermind that anything using the new tags is going to be broken legacy ANYWAYS - so what difference does doing that as ‘action’ make in the first place? That’s complete nonsense.
If by reason you mean bloat.
915 is about STRUCTURE, SCOPE and proper INHERITANCE. Mind you, CSS3’s nth-child negates much of the need for it, but really such a gaping hole in the HTML 4 spec to remain not even ASSIGNED for more than a decade? Oh yeah, that open source fixes bugs SO quickly.
That’s the problem with open source, if it’s not worth it to organize a bounty for, and it’s not flashy or trendy, and the people who want it to work have neither the skills or the time to fix it - it will NEVER be fixed. At least with commercial software you might have a boss cracking that whip.
… and having read over and tried it out, I’m not sure I ever want it to be. It’s a bloated train wreck just as bad as all the extra crap added to HTML 3.2 that the STRICT doctype intentionally tried to get rid of… in fact, much of it is the EXACT same crap that was added in 3.2 that STRICT tried to get rid of.
First up, I’m gonna hit notify… Oh wait “flag” … after posting this asking the mods if we can get a thread split, it’s a good discussion but we’re dragging this WAY WAY WAY off topic.
I think so… You write to a variable - big deal, you changed a variable. The system has to poll it to find out it’s changed. You write to an event heap (like the BeOS event system or the Windows GDI) you don’t have to poll every time you write a frame - it’s not on the heap, there’s nothign to check for apart from the normal event heap check you’d be running ANYWAYS.
But then people look at me funny for how I write my WM_KEYDOWN and WM_KEYUP handler since it sets a two digit response instead of boolean in a check array that is polled on a event driven state change.
Then what the heck is it even FOR?
Assuming you think NAV is a semantic element - I’m just not sold on it as anything more than wasteful bloat… but I’m the guy who’s constantly saying “What the **** is this extra DIV you have around your H1 and UL#mainMenu?”
Let’s put that in logic flow order.
Then of course we start our switch
CASE for supported formats, return true if it works.
CASE, new dom object rendered on a surface on the parent element, return true if it works.
CASE, check if plugin exists… call the plugin and return true if it works
none of the other mechanisms returned, so show the fallback.
BIG DEAL.
parent thread suspend new, state change old-school (one variable – ooh)… That or you just dont’ EXPOSE it to the DOM or scripts until AFTER its’ loaded. After all, isn’t that one of the ADVANTAGES of pointers and a object model? Nil pointer on the element, build it in a dummy pointer, when it’s done copy the pointer over to make it go live?
Oh noes, you have to wait for </object>!!! Sorry, not buying it.
You mean actually apply them in the order they are SET?!? Who’d have THOUGHT!!! As if that magically takes extra work?!?
You know, I noticed the spec referring to it having something to do with form controls – but since it lacks a value attribute, just exactly what would it even be DOING on a form? Or is that a mechanism so plugins can return values to the parent page? If so, again, simple data passing.
Oh noes, calling the same code a second time… Gee, build it as a standalone, copy old pointer, move new one in, discard old pointer, send a DOM rebuild message… Not exactly blowing my skirt up.
Not as complicated as you make it sound either. The code to implement each of those functions would certainly be complex, but no more so than making individual tags for each - the only extra code being a simple nest of drop-through checks that if you do your prep ahead of time well enough, should be little more than a switch statement and a few IF’s.
No, that’s just PART of it.
MENU, DIR, APPLET - deprecated because they were redundant (the first two to UL, the last one to OBJECT) . It’s also why EMBED was supposed to never see the light of day… and why I HATE the idea of AUDIO and VIDEO. We don’t need more tags. Hell, anybody remember BGSOUND?
The OBJECT element is used to include objects such as images, audio, videos, Java applets, and Flash animations. OBJECT is intended to replace the more specific IMG and APPLET elements, as well as the proprietary EMBED and BGSOUND elements, though a lack of browser support and severe bugs in supporting browsers make the other elements a better choice in many cases.
[/quote]
[QUOTE=zcorpan,post:15,topic:60509"]
<img> is redundant with <object>. Should we remove <img>?
[/quote]
YES!!! THAT’S THE POINT!
Only reason it didn’t work was M$ sitting around with their thumb up their ass about updating IE for half a decade. Well, that and the number of designers REALLY embracing STRICT worldwide likely numbering in the double digits.
Of course that article is typical of what I expect from Yank - misses the point on every page.
The whole point of stylesheets is to get the presentation the **** out of the markup. If you’re going to inline it with <STYLE> or STYLE=“”, it’s still in the markup! DEFEATS THE POINT. Especially since things you set in STYLE may not even apply to all stylesheets, and while yes, you can do media on the style TAG, you can’t do it on attribute.
Only place it belongs as a tag is on a quick testing page… it shouldn’t even EXIST as an attribute, and frankly as both an attribute and as a tag, I’d obsolete them… likewise obsoleting all the deprecated tags. Remember, there’s a difference between deprecated and obsolete; and really the validator should be throwing WARNINGS if a tag is only deprecated.
INLINED CSS does nothing but make pages a royal pain in the ass to maintain.
It’s not being silly - I’m not convinced that any of the new tags are neccessary, do anything to make documents easier to build, faster to develop or easier to maintain. The only part I have ANY use for in the entire spec is probably CANVAS, and the new form attributes. (and I still hate the names)
Ok, I’ll give you that… but it not working is still a failure of proper inheritance, structure and scope… and since without slapping classes on every blasted TD there’s no other way to actually target them in every browser, it might be nice if the ONE OVER A DECADE OLD way of doing it actually worked in gecko when everyone else has been doing it just fine since 1998. Hell, even IE5.0 gets it right.
Actually, it’s funny to watch - past two years it’s been in drydock as unassigned, but before that it’s been assigned, even slated to appear in releases at least SIX TIMES, and then mysteriously been nowhere to be found when the allegedly fixed release materializes - even FUNNIER since at one point it was reported as fixed in the nightlies like three or four years ago.
Well… let’s see…
ARTICLE - redundant to DIV, while it might help data scrapers there’s no reason to be applying that much meaning when you could just start the section with a perfectly good heading tag and put the actual text in paragraphs - very handy if one were to oh say, stop slapping paragraph around every inline-level tag for no good reason. (see IMG)
ASIDE - people can’t even figure out how to use P properly, I don’t even want to think about how this one is going to be abused. Again, redundant to div, oh noes I might put a ID on it that actually SAYS what it is… and if using this tag much like the previous one either need a wrapping container with an ID or an ID/class on it ANYWAYS.
AUDIO/VIDEO - redundant to object, merge the damned codebases. Oh noes, you need to add two conditions to the SWITCH at the start. (god forbid you just trap the TYPE attribute)
CANVAS - I’d probably lose that in favor of a render mode on OBJECT as well.
COMMAND - redundant to form elements in some cases, anchors in others. Why do we even need this? I mean look at the attributes - checked, disabled, label, radiogroup, type… and types parameters are checkbox, command and radio… Dooieey!
DATALIST - Why not just use a SELECT?
DETAILS and SUMMARY - cute, but pointless. Not sure why we even need that and because it’s JUST the crap people usually throw in the footer on a page it’s meaning is SO specific that I’d not be surprised to see it go the way of ADDRESS, another tag nobody uses. Of course that nice OPEN attribute will be great for people to abuse for content cloaking. Guarantee the search engines start ignoring that element almost overnight when HTML5 does become a reality.
EMBED - again, that was supposed to be objects job which is why it was NOT added in HTML4 - and why APPLET was dropped.
FIGURE and FIGCAPTION - I’m not even sure what the hell those are FOR. MOST of the examples seem to be using it like it was a DL… I would have thought a FIGURE would involve images, like a PLATE. See figure 1… but that doesn’t seem to be it.
FOOTER - Ok. Here’s one tag that a decade ago when I was still doing presentational markup I’d have said sure… today? Not so much. Oh noes, I have to use a div… Big deal, doesn’t add anything I actually care about on a page. Still, might be nice to not use the ID and might save a couple bytes, goes into my “I could go either way” bin.
HEADER - Would be fine if the first thing I put in it wasn’t likely going to be a H# tag… You know, HEADINGS. Redundant, pointless – whatever.
HGROUP - Why on earth would you group headings one after the other BEFORE the content for the last heading… Do we not even understand how to use a damned numbered heading tag in the first place?!? Looks like something for the people who slap an h2 after the h1 when they arent’ even starting a new subsection.
KEYGEN - Yeah, that’s gonna work. I like the idea, but I’m still fuzzy how the hell that’s going to even be trustworthy running client-side. I mean, all the data ends up cleint side so how is that even secure? Waste of time.
MARK - Ok, you got me here. THIS one makes sense. Fits in nicely with CODE, DFN, SAMP, VAR and KBD. I like this one.
METER - Another waste of time. If the text itself isn’t clear enough to say what it means, you’re using the wrong text. MIGHT be handy though if used around an IMAGE, though really the alt text should handle that too.
NAV - Didn’t we get RID of the menu tag as redundant to UL… so now we need a wrapper around our list of links for… christ only knows what reason. Sure you want to ditch skip links I suppose it almost makes sense, but I’d rather include them so I can pass title and accesskeys for things like Opera’s accesskeys menu anyways. (something that ROCKS in Mini on a handheld on sites that support it)
OUTPUT and PROGRESS
Scripting hook {sexual preference slur avoided}… Because what we need is to encourage the use of MORE javascript. (wait, isn’t that the opposite of why we have all those shiny new form attributes?). If a normal container isn’t good enough for 'em, oh well!
RUBY, RT, RP — uhm, isn’t this character encoding’s job? AT MOST a job for the LANG attribute? Admittedly I don’t have the most experience with oriental character sets… Though what experience I have would say it would be a LOT more useful if we could get top to bottom priority before RTL.
SECTION - well, that’s nice and vague, and this is different from a DIVision how exactly?
SOURCE – because we couldn’t possibly just re-use the existing PARAM attribute.
TIME – Ok, I like this one too. Good way to shut up the microformats junkies and their abbr abuse.
Oh, and let’s not forget the undeprecated:
MENU – A tag I did’t think should have been deprecated in the first place, since what it SAYS it is would be far more useful than ‘NAV’… but then I always hated code where people call the main menu ‘nav’ since every blasted link on a website is navigation… vague/meaningless… there’s a reason I do it <ul id=“mainMenu”>… except of course it wasn’t brought back for that - that would make too much sense. No instead let’s make it for wrapping form elements because what we need is more tags to use in our forms. Great when most people can’t even be bothered to use FIELDSET, LEGEND and LABEL and usually just abuse a definition list or table for it. Was deprecated as redundant to UL, why is it being brought back for FORMS?!? (christmas on a cracker people, is inline-block or float:left on a label so damned hard you need half a dozen extra tags for nothing?)
So out of all the new tags, I only really think we NEED two of them, and in total would only be ‘ok’ with five of them… to me the rest are pointless bloat, redundancy etc, etc…
Of course, I’d obsolete all the deprecated tags from strict (hell, I’d even code it in that they don’t even WORK in modern browsers with the 5 doctype)
Hell, if nothing else you’d think less tags would be EASIER to implement, it certainly would be faster to render since you could tree out the checks since it would be a shorter list of possible values.
Though at the same time, I can actually keep ACRONYM and ABBR straight so I don’t understand the need to get rid of it just becuase some people are idiots, I’d probably axe AREA and MAP since there’s no legitimate need for imagemaps in my mind, BDO should be redundant to BOTH the LANG and DIR attributes, BUTTON should go as redundant to INPUT - not like it ever worked right cross browser anyways, I’d be half tempted to axe DL just since nobody uses it for what it’s actually FOR, but leave it in for people who aren’t dimwits… open up numbered headings to a infinite number limit, and as mentioned get rid of IMG.
Doesn’t help I’ve yet to see any site done using HTML 5 that was worth a flying purple fish.
i mean a bad part of web today. activities of users generating content. play time is almost over. things are about to become less sordid on the web. legislation, business interests are going to make internet a less fun place but a more secure one. and with it, individuals will educate into a healthy use of web content.
business means also entertainment. video and music will remain. the change is not in terms (like web 3.0 or web 2.0) but in it’s users behaviour, which now are acting a little bit like viking conquerors (or spanish conquerors for that matter).
so html5 should not try and make web appealing to weak over-the-weekend formed developers in detriment to normal concerns. i like looking at a browser on how secure it is or compliant, not how well it plays video and audio. html5 should consider real problems faced by a rather poor interface that requires so much media over so little actual amount of sane objects and elements.
i find it very laughable when ms produces ides that are building pages that it’s own browser doesn’t recognize. these are real concerns. v8 will be forgotten, ie will never be. and not in a good way. what is html5 doing to help ie? and help us for that matter?
if we are going to have to support versions of ie in the future the same way until now, html5 and css3 should come with solutions here. this is practical. this is hands on. removing things saying are deprecated it’s easy. helping developers of all kinds deal with deprecated browsers is gold. later we can turn it into fools gold and ditch it. but html5 it’s producing fools gold as it is.
let html5 bring a consensus rather than a feel that it’s pushing forward (which is only to serve some immediate interests). chaos can be restored after.
From what I can see there isn’t anything in HTML 5 that affects web 2.0 at all since its support for Ajax is no different from earlier versions of HTML.
Web 3.0 being back end and related to the way you design the database would also be completely unaffected.
<video> <audio> <embed> and <iframe> will become superfluous once IE6 dies since the HTML 4 <object> tag will then perform all of that functionality in the same amount of coding but with more options.
… after posting this asking the mods if we can get a thread split, it’s a good discussion but we’re dragging this WAY WAY