From: Garrett Smith on
Dr J R Stockton wrote:
> In comp.lang.javascript message <hr5m5p$hph$1(a)news.eternal-
> september.org>, Mon, 26 Apr 2010 20:37:27, Garrett Smith
> <dhtmlkitchen(a)gmail.com> posted:
>> Dr J R Stockton wrote:
>>> In comp.lang.javascript message <hr0qk7$205$1(a)news.eternal-
>>> september.org>, Sun, 25 Apr 2010 00:22:44, Garrett Smith
>>> <dhtmlkitchen(a)gmail.com> posted:
>>>
>>>> Can you mention the problem that you think should be addressed here?
>>>> Is
>>>> it whitespace? What are you getting at?
>>> I did. Using MS IE, go to

[...]

>> I am unfamiliar with the term "design width". What is that?

[about Queen's English, etc]

[...]

>>> Now repeat exactly with a reputable browser; note that whitespace is now
>>> rendered as one would evidently wish.
>>>
>> Can provide a short summary, followed by a brief description and an
>> example. Tell us what you thought the expected outcome should be and
>> then show what really happened, and in which browsers and versions.
>>
>> I have no idea what you are expecting
>
>
> You were told that in the article which introduced the matter to this
> thread, "Date: 22 April 2010 14:24:45".
>
I see a thread from you on that date under the same thread. I don't know
about your local time zone, or if what you wrote is local time.

Sorry, I don't see the problem. Looks like that thread points back to
your Reso1D function which I replied with: "Ok but what's that got to do
with this entry?"
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on
Dr J R Stockton wrote:
> In comp.lang.javascript message <hrgeuf$ac2$1(a)news.eternal-
> september.org>, Fri, 30 Apr 2010 22:41:32, Garrett Smith
> <dhtmlkitchen(a)gmail.com> posted:
>> Dr J R Stockton wrote:
> [GS:]

[...]

> ISTM that, where the element is a PRE, and the assigned string contains
> whitespace, then for IE8 each block of whitespace is treated as a single
> space, and for other browsers the whitespace is happily preserved.
>
> That may be worth mentioning.
>

IE has never handled whitespace properly with innerHTML, and it is not
just for PRE that matters. If the element is a DIV, the whitespace
should also be preserved so that when it is changed to, say, have
`div.style.whiteSpace = "pre"`, that the white space is then displayed
as expected.

It is worth mentioning. Linking to the innerHTML section for HTML 5
working draft sounds also worthwhile, if mentioned as a draft.

I'll provide a proposal later.

Thanks for reposting.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on
Garrett Smith wrote:
> Dr J R Stockton wrote:
>> In comp.lang.javascript message <hrgeuf$ac2$1(a)news.eternal-
>> september.org>, Fri, 30 Apr 2010 22:41:32, Garrett Smith
>> <dhtmlkitchen(a)gmail.com> posted:
>>> Dr J R Stockton wrote:

[...]

> I'll provide a proposal later.

| How do I modify the content of the current page?
|
| Using the non-standard but widely implemented `innerHTML` property:
| <div id="anID">Some Content</div> with script:
|
| document.getElementById("anID").innerHTML =
| "Some <em>new</em> Content";
|
| Where "anID" is the (unique on the HTML page) id attribute value of
| the element to modify.
|
| All versions of Internet Explorer exhibit problems with `innerHTML`,
| including:
|
| * Fails with FRAMESET, HEAD, HTML, STYLE, SELECT, OBJECT, and all
| TABLE-related elements.
| * Replaces consecutive whitespace characters with a single space.
| * Changes attribute values and order of appearance.
| * Removes quotations around attribute values.
|
| If the new content is only text and does not need to replace existing
| HTML, it is more efficient to modify the data property of a text node.
|
| document.getElementById("anID").firstChild.data = "Some new Text";
|
| Compatibility Note: Implementations have been known to split long text
| content among several adjacent text nodes, so replacing the data of
| the
| first text node may not replace all the element's text. The normalize
| method, where supported, will combine adjacent text nodes.
|
| Note: Make sure the element exists in the document (has been parsed)
| before trying to reference it.
|
| * http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-FF21A306
| * http://msdn.microsoft.com/en-us/library/cc304097%28VS.85%29.aspx
| * http://msdn.microsoft.com/en-us/library/ms533897%28VS.85%29.aspx
| * http://developer.mozilla.org/en/Whitespace_in_the_DOM
| * http://developer.mozilla.org/en/docs/DOM:element.innerHTML
| * Draft Standard:
|
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#html-fragment-serialization-algorithm
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on
Dr J R Stockton wrote:
> In comp.lang.javascript message <hrqto9$dv5$1(a)news.eternal-
> september.org>, Tue, 4 May 2010 21:55:34, Garrett Smith
> <dhtmlkitchen(a)gmail.com> posted:
>> Garrett Smith wrote:
>>> Dr J R Stockton wrote:
>>>> In comp.lang.javascript message <hrgeuf$ac2$1(a)news.eternal-
>>>> september.org>, Fri, 30 Apr 2010 22:41:32, Garrett Smith
>>>> <dhtmlkitchen(a)gmail.com> posted:
>>>>> Dr J R Stockton wrote:
>> [...]
>>
>>> I'll provide a proposal later.
>> | How do I modify the content of the current page?
>> |
>> | Using the non-standard but widely implemented `innerHTML` property:
>> | <div id="anID">Some Content</div> with script:
>> |
>> | document.getElementById("anID").innerHTML =
>> | "Some <em>new</em> Content";
>> |
>> | Where "anID" is the (unique on the HTML page) id attribute value of
>> | the element to modify.
>
>
> It would be better to have an earlier FAQ section on the various ways of
> obtaining a reference to an element, and to put instead of that
>
> reference.innerHTML = "Some <em>new</em> Content";
>
> Commonly, though, an ID is used. The above code should not be used
> multiple times, but should be made a function :
>
> function Wryt(ID, S) { document.getElementById(ID).innerHTML = S }
>

I fail to see how that should be a rule. In fact, it is often a bad
idea to exit an execution context amid multiple DOM updates as it
triggers costly (and sometimes ugly) re-flows.

Context, context, context. There are very few absolute rules in this
business. This underscores the need to avoid scripts by authors who
think that theirs is the only "right" way (e.g. Resig's ridiculous
stance that CSS height/width is "better" than the values contained in
height/width attributes) as they paint you into corners.
From: David Mark on
Dr J R Stockton wrote:
> In comp.lang.javascript message <hrvu7q$7cr$1(a)news.eternal-
> september.org>, Thu, 6 May 2010 22:29:11, David Mark
> <dmark.cinsoft(a)gmail.com> posted:
>
>
>>> The above code should not be used
>>> multiple times, but should be made a function :
>>>
>>> function Wryt(ID, S) { document.getElementById(ID).innerHTML = S }
>>>
>> I fail to see how that should be a rule. In fact, it is often a bad
>> idea to exit an execution context amid multiple DOM updates as it
>> triggers costly (and sometimes ugly) re-flows.
>
> Kindle explain how replacing something like
>
> document.getElementById("A").innerHTML = S1
> ...
> document.getElementById("B").innerHTML = S2
> ...
> document.getElementBy1d("C").innerHTML = S3
> ...
> document.getElementById("D").innerHTML = S4
> ...
> document.getElementById("E").innerHTML = S5
>
> with something like
>
> Wryt("A", S1)
> ...
> Wryt("B", S2)
> ...
> Wryt("C", S3)
> ...
> Wryt("D", S4)
> ...
> Wryt("E", S5)
>
> add reflow costs.

Like I said. Browsers re-flow on exiting execution contexts. The
second set allows for up to five re-flows. The first set allows for
none. Re-flows are often expensive (not to mention ugly), so should be
minimized.

> It aids clarity, and reduces the chance of the sort
> of typo that may not have been noticed above.

Personally, I don't see how a function called "wryt" adds clarity. :)

Encapsulation of common logic in functions is generally a good idea, but
like many things in JS/browser scripting, there are caveats that don't
exist in other languages/environments.

>
> If, as must often be the case, S1 replaces text of the same length,
> there will be no reflow;

Text? Who said the content was text only?

> if of similar length, often no more than a line
> reflow.

I don't know what that means. A re-flow is a re-flow. That single
"line" pushes the content below it down. And the point is that you
don't normally want to see flickery partial results.

> And in any case, current machines are so fast that reflow, if
> required, will usually take negligible time.
>

That's silly. For one, not everyone has a "current machine" and for
two, mobile browsers are all the rage (i.e. an iPhone should be
considered a "current machine"). So what are you saying?

Stick to the math, doc.