Jump to content

JS Special Text


shreyaskudav

Recommended Posts

There's really no reason to use a backspace character. Tabs are used more often in other languages than Javascript, since HTML ignores whitespace. The \r character is used by Macs to denote a line ending. I've never had a use for \f.

Link to comment
Share on other sites

If by "skip" you mean not learn then you shouldn't skip them. You need to know what they're for.Those characters are used when printing strings.The following code:

alert("Line 1\nLine 2");

would show:"Line 1Line 2"Besides that, you shouldn't have to think too hard about them.

Link to comment
Share on other sites

I tried posting before, but my ##### Internet connection was throwing fits. So I'll try again.All the characters you mentioned are called "whitespace" characters.HTML treats all whitespace characters the same when they occur as part of a text node. If there is one whitespace char, it is rendered as one empty (horizontal) space. Multiple whitespace chars are also rendered as one space. It does not matter if the whitespace character is a linebreak or a tab or anything else. They are all treated the same. A string that contains "\n" in an HTML context behaves just the same as if you were typing HTML and hit the return/enter key. If you hit the return/enter key 100 times in the middle of an HTML document, you would not expect to see a huge vertical gap representing 100 linebreaks. The same rule applies if you add 100 "\n" characters to an HTML text node. It's almost like they don't exist.The normal rules of HTML always apply. If you want vertical or horizontal space, use margins or padding. (Or, yes, the <br> element, if :) you have no imagination, in which case you should try a different occupation.)Whitespace characters WILL appear as expected in textareas, alerts, <pre> elements, and elements whose CSS formats them to look like <pre> elements. That is the point of those kinds of elements. (For the time being, though, vertical tabs and bell characters do squat.)Remember that escaped characters (like we've been discussing) existed long before HTML, and their existence in JavaScript reflects that heritage. For the most part, they are ugly step children, not useful for very much. When I find myself using them in a browsing context (rarely) it is because I have sent formatted text from my server that needs to be reformatted somehow. (Even there, I tend to reformat it on the server before it ever hits the browser.)Bottom line: this stuff just doesn't come up that much. (But you are correct! A good programmer must know about it.)EDIT: The big exception (kind of) is when you use these characters as part of a regular expression. I say kind of, because you would only every need to do that with text that comes raw from your server, or from a textarea.

Link to comment
Share on other sites

I tried posting before, but my ##### Internet connection was throwing fits. So I'll try again.
you didn't sing it a lullaby before you logged off ? :)
Bottom line: this stuff just doesn't come up that much. (But you are correct! A good programmer must know about it.)EDIT: The big exception (kind of) is when you use these characters as part of a regular expression. I say kind of, because you would only every need to do that with text that comes raw from your server, or from a textarea.
i find i use '\n' quite a bit, does that make '\r' redundant ?since '\n' pretty much is the equivalent of <br />
Link to comment
Share on other sites

Brief history lesson.Before there were visual displays, you communicated with a computer using a thing like a telegraph. To get the thing to start a new line, you needed to send a sequence of 2 characters: carriage return plus line feed. The first realigned the typing head with the left side of the page. The line feed rolled the page up to the next line. So the CRLF (\r\n) combination became the standard way of indicating all line breaks. A lot of older protocols continue to use this pattern even though it is no longer necessary. In some cases, changing the protocols would be a lot more work than just leaving them alone. (At least, I've always assumed so.)If you just need a line break to make HTML or any other file more readable (or to separate data records) a simple \n works just fine.If you ever have to read someone else's data file and you get unexpected line breaks or invisible characters, you may need to search for \r characters.

Link to comment
Share on other sites

Brief history lesson.Before there were visual displays, you communicated with a computer using a thing like a telegraph. To get the thing to start a new line, you needed to send a sequence of 2 characters: carriage return plus line feed. The first realigned the typing head with the left side of the page. The line feed rolled the page up to the next line. So the CRLF (\r\n) combination became the standard way of indicating all line breaks. A lot of older protocols continue to use this pattern even though it is no longer necessary. In some cases, changing the protocols would be a lot more work than just leaving them alone. (At least, I've always assumed so.)If you just need a line break to make HTML or any other file more readable (or to separate data records) a simple \n works just fine.If you ever have to read someone else's data file and you get unexpected line breaks or invisible characters, you may need to search for \r characters.
don't take this the wrong way, but with posts like this, you remind me more and more of Uncle Bob :)edit: I guess you would have had to read some of his books to understand the reference, perhaps.
Link to comment
Share on other sites

##CUT##If you ever have to read someone else's data file and you get unexpected line breaks or invisible characters, you may need to search for \r characters.
yeah, learned that the hard way when i couldn't figure out why the strlen() of a $word kept returning +2 from what was expected.had to loop through each character and ord() it before i got it !then i learned about rtrim() !!
don't take this the wrong way, but with posts like this, you remind me more and more of Uncle Bob :)edit: I guess you would have had to read some of his books to understand the reference, perhaps.
one could only take it as a compliment !we can know why our languages have evolved based on words for concepts that don't exist anymore in the "modern" world.i can imagine years from now when all video-camera work is digital, people will still ask "is the tape rolling".
Link to comment
Share on other sites

I do think it's important to know a bit of the history behind things, yeah. Switching examples, web development has changed so dramatically in almost 20 years that knowing some background explains a lot of seeming weirdness. We still see young developers copy/pasting code that looks like this:if (document.layers) { // etc.A bit of browser-war history explains why code like that existed, why it no longer works, and why it would be a bad idea to use it (for browser sniffing) even if it did still work.Or how many times do you catch yourself explaining to someone, "That element was deprecated in HTML 4, and doesn't exist in HTML 5"? Knowing the thinking that went behind that process helps you explain to someone why, for example, <center> tags should be abandoned.

Link to comment
Share on other sites

I do think it's important to know a bit of the history behind things, yeah. ..
yep, as they say, those who don't know history, are condemned to repeat it.
Or how many times do you catch yourself explaining to someone, "That element was deprecated in HTML 4, and doesn't exist in HTML 5"? Knowing the thinking that went behind that process helps you explain to someone why, for example, <center> tags should be abandoned.
i can attest to that, having dabbled with HTML pre-CSS, i was already so used to <p align="center">, not to mention valign attribs, and kept ignoring CSS thinking it was "too advanced" for whatever simple pages i wanted to make.now, having a better grasp of CSS, it makes so much sense to use it instead of all the old align attribs that i can see why it's deprecated because it's such a 'dinosaur' ! not that i understand how it actually is better, technically, to the HTML parser(?)i suppose there's already an engine(?) that is processing the CSS, so having <center> be parsed as well is redundant and actually superfluous proces - hence the deprecation.
Link to comment
Share on other sites

You're on the right track, ed. But it's even better! There is a philosophy at work now. When you think of a web document, you can break it down into 3 large aspects:structurepresentation (appearance)behaviorHTML handles the structure of the thing. HTML 5 really runs with this idea and gives us a lot of new elements to specifically identify common structures, like <footer> and <article>.CSS handles the presentation: colors, fonts, sizes, positions, and so on. It used to be that HTML itself was a mix of structure and presentation. Now for the most part, they have been separated. (Though friendships have been lost over <b> tags, for example.)Scripting handles most of the behavior. CSS actually does a lot more than it used to. You need JavaScript to make things move (e.g., flyout menus). But you do need JavaScript to make persistent changes to the state of your document and its environment (like cookies). So the basic division still holds true.---The seniors often make explanations with references to those 3 terms. HTML is also discussed in terms of semantics, ie: what a given element type should mean.

Link to comment
Share on other sites

You're on the right track, ed.
thanks, "Dad" xD
But it's even better! There is a philosophy at work now. When you think of a web document, you can break it down into 3 large aspects:structurepresentation (appearance)behavior
i guess behaviour is when the term "DHTML" began ?
...(Though friendships have been lost over <b> tags, for example.)
ooh, do tell !i think they're okay; but i would wouldn't i, seeing as i'm never without using a bold or italic in my posts !! :(i believe it was on the W3shools tutorials where i learned about <strong> & <em> and i think leaving <b> & <i> as valid tags is probably a good idea - it's certainly more effcient than <span style="text-style:bold">text here</span> for something that might occur quite frequently.
The seniors often make explanations with references to those 3 terms. HTML is also discussed in terms of semantics, ie: what a given element type should mean.
well, i'm starting to see containers everywhere IRL now !! :) eg. <house> --> <room> --> <wall> --> <window> --> <frame> --> <slats> --> <pane> --> <stain> --> <colour>i reckon that's how God keeps track, eh ? :P if(nation(greed_index>charity)) {nation.flood=true; nation.famine=(reserves/consumption)} ... :)
Link to comment
Share on other sites

Sometimes DHTML refers to CSS that changes appearance rather than the DOM, like rollover menus, etc. I don't really like that usage. The D stands for "dynamic" and to me that means a content change, not simply animation. So, yeah, that's scripting the DOM.Then again, I think terms like DHTML and Web 2 are a bit precious and dated. People who use them tend to be web beginners or managerial types who only think they're on the cutting edge. Web pages have been dynamic for more than half the time that the web has existed. It's like asking someone, "Do you have color TV?"I'm not picking on you, really. If you want to be a web developer you need to sound like a web developer, right? :)

Link to comment
Share on other sites

...I'm not picking on you, really. If you want to be a web developer you need to sound like a web developer, right? :)
right you are!and please do "pick on me", that's the proper teacher/student dynamic (IMO).i'm a pedant when it comes to simple English and a real spelink Nazi, so i'm prepared (infact, expect) to get the same when it comes to terminology i'm not using correctly.hmm, you do mean "precious" as rare, right ? (and not pretentious ? :) )
Link to comment
Share on other sites

The reason that the advent of CSS is "better" is for the same reason good web developers refrain from writing inline javascript, and include their files in the head. It comes down to a separation of concerns, in so much that you can have all your presentational code in one file, your functionality in another file, and your markup in another file, acting as the anchor. In this way, you don't need access to the markup just to change the background color of a div, and so that you don't need to clutter up a page with inline javascript when you can just use something like addEventListener. This makes for cleaner files and an easier work flow for the current developer, as well as future developers who may need to work on the project, however at that point we get to talking about well named variables/functions, modularity/decoupling/no-dependancies, good comments (although some might argue well written code should read like a book anyway), and so on and so forth.

Link to comment
Share on other sites

The reason that the advent of CSS is "better" is for the same reason good web developers refrain from writing inline javascript, and include their files in the head. It comes down to a separation of concerns, in so much that you can have all your presentational code in one file, your functionality in another file, and your markup in another file, acting as the anchor. In this way, you don't need access to the markup just to change the background color of a div, and so that you don't need to clutter up a page with inline javascript when you can just use something like addEventListener. This makes for cleaner files and an easier work flow for the current developer, as well as future developers who may need to work on the project, however at that point we get to talking about well named variables/functions, modularity/decoupling/no-dependancies, good comments (although some might argue well written code should read like a book anyway), and so on and so forth.
are you in the "NO <b>" camp then ?at the moment, my projects are quite small, and so inline <scripts> are probably "okay", especially since i'm only using simple JS methods - but certainly for clarity's sake, all three sections should be kept separate.definitely if you need to alter the project at some time in the future.
Link to comment
Share on other sites

yes. no inline CSS/JS. it's just a matter of discipline. if you follow your disciplines from the beginning of a project, even if it's a tight deadline. the worst thing you can do is sacrifice your disciplines for a deadline, because then you think, I'll just fix it later. But then you don't, and you just keep on piling on the mess, and so on and so forth, and before you know it, you've got a code "dump". Better to be a day late and a dollar short having it done the right way, then to spend more time and money in the future fixing a bunch of junk code.

Link to comment
Share on other sites

yes. no inline CSS/JS. it's just a matter of discipline. if you follow your disciplines from the beginning of a project, even if it's a tight deadline. the worst thing you can do is sacrifice your disciplines for a deadline, because then you think, I'll just fix it later. But then you don't, and you just keep on piling on the mess, and so on and so forth, and before you know it, you've got a code "dump". Better to be a day late and a dollar short having it done the right way, then to spend more time and money in the future fixing a bunch of junk code.
i'm not referring to particular headings or section titles, etc which would obviously be better with CSS as such styles would be relevant to the element type/class, and a fixed look of the page.i meant with <b> & <i> tags, which are NOT CSS, right ?these would be for individual words in a body of text, and therefore, within reason (infact, more efficient, i would say) to use <b>word</b> rather than <span class="bold">word</span>it's not code that is logic/DOM-relevant, but rather content-relevant, it should be simple enough to change such emphases if for example there is editorial adjustment to be made.
Link to comment
Share on other sites

Well, although it's a tag, it's really just another form of inline styling. That's why we have CSS, so that HTML can focus strictly on structure, and not presentation.edit: if you need to style text, say within a <p> tag, use a <span> and give it a class/id.

Link to comment
Share on other sites

:) I did not mean to stir up the debate about <b> and <i>. In fact, I thought I was warning against such debates.IMO, there's no reason for this board to rehash what has been discussed over and over. If you really want to play, Google it. Just don't expect to resolve it.My apologies to humanity even for mentioning the #### topic.
Link to comment
Share on other sites

It all comes down to using the right tools for the job. You might have a really nice, shiny and new hammer, but if you need to remove a screw it's time to put the hammer down. Also, I miss the blink tag.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...