Jump to content


Check out our Community Blogs

Register and join over 40,000 other developers!


Recent Status Updates

View All Updates

Photo
- - - - -

Is there a way to use less divs in HTML?

HTML

  • Please log in to reply
36 replies to this topic

#25 WingedPanther73

WingedPanther73

    A spammer's worst nightmare

  • Moderator
  • 17757 posts
  • Location:Upstate, South Carolina
  • Programming Language:C, C++, PL/SQL, Delphi/Object Pascal, Pascal, Transact-SQL, Others
  • Learning:Java, C#, PHP, JavaScript, Lisp, Fortran, Haskell, Others

Posted 26 October 2011 - 07:38 PM

Hmmm... Customers? Is thy website an online store?


A "compiler" is good; a "decompiler" would be nice too, however.


Not really. We have a desktop app that stores data in a database. Many of our customers use the desktop app to track the work they do for their customers, so we also provide a web portal so their customers can interact with the same database. What that means is we provide an end-to-end solution.

Since the "source" version of the code is stored in version control, there's no need to "decompile" it, as I always keep it. Also, the "compiled" version, being server-side code, is still human-readable.
  • 0

Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

My MineCraft server site: http://banishedwings.enjin.com/


#26 RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Expert Member
  • PipPipPipPipPipPipPip
  • 1311 posts
  • Location:C:\Countries\US
  • Programming Language:C, Java, C++, PHP, Python, JavaScript

Posted 26 October 2011 - 08:10 PM

Since the "source" version of the code is stored in version control, there's no need to "decompile" it, as I always keep it. Also, the "compiled" version, being server-side code, is still human-readable.


It's just looking at the Google home page's source is not too readable. I just want to see if HTML with Google Instant on and HTML with Google Instant off is any different, but, as one can probably notice, it's not very easy, especially with the high readability of Google's HTML code.

* * *

As for Google Instant, it might be a good idea for them to add some sort of keyboard shortcut that would enable/disable Google Instant. That *feature* is not really a problem at home, but every time I log into a computer at school, the cookies are reset, so Instant is on again :(.

* Not so much of a feature as is a drawback.
  • 0

#27 LBProgrammer

LBProgrammer

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 65 posts
  • Location:Long Beach
  • Programming Language:Others
  • Learning:C, Java, C++, Objective-C, C#, PHP, (Visual) Basic, Python, JavaScript, ActionScript

Posted 28 March 2013 - 10:46 AM

It's funny I have seen a couple of HTML tutorials where the instructor has clearly stated not to use tables for layout and do NOT use too many "div" tags. I just started HTML a month ago and was torturing myself trying to layout my first little website, I heard things in my head like "SFP the div tag is evil", "SFP the div tag will make you look like a bad programmer", "SFP there has to be another way then a div tag". Then I go out and look at some of my favorite and most used websites and the pages are filled with divs. As soon as I started using divs I actually started making progress with my layout. I think the "Too many div tags" thing is something you learn in school and promptly drop when you get into the real world.

Cheers,

SFP
  • 0
Would ya just watch the hair. Ya know, I work on my hair a long time and you hit it.

#28 RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Expert Member
  • PipPipPipPipPipPipPip
  • 1311 posts
  • Location:C:\Countries\US
  • Programming Language:C, Java, C++, PHP, Python, JavaScript

Posted 28 March 2013 - 12:57 PM

It's funny I have seen a couple of HTML tutorials where the instructor has clearly stated not to use tables for layout and do NOT use too many "div" tags. I just started HTML a month ago and was torturing myself trying to layout my first little website, I heard things in my head like "SFP the div tag is evil", "SFP the div tag will make you look like a bad programmer", "SFP there has to be another way then a div tag". Then I go out and look at some of my favorite and most used websites and the pages are filled with divs. As soon as I started using divs I actually started making progress with my layout. I think the "Too many div tags" thing is something you learn in school and promptly drop when you get into the real world.

Cheers,

SFP

Maybe the "don't use too many DIV tags" is a teacher myth, kind of like the 5-paragraph essay teaching? It is, after all, easier to grade a project that doesn't have as many DIV tags, just as it is easier to grade and teach a 5-paragraph essay.
  • 0
Regards,
RR

#29 JasonKnight

JasonKnight

    CC Addict

  • Senior Member
  • PipPipPipPipPip
  • 312 posts
  • Location:Keene, NH
  • Programming Language:C, C++, JavaScript, Delphi/Object Pascal, Pascal, Assembly, Others

Posted 06 April 2013 - 09:46 PM

RhetoricalRuvim, on 28 Mar 2013 - 17:01, said:
Maybe the "don't use too many DIV tags" is a teacher myth, kind of like the 5-paragraph essay teaching? It is, after all, easier to grade a project that doesn't have as many DIV tags, just as it is easier to grade and teach a 5-paragraph essay.

No, the 'don't use too many DIV' is an accurate assessment since it's often just nonsensical code bloat.

Take the OP's post - even for 2011 that's just shamefully BAD code. Now, you might be scratching your head as to what's wrong with it... well, here we go:

First line proudly proclaims it's a trap. Tranny -- transitional... it's in "transition" from 1997 to 1998 coding practices. The LINK to the CSS has no media target, it has pointless idiotic comments like this one:

<!-- header -->
<div id="header">

No **** Sherlock! We never would have figured out that opening a DIV with the id of HEADER might be the header.

It's got a DIV doing H1's job, It's got a H1 doing a H2's job, it's got DIV#header and DIV#menu for NO good reason... and that last one, you see a LOT.

For some whacked out reason people seem to LOVE slapping DIV around menu UL's for no good reason -- which is probably where the dumbass HTML 5 NAV tag really came from. UL is a perfectly good block level container and there's not a blasted thing you can do to a DIV you can't do to a UL, OL, DL, P, FORM or any other block level element!

From there it has CSS metric declarations in WIDTH and HEIGHT attributes (invalid markup, you want pixels in attributes you just say the number), ending comments that could trip rendering errors (no joke), STRONG tags inside a H1 [i(because something already as the topmost header under which all other lower order headings on the page are the start of a subsection needs "more emphasis")[/i], inlined style (I still say STYLE as a tag should be made obsolete and as a attribute should be deprecated), meaningless and cryptically short ID's, I suspect I'm seeing some presentational images in the markup, what are likely unnecessary ID's on a number of DIV, more div that probably aren't needed in the footer, more emphasis being applied for Christmas only knows what, and it tries to close more DIV than it opens.

So too many DIV, and just bad/sloppy code.

More of a problem in my mind is that for some weird reason when people hear "don't over use it" or "don't abuse it for the wrong purpose" their brains auto-translate that into "don't ever use it" -- and that's just wrong. I've heard people say that about DIV now that HTML 5's trip in the wayback machine with Mr. Peabody to 1997 is here, I've heard it said about tables, and even simple tags like B and I.

Tables are a great example... Don't use tables for layout -- seems simple enough. That does NOT mean don't use tables when you actually have TABULAR DATA. Of course with most programmers being at best vaguely aware of TH, and being outright unaware of CAPTION, THEAD, TBODY, SCOPE, AXIS, and a host of other things a proper table should have, it's hardly a shock nobody bothers using them correctly if at all.

Or B and I, where you have ignorant twits running around claiming they're deprecated (they aren't) or that you should only ever use EM and STRONG (you shouldn't). EM and STRONG have MEANING -- emphasis, and more emphasis... if you're not emphasizing a statement, you shouldn't be using either tag. B and I are for when grammatically it would be bold or italic in normal writing -- an example would be a book title or ship name. When I say "I read <i>Moby **</i> last week" I would not be adding emphasis to the book name.

Buddy of mine on another forums came up with this great example of all four being used properly:

<i>GURPS</i>, <b>Steve Jackson Games'</b> flagship roleplaying game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows</i>. However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS,</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong>

DIV can fall into the same trap, ESPECIALLY with the HTML 5 nonsense on the table. Stands to reason though with most developers never having dislodged their heads from 1997's backside, sleazing out HTML 3.2 and until a couple years ago slapping 4 tranny on it, and now just wrapping 5's lip-service around the same half-assed decade and a half out of date coding methods.

It shouldn't just be "don't use too many DIV" -- it should always be "don't use more code than you need to" and "use tags for what they mean, NOT what they look like!" -- which is why one should use DIV and SPAN in a lot of cases, because they are semantically neutral, do NOTHING to change the meaning of their content or provide grammatical structure to the document! They are there as hooks for grouping tags for the application of style, without saying what that style actually is, and nothing more! You want structure, that's numbered headings and horizontal rule's job!

But of course, nobody seems to be able to use those correctly either; hence the pointless redundant garbage from HTML 5 known as HEADER, FOOTER, NAV, SECTION, ARTICLE and ASIDE.

Oh, and sorry for long rant... You'll find if I decide to hang out here more often I'll be doing that a lot. I have a nasty tendency towards long posts, and an even nastier case of TSDR.

Edited by JasonKnight, 06 April 2013 - 09:40 PM.

  • 0
The only thing about Dreamweaver that can be considered professional grade tools are the people promoting it's use.

#30 RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Expert Member
  • PipPipPipPipPipPipPip
  • 1311 posts
  • Location:C:\Countries\US
  • Programming Language:C, Java, C++, PHP, Python, JavaScript

Posted 06 April 2013 - 10:04 PM

That is not the point of DIV tags and of HTML5; with programming, as long as something works it is okay. Why should it bother you that someone is doing something you do not like?

I personally use very many DIV and other elements in the HTML DOM and the HTML5 world I work, and I find your post a little offensive. I also personally cannot imagine getting something brilliant (e.g. cool web app) together without using many tables and DIVs.

I think I have written enough web apps by now to be able to say this: it is better to use more nested elements (e.g. DIVs) than to use less. It doesn't hurt anyone, and it makes expanding the app more convenient.
  • 0
Regards,
RR

#31 JasonKnight

JasonKnight

    CC Addict

  • Senior Member
  • PipPipPipPipPip
  • 312 posts
  • Location:Keene, NH
  • Programming Language:C, C++, JavaScript, Delphi/Object Pascal, Pascal, Assembly, Others

Posted 06 April 2013 - 11:36 PM

I find your post a little offensive

I'm used to that by now -- apparently my bothering to understand the point of HTML, the point of CSS, taking the time to understand what all the tags mean and what they are for, embracing 4 Strict, understanding the logic behind 4 Strict, and actually bothering to practice minimalist semantic markup with separation of presentation from content makes me some sort of 'radical' or 'heretic'.

That is not the point of DIV tags and of HTML5;

The POINT of a DIV is to be a semantically neutral container -- the only reason to put it in the markup it to hook it via CSS or Javascript... and I quote:

"These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes."

There is NO other reason to have them in the HTML if you are practicing semantic markup. They do not change the semantic meaning of what they wrap.

You have at least heard of semantic markup, right? (The moment you say web crapplication I have to assume not).

with programming, as long as something works it is okay. Why should it bother you that someone is doing something you do not like?

Depends on your definition of "works" -- how's it work CSS off? You know, basically what search engines, braille readers, screen readers, people on restricted connections or just don't want the goofy bandwidth wasting garbage end up with? How does it work (and this'll stick in your craw) with Javascript off? You know, all the people downloading extensions for FF and Chrome like "NOSCRIPT", or nutjobs like myself who use Opera because it has that functionality built in? How's the Images off/blocked with CSS on hold up? You know, all the folks on tethered data plans or in places like Canada and Australia who are facing monthly bandwidth caps with either cutoffs or overage charges?

PROPER site building for the majority of sites out there -- the ones providing actually useful information as opposed to the ones that just use images and js to dump a can of shellac on a pile -- should first make a working page with semantic markup and logical/proper structure provided by numbered headings (and HR to indicate changes in topic where a heading is inappropriate/unwanted -- ONLY good thing I can say about HTML 5 is it clarifying HR's job). If you can't make it work without CSS or Scripting, it probably shouldn't be a website unless you're doign something truly cool like google maps. Then it should be enhanced with all the different layouts (YES, PLURAL!!!) using CSS with proper media targets, and now media quereies. (and you don't need 5 for that either). Then and only then enhance the page with scripting.

Or at least, that's the ideal if you give a flying purple fish about accessibility. It's called progressive enhancement, one of the cornerstones of accessibility that is how one ends up with graceful degradation! Of course, such concepts are typically lost on those who start out with a hundred K or more of goofy javascripted animated garbage before they even have content of value plugged in. See the train wrecks of idiocy like Bootstrap or YUI; where one ends up with 70 to 140 files and multi-megabyte page sizes doing two dozen or less files and a quarter a meg or less' job! Much less how they work being the antithesis of the entire reason to use CSS in the first place. Same goes for things like OOCSS, one of the DUMBEST concepts I've ever heard and the antithesis of separation of presentation from content.

So why should it bother me? Because I'm sick of seeing webmail turned into inaccessbile broken ** that went from six years ago me thinking mail clients were dead, to the past two years me running screaming back to thunderbird and M2. I'm sick of having websites with little to no useful information on them taking a year and a half to load and pissing away the battery on my laptop, tablet or handheld just because someone wanted some stupid animated scripted effect that doesn't even work right on anything less than desktop resolutions. Quite often said 'effects' are just the worst of 1990's style animated GIF's on a larger scale or the flash ** we FINALLY got rid of. Naturally forgetting the problem wasn't that it required a flash plugin, but because it made pages load slower and was inaccessibile. Kind of like Target, where we tell people not to shove new windows down everyone's throat by deprecating it, and then the scripttards pour out of the woodwork to make it happen with JS ignoring WHY it was deprecated.

Most sites guilty of the above being slower and less useful than what was available 15 years ago on dialup.

It bothers me when a client calls me up now that I'm retired begging for me to bail them out because they got someone else to update them, and now they either need to move to new hosting or their traffic numbers have dropped through the floor because of this type of half-assed broken methodology. Basically, sick of cleaning up other people's messes.

I personally use very many DIV and other elements in the HTML DOM and the HTML5 world I work, and I find your post a little offensive. I also personally cannot imagine getting something brilliant (e.g. cool web app) together without using many tables and DIVs.

Cool Web App. Hahaha... That's a good one.

Though I'm not saying don't use them if you're USING THEM. I'm saying don't add extra ones for NOTHING. If you are using a table for tabular data, GOOD! If you're properly building heading relationships with SCOPE on your TH with a proper caption, GOOD! If you are using a DIV to group tags to apply styling or to avoid pointlessly slapping classes everywhere for no good reason, GOOD!

Meanwhile if you're doing dumbass garbage like this:
<table id="posts">
	<tr>
		<td colspan="3"><h2>Posts</h2></td>
	</tr><tr>
		<td class="heading"><b>Title</b></td>
		<td class="heading"><b>Views</b></td>
		<td class="heading"><b>Replies</b></td>
	</tr><tr>
		<td class="left">Something</td>
		<td class="number">4</td>
		<td class="number">2</td>
	</tr>
</table>
Do the world a favor and back the devil away from the keyboard until you have enough knowledge of HTML to build a table properly.

For the curious:
<table id="posts">
	<caption>Posts</caption>
	<thead>
		<tr>
			<th scope="col">Title</th>
			<th scope="col">Views</th>
			<th scope="col">Replies</th>
		</tr>
	</thead><tbody>
		<tr>
			<th scope="row">Something</th>
			<td>4</td>
			<td>2</td>
		</tr>
	</tbody>
</table>
Who cares/why does it make a difference?

Ever use JAWS? You know, screen readers? How about data scraping/search engines? Braille reader anyone?

Which of the above code actually says WHAT THE CONTENT IS? If you don't know what the tags are for or how to use them properly, you probably shouldn't be writing markup!

I think you misread or mis-interpreted my last post.

I think I have written enough web apps by now to be able to say this: it is better to use more nested elements (e.g. DIVs) than to use less. It doesn't hurt anyone, and it makes expanding the app more convenient.

Oh yes, we've only been told for years to shrink our DOM use with sites like Google adding excessively large DOM sizes to the things their speed analysis (which is now part of rankings) for slapping down poorly made sites. Google pagespeed will even TELL YOU THAT!

Larger DOM can't possibly have an impact on how long already heavy functions like getElementsByTagName or getElementsByClassName will take, much less the fat bloated slow extra overhead wrappers from garbage like jquery, mootools, or any of the other trash people use to DESTROY perfectly good site concepts.

... and of course more elements on the DOM makes it SO much easier to traverse it to do things with. RIGHT. Is that like how the developers over at turdpress say having 20 classes on every menu LI is 'easier' when none of them are actually useful if you understand the 'cascading' part of CSS?

But then, I'm one of the nutjobs who still sets file-count limits (12 ideal, 24 max for a contentless template), file-size limits (72k contentless template ideal, 144k with content plugged in, that's HTML+CSS+SCRIPTS+IMAGES), bothers actually trying to *SHOCK* deliver content of value to as many people as possible using as acessible a design as possible...

As opposed to what I keep seeing of scam artists and artsy fartsy types preying on the ignorance of the average suit with some flashy but ultimately useless image heavy javascript heavy fixed metric fonts fixed width inaccessible train wreck -- that every day seems to become more and more the norm... seemingly forgetting that people visit websites for the CONTENT, NOT the goofy graphics some 'designer' hung around it or the endless stupid scripting that is in there just to stroke some programmers... uhm... ego.

Funny since we finally have the tools to do things like responsive layout using media queries and lean out designs with CSS3... Separation of presentation from content being easier than ever before resulting in being able to make more accessible designs that leverage caching better, and take less time to develop because you should be writing less code.

There's this oddball noodle doodle idea I keep hearing people say that somehow throwing more code at things makes it EASIER? How the devil is writing more, with more complexity, EASIER?!? From idiotic frameworks, to pointless "gee ain't it neat" scripting that does nothing but get in the users way, it's like a return to the worst of the late '90's.

Which is of course, HTML 5 in a nutshell, at least so far as writing markup is concerned... all the actually cool stuff people CALL HTML 5 is of course either useless without the javascript that you could go ahead and use in older doctypes, or CSS3 which guess what?!? ALSO works in the older doctypes.

Since you take those away and look at HTML 5 as strictly a markup specification, the Emperor is standing bare for all the world to see.

Edited by JasonKnight, 06 April 2013 - 11:39 PM.

  • 0
The only thing about Dreamweaver that can be considered professional grade tools are the people promoting it's use.

#32 RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Expert Member
  • PipPipPipPipPipPipPip
  • 1311 posts
  • Location:C:\Countries\US
  • Programming Language:C, Java, C++, PHP, Python, JavaScript

Posted 07 April 2013 - 12:55 PM

I am not sure we understand each other correctly.
You do not seem to be very fond of HTML5, do you?

For regular web pages (the ones that show content), go ahead and abandon JavaScript, and you can use PHP backend all you want, and make the appearance of the site as simple as you find it necessary to make the content stand out - it would make sense to use captions and headers and those semantics there.

However, HTML5 is - from my understanding - mainly not aimed at just regular pages; it's in no small part targeted at web apps. For an example, take a look at a simple web app I wrote some month or two ago:
> \ncos(x) <>\ntan(x) <<#FFFF00>> \nasin(sin(x))"}">http://wbord.net/new/wave.html#{"wtime":25,"xtime":2,"winMaxY":1.5,"lwidth":2,"lcolor":"black","text":"sin(x) <> \ncos(x) <>\ntan(x) <<#FFFF00>> \nasin(sin(x))"}

You can use the 'view source' and 'expect element' in your browser to check out how many tags I used. That app's task would be nearly impossible without HTML5's CANVAS, so HTML5 is good for web apps.

And what about offline usage? Without HTML5's manifest specification, web apps wouldn't be able to run without an internet connection - what good is that, especially in Australia or Canada (as you mentioned)? HTML5 is really not as bad as you describe.

How about all the other HTML5 good stuff, like GPS and accelerometer and local storage? Local storage, in particular, serves a very significant purpose in reducing bandwidth because with it web apps can save data to (somewhat) non-volatile variables to access later - if not for such HTML5 functionality, web apps would have been exclusively using AJAX to save and retrieve data (not good if you want less bandwidth usage).


In short, HTML5 is a very useful set of functionality [particularly for web apps run by JavaScript]. If you dislike JavaScript and only want to view content rather than running any web apps, that's fine - my apps won't load at all for you in that case. However, the web nowadays has much more use than just the viewing of content.

























EDIT: (A lot of new posts are here now, so I'll just start editing my older posts.)

You are forgetting inline SVG; that uses markup inside of HTML. However, who needs markup when there's script? At least for me, it's more convenient to script things.

Input elements don't need wrapper forms, and besides, that would only add extra elements, which is against your 'don't use too many wrapper tags' idea. It also helps because if I use form, the document might get "submitted" when the user hits 'enter' inside a text input field, and I do not want that.


As for my program, it works in all major browsers I tested it in (Internet Explorer 9, Google Chrome, Mozilla Firefox, Opera, and Safari). My former mathematics instructor even tried it on his android phone, and it didn't work very fast, but it worked.

HTML5 is meant for expanding scripts' abilities, by the way. And again, the web consists of more than just content pages - I believe the existence of web apps is a different topic from what you're talking about in your definition of the meanings of the different tags.

Edited by RhetoricalRuvim, 08 April 2013 - 11:11 AM.

  • 0
Regards,
RR

#33 JasonKnight

JasonKnight

    CC Addict

  • Senior Member
  • PipPipPipPipPip
  • 312 posts
  • Location:Keene, NH
  • Programming Language:C, C++, JavaScript, Delphi/Object Pascal, Pascal, Assembly, Others

Posted 07 April 2013 - 10:36 PM

Canvas -- useless without JavaScript, so why does it even have a tag?!? I can write a valid XHTML 1.0 doc that uses CANVAS -- It's a scripting element that has no business even being a markup one!

Local storage has nothing to do with writing markup and is purely JavaScript, and can be used JUST FINE in older doctypes -- has absolutely no business even being CALLED HTML 5!

As to running off-line, I still don't get what the difference is between that and saving as a MHT or other archive format is, apart from the fact you hand control over to the site designer to do it and let them push to your computer whatever they think they need to. (Which I suspect is going to end in tears just as it did under ActiveX 15 years ago -- sick of seeing the same mistakes repeated)

In fact apart from CANVAS (and even then), NOTHING you mentioned is in fact HTML / MARKUP!!! I think that's where we're missing each-other is you've fallen for calling all the cool stuff that has nothing to do with a HTML specification or writing markup "HTML 5" -- it's effectively a lie and delusion a LOT of people are falling for and parroting en-masse, turning HTML 5 into a second rate sick buzzword like "Web 2.0" was. Yes, the new scripting and CSS3 are great - But that has exactly what to do with writing markup? Not a blasted thing!

Now, as much as I LIKE the idea of anything of having it so anything that doesn't work with scripting off is generated by JS, methinks you took it a little too far -- you've got inaccessible form (no LABEL, no FOR, no FORM so you're generating invalid markup), your DIV look more like they should be FIELDSET (NOT all screen reader users are sightless), since they DID make canvas a tag there's no reason to put a DIV around it, and you're not leveraging the true advantages of CSS. This is particularly true from your not properly using flow to build the layout and failing to get the resize behavior on canvas quite right.

I'm not entirely certain why you need to relpo a container around CANVAS, though the fixed height of it's parent preventing it from being contained looks broken/silly. Also not helping is it not really being well centered and/or contained by the window -- and no proper resize handler.

Also wondering why you didn't just make that an anonymous function -- and you're doing a lot of the same things over and over again, which is pretty much what functions are for in the first place. (that's really odd). In many ways it's the same as the folks who put the same class on every LI or A inside a perfectly good parent.

Of course that the only browsers it seems to work in here is Opera and IE 10 is odd too -- seems to be dead/nonfunctional in Chrome and Firefox. Wondering if they started blocking the function evals or something. (even stranger is them throwing no js errors) -- though you do have a slight lack of error handling/reporting too.

Trying to pass JSON in the URI also seems a bit like ice-skating uphill, particularly as a hash that doesn't even resolve to a target. Wouldn't getData make a ** of a lot more sense? (But then I'm increasingly soured on JSON just as I'm soured on XML for anything other that website markup)

Creating your 'style' in the JavaScript really limits what you can do for layout, makes re-skinning harder, and is generally more code. You've got no method of handling cross-browser layout issues, no way to handle reformatting for things like responsive layout, etc, etc... I mean have you seen what your applet does on large font/120 dpi systems? How useful is that on a tablet? Handheld?

Even if you are writing a 'web application' you should still be generating semantic markup, practicing separation of presentation from content, and EVEN going so far as to maintain separation of behavior from presentation too. That way you can leverage caching models, add responsive layout, have accessible layout for things like screen readers or mobile apps, etc, etc.

... and that's what I'm talking about. Heading to bed, but when I get up I'll take a stab at a quick rewrite of your little app to show you EXACTLY what I mean. Probably knock a K or two off it while still expanding it's appearance and behavior with responsive accessible layout.

Edited by JasonKnight, 07 April 2013 - 10:37 PM.

  • 0
The only thing about Dreamweaver that can be considered professional grade tools are the people promoting it's use.

#34 JasonKnight

JasonKnight

    CC Addict

  • Senior Member
  • PipPipPipPipPip
  • 312 posts
  • Location:Keene, NH
  • Programming Language:C, C++, JavaScript, Delphi/Object Pascal, Pascal, Assembly, Others

Posted 08 April 2013 - 08:29 PM

EDIT: (A lot of new posts are here now, so I'll just start editing my older posts.)

Wish you wouldn't... confusing as ** to have your responses not in order. (surprised there's no edit limit time here...)

You are forgetting inline SVG; that uses markup inside of HTML.

Or more properly should be embedded from an OBJECT -- NOT that I see any legitimate reason to start using SVG 20 years after it was considered a fat bloated pointless specification, much less 8 years after it's real champion - Adobe, the ONLY company to make a SVG plugin that worked in IE all the way back to 1998 -- dropped it like a hot potato and tried to bury it when they bought out Macromedia. That people even still talk about it is shocking to me.

However, who needs markup when there's script? At least for me, it's more convenient to script things.

Depends on what you're doing... I would never use client side scripting to deliver actual content of value; what with people ACTIVELY blocking javascript with browser plugins and extensions... much less how useful javascript is for people on screen readers, braille readers; or how it might as well not even EXIST for search engines.

Input elements don't need wrapper forms

Uhm, actually they do require them and failing to provide them could result in unpredictable behaviors; it's one of the things that can even send legacy IE into quirks mode even if you include the doctype. Using INPUT without a FORM, and without a block level container inside the FORM and around the INPUT, is invalid broken assed inaccessible HTML! It also screws up trying to get around it with alternative browsing methods.

It's LITERALLY required in XHTML, since there form elements aren't actually part of INLINE.

Really, if you are using INPUT, SELECT, BUTTON or TEXTAREA without a FORM around them, you're just sleazing out HTML any old way instead of building with logical document structure -- No matter how many scripttards tell you otherwise.

Starting to sound like you don't know enough about HTML or websites to be saying anything you've said.

and besides, that would only add extra elements, which is against your 'don't use too many wrapper tags' idea.

They are not extra elements when they provide meaning and semantic structure, aiding in accessibility and functionality. They are only extra elements when they serve no legitimate purpose; actually why your reaction given you only used three DIV, each of them serving a purpose was a bit surprising. Admittedly one is kind-of unneccessary, and two should probably be fieldsets -- but really that's NOT what I was talking about.

It also helps because if I use form, the document might get "submitted" when the user hits 'enter' inside a text input field, and I do not want that.

Either trap onsubmit (I'd consider that for maybe pulling up the export in addition to your button), set action to #, or since your generating on the DOM instead of writing markup, just don't set the ACTION attribute in the first place. (or even better, get some server side code to generate a near identical image from the results for the people who block or don't want scripting!)

As for my program, it works in all major browsers I tested it in (Internet Explorer 9, Google Chrome, Mozilla Firefox, Opera, and Safari). My former mathematics instructor even tried it on his android phone, and it didn't work very fast, but it worked.

Figured out why it was bombing here -- the escaped codes for the JSON were being decoded on link copy, killing the existing data. Plug in the textarea and adjust the default values by hand, it works.

Again, part of why JSON is a REALLY bad way to pass data in a URL, much less doing so passing it via a hash which isn't even what hashes are FOR. We have getdata for a reason -- just as we have encodeURIComponent... If you're gonna try and pass data, use the mechanism for... uhm... passing data.

Though you mentioned an 'instructor' -- that explains a lot. Most "instructors", "professors" or whatever else "educators" want to call themselves, particularly in IT, aren't qualified enough to rank as pastry chefs, much less code their way out of a piss soaked paper bag with a hole in the bottom. There's a reason that by the time you are 30, you'll find any silly pieces of paper you collect to not even be worth a sheet of bog roll... enjoy putting yourself a decade in debt for nothing of value.

HTML5 is meant for expanding scripts' abilities, by the way.

Scripting has nothign to do with writing markup. Two separate specifications and should remain that way. The new tags that are scripting only have no legitimate reason to even exist; Just like the new structural tags are redundant to numbered headings, just like the new form elements destroy accessibility by encouraging false simplicty...

And again, the web consists of more than just content pages - I believe the existence of web apps is a different topic from what you're talking about in your definition of the meanings of the different tags.

You are correct, web apps are a different story from regular websites. I'm talking about WEBSITES. With content of value... which is what most people visit and use and enjoy -- with web crapplets destroying the usability of many content based sites.

SOME web applications are just fine -- your's is actually an example of something that makes SENSE as a web application... and no, you did not overuse containers, IMHO you just chose the wrong ones... I'd have one more just because you can't trust body for scaling, and of course getting the CSS into it's own stylesheet would let a reset be added so it's not getting screwed up by things like Opera's default padding on body, IE's default padding on HTML... though you don't really use enough semantic accessible markup or even proper HTML for many other elements to throw a wobbly.

Webmail does not make sense as a web applet (they're getting less and less useful every day thanks to JS frameworks and scripttards who don't know any better) -- 99% of normal websites do not... but people out there are throwing them at everything like a sick fad, from pissing on accessibility by replicating framesets via tabs+ajax (forgetting why they were deprecated), to just filling pages with stupid animated ** for nothing.

Likewise -- and let's make the distinction -- on CONTENT based websites, people continue to sleaze out broken, outdated, needlessly and pointlessly bloated code. See the sample from the OT of this this thread. You're seeing websites blowing 100k or more markup to do 10k's job, 200k of CSS to do 10k's job, and megabytes of javascript on sites that most likely shouldn't even have ANY.

If this doesn't describe you, I'm not certain why you found it offensive. Sounds like you're making web apps that actually do something useful... methodology could use a bit of tweaking, but how long have you been at this? (guessing about two to four years?)... In fact looking at your code you taught this old dog a couple things.

I'm starting to work your demo into 'my way' of doing things to show you the difference. I've got a bit more robust a canvas resize mechanism I'm going to leverage, it'll have responsive layout so it's useful right down to tiny 192px wide displays, separate out the style to it's own sheet so it's easier to maintain, etc, etc... the real laugh being I'm gonna write it in a validating XHTML 1.0 doctype just to prove how pointlessly stupid calling this stuff "HTML 5" really is.
  • 0
The only thing about Dreamweaver that can be considered professional grade tools are the people promoting it's use.

#35 JasonKnight

JasonKnight

    CC Addict

  • Senior Member
  • PipPipPipPipPip
  • 312 posts
  • Location:Keene, NH
  • Programming Language:C, C++, JavaScript, Delphi/Object Pascal, Pascal, Assembly, Others

Posted 08 April 2013 - 09:50 PM

Ok, here's what I came up with:

http://www.cutcodedo...hetoricalRuvim/

here's a link with test data... built using getdata instead of JSON.

http://www.cutcodedo....html?plots=sin(x) <>
cos(x) <>
tan(x) <<#F80>>
asin(sin(x))&lineColor=#00C&lineWidth=4&waitInterval=25&intervalX=2&windowX=1.5&windowY=0.9

As you can see I go about things a wee bit different. Gave it some real styling, added responsive layout to make it much more useful/usable on mobile (looks great on my 7" tablet). One major difference is it doesn't save/generate image (so no saving), and instead uses line drawing to build the entire graph every frame. This means more math, but it actually runs faster on mobile and changes to the input values are instant and effect the entire graph. I don't center the 'export' dialogue vertically because that's unreliable on small displays with something that should hold a good deal of text... assuming the position:fixed wrapper is even displayed.

As you can see, I'm using escaped getData instead of the hash... and set it in the address bar using window.history.pushState. The default values are all built from arrays are as many of the inputs and ID's.

You'll notice it uses a FORM, two fieldsets, and a DIV for export area... with the CANVAS as a direct child.

... and since JS generated content isn't content, not existing for many search engines and certainly not existing for markup validation, it's still "valid XHTML 1.0 Strict" -- which again is why there's no reason for CANVAS to even exist as a tag apart from targeting it for CSS positioning. You don't even use it as a tag -- you put it on the DOM, but you didn't write <canvas></canvas> in the markup -- and there's a difference!

Big thing though is the responsive layout... try resizing the browser window and watch the canvas resize to fit, and then as it gets narrower stripping off columns and using a different calculation for the canvas size.

Man, this forum SUCKS for trying to post code or URL's. Even with the blasted editor disabled it wants to mangle everything. What was that I was saying about javascript for nothing?

Edited by JasonKnight, 08 April 2013 - 09:55 PM.

  • 0
The only thing about Dreamweaver that can be considered professional grade tools are the people promoting it's use.

#36 RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Expert Member
  • PipPipPipPipPipPipPip
  • 1311 posts
  • Location:C:\Countries\US
  • Programming Language:C, Java, C++, PHP, Python, JavaScript

Posted 08 April 2013 - 10:38 PM

Really nice indeed. And I must admit, I don't even understand all the code behind the page. I did somewhat-quickly read over the code, but I (at least at the moment) have other time-consuming things to do (e.g. homework, essays to write, ...).

I did notice that there's no [right-click + save image as] functionality when the graph scrolling is paused. By the way, the re-sizing functionality is also gone whenever the graph is paused :) .

Also, as for the redrawing the whole graph each frame, my intent was to make the process run faster, so I made the program actually scroll the image data rather than starting all over each time a new frame is rendered.

It did take me less lines of code to write mine (1 file, 234 lines) than what you have (3 files, 517 lines total), but yours does look very much nicer. I'm not as experienced with CSS and with making layouts look elegant.

... but how long have you been at this? (guessing about two to four years?)...

This particular app I wrote about a month or two ago. As for my technological unit utilization practices, here's where I currently am at:
  • first started learning HTML ~5 years ago
  • started learning JavaScript about 4 years ago
  • began doing "cool stuff" (like this app) around a little over a year back
  • Basically, my web app writing practices aren't nearly as elegant (I am not very good at styling, etc.), but my idea is to make use of what I have at hand.

    For example, why not substitute a chair for firewood when a person is freezing and there's no more firewood left?

    Programming is not necessarily quite at the level of life vs death type of survival, but I think there wouldn't be as much innovation if people were restricted to use things only as they were intended and not use them for anything else.


    One of the things with usage (I think you mentioned captions or something) is that I am not expecting users to try to plot things on their e-readers or find such plots using search engines, etc., so the H1 and other usage-specific tags shouldn't be too big of a deal. With some apps, I try to eliminate headers and other space-reducers completely in order to make more room on the page for things like controls, displays, and other useful items as that.


    I'll take a closer look at your code later when I find some time.

Edited by RhetoricalRuvim, 08 April 2013 - 10:39 PM.

  • 0
Regards,
RR





Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download