We Keep Coding

Determine what javascript is overwriting option text on load

Chrome has a feature as did firebug before it went defunct to break on an element's changes. Chrome however, only breaks on 3 types of changes and Firebug no longer works on new versions of Firefox and the tool to replace doesn't have the ability to break on changes to an element.
I have tried all three break on events for chrome and none enter the debugger. I have a select list like:
<select id="someid">
<option value="">Choose</option>
<option value="12"> Some Text with bad formatting and <span>in it for some reason</span>
<option value="13"> Other text with <span>etc</span> in it</option>
</select>
What I have found happens is that some JS on load will replace all the bad option text with valid html after load. Why does magento2 do this? I don't know. But it makes it a pain for me and is likely tied to a core feature as the spans have ids to products and more in it.
I append text to the options but it gets removed by this other replace procedure. I ended up writing setTimeout to check every 1000ms if the newer option text is there, and add my changes. But it's not a good fix it's a work around that is prone to break for a multitude of reasons, and slow besides.
My question is, in this gigantic huge program of software I never wrote how can I easily find what arbitrary javascript is changing the option text on load? Chrome won't persist on load, and even if I quickfinger Mcgee it and hit f8 to pause loading just as it starts, then find the element, then set it to break on changes, it doesn't actually break.
So I tried Mutation Observers, but then found out via another stack overflow answer to someone else's question, that you can never have the call stack visible using mutation observers. So now I'm looking at watch(), but I doubt it will solve my issue either?
Why isn't breaking on changes to element or it's children or it's text from JS a default easy to use feature this is a CONSTANT issue in development to find out which chunk of code in thousands and thousands of lines is actually causing a behavior you don't want, or you wish to run other javascript after it runs.

I don't have reputation to comment, but based on what you said:
What I have found happens is that some JS on load will replace all the bad option text with valid html after load. Why does magento2 do this?
i was thinking if magento doesn't have a function to show raw input ? maybe it's the root of your problems...
https://magento.stackexchange.com/questions/569/how-to-escape-output-data

input type=button with and without form tag

I have created lots of buttons for a large number of pages (usually 5-10 in a row at the bottom of each page inside a table cell) using input type="button" name="..." value="..." onclick="some javascript event handler" etc, basically to link to other pages of the same group. All these pages are ultimately linked from an iframe tag on a single page. The buttons are working fine offline on my PC at least. But, now I've suddenly realized that I haven't used any 'form' tag for these buttons.
So my question is, is this 'form' tag really necessary? Will there by any problem after I upload? I would prefer not to add the form tag now to so many pages if it's not really necessary, because that's going to be a real drag. But, I don't want to suffer afterwards either.

No it is not necessary as long as you are not doing any Get/Post and grouping form elements together. They should work completely fine without a form tag.

There are two issues to be concerened with:
Is it valid HTML?
Turns out that it is valid HTML (see Is <input> well formed without a <form>?), so you are on the safe side here.
Will all common browsers accept it?
After googling around I haven't seen any information on problems wih this use of Input tags. That suggests that all common browsers accept this valid HTML (as they should). When developing any website that is accessible to the general public I would always do a manual cross-browser check to discover any abnormalities certain browsers may habe with my site.
Problem is that you most likely won't be able to tell from looking at your server logs whether certain browsers have a problem with your HTML. It may just not work on IE 6 and you would never be able to find unless a disgruntled customer calls up and informs you.
If this is a generally accessible website get some stats on the most commonly used browsers, decide which ones you want to support, and verify that the website is behaving properly on thiee browsers. This is a pain in the ass, but there is no way I know of to get around that. Browsers may not react to valid HTML properly.
As a rule of thumb, Firefox, Chrome, and Safari unsually behave well, and because of auto-updates most people will have a very recent version installed. If the latest version of the browser works I wouldn't be too concerned that users with some older version will have trouble.
The real test is always Internet Explorer. While version 8 and 9 are pretty standards-compliant, IE 7 certainly needs checking. IE 6 is the worst offender for unusual behavior. It was introduced in 2002, but today still 6% of the population use it! Most of this comes from cracked copies of Windows XP in China, but it is also used quite a lot in corporate networks, where OS and browsers are centrally deployed, and administrators have not managed to progress since early 2000.
In conclusion: Your code is unusual but ok, test it manually on the browsers you expect.

javascript detect option tag text indent feature or detect type of browser as a fallback

I have a select drop-down that is supposed to represent the hierarchy of pages in a site.
<select id="parent" name="parent">
<option value="">(none)</option>
<option class="inset0" value="home">home</option>
<option class="inset1" value="aboutpage">aboutpage</option>
<option class="inset2" value="about">about</option>
<option class="inset2" value="staff">staff</option>
<option class="inset1" value="news">news</option>
<option class="inset1" value="products">products</option>
<option class="inset2" value="starter">starter</option>
<option class="inset3" value="nesso">nesso</option>
</select>
The construction is made on the backend and styled using css.
option.inset0 {text-indent:0px;}
option.inset1 {text-indent:10px;}
option.inset2 {text-indent:20px;}
option.inset3 {text-indent:30px;}
option.inset4 {text-indent:40px;}
option.inset5 {text-indent:50px;}
option.inset6 {text-indent:60px;}
This is making options of deeper levels display as indented according to the depth each page is in the site hierarchy. However this styling only works in FireFox, and not in Chrome. I know that styling of controls is largely uneven among browsers and operating systems, so I will not go there. Instead I would like to add "-" characters before the text of each option in order to make the hierarchy visible. I only need to do this for Chrome, since I am not supporting IE at all in this project.
The manipulation of the object's text will be done in javascript.
My question is this:
Knowing that browser detection is not recommended and feature detection is favored instead, how can I perform a feature detection for this browser behavior? If this is not possible, is there a quick test that will allow me to know if I'm in Chrome/webkit or Firefox/Gecko?

I can't imagine how one would feature detect this. I thought maybe the computed style may not be set, however a quick test showed it is.
There is an offical page (http://trac.webkit.org/wiki/DetectingWebKit) about detecting WebKit, but it's 4 years old, and the script simply checks the User Agent string, which is basically the same thing jQuery does for $.browser.webkit.
As for specifically detecting Chrome, it defines window.chrome (I can't find an official documentation, but see Safe feature-based way for detecting Google Chrome with Javascript?), but I guess the rendering problem will be in all Webkit browsers.

Accessing value of SELECT in Internet Explorer 6

I am looking for simple and short solution of accessing SELECT value on HTML website in Internet Explorers (6 and 7).
HTML
<select id="s1">
<option>Option1</option>
</select>
JS:
document.getElementById("s1").options[document.getElementById("s1").selectedIndex].value
Above code do not work. I get empty strings.
I found one solution - I would have to make every option look like this:
<option value="Option1">Option1</option>
That works but my website mostly cosist of forms, so such operation increase its size by 50-70%.
Do you know any other ways ?
PS. I've read that I should use "text" instead of "value", but I am not sure about that. I couldn't find what are the consequences of doing this.

Use,
document.getElementById("s1").options[document.getElementById("s1").selectedIndex].innerHTML;

This is because you don't have a value attribute in your option:
<select id="s1">
<option value="Option1">Option1</option>
</select>
This would give you the correct value back.
Newer browsers send the option text instead of the missing value attribute.
As for your question as to what to use, the proper semantic way would be to use value attribute. What if your display text is different than value? Would you change your design again?
If page size is a concern, try removing whitespace or gzipping content instead of breaking the semantics. Note that some older IE6 versions (IE6 with SP3 is fine I guess) may not play well with GZipped content.

iframe shimming or ie6 (and below) select z-index bug

Uhm I'm not sure if anyone has encountered this problem
a brief description is on IE6 any <select> objects get displayed over any other item, even div's... meaning if you have a fancy javascript effect that displays a div that's supposed to be on top of everything (e.g: lightbox, multibox etc..) onclick of a certain element and that div overlaps a <select> your div get's to be displayed as if it's under the <select> [on this case a max and minimum z-index doesn't work ]
I've tried googling and found the iframe shim solution
but I wanted some pretty clean alternatives
or better yet has anyone found a better solution?
since the method using iframes uses around 130mb of ram might slow down poor people's machines

You don't have to hide every select using a loop. All you need is a CSS rule like:
* html .hideSelects select { visibility: hidden; }
And the following JavaScript:
//hide:
document.body.className +=' hideSelects'
//show:
document.body.className = document.body.className.replace(' hideSelects', '');
(Or, you can use your favourite addClass / removeClass implementation).

There is a plugin for jquery called bgiframe that makes the iframe method quite easy to implement.
Personally, as a web developer, I'm to the point where I no longer care about the user experience in IE6. I'll make it render as close to "correct" as possible, and make sure it's functional, but as far as speed goes, too bad. They can upgrade. IE7 (though still quite slow, compared to every other browser) has been out for 2 years (almost to the day!). IE8 is going to be out shortly. Firefox is available for every platform. Safari is also an option (and super fast). Opera is available for most/every platform.
IE6 was released in over 7 years ago. IMHO, there is no reason to still be using it, other than lazy users and incompetent IT departments (or if you're a web developer).

in case anyone is interested, here's some IE shimming code.
* html .shimmed {
_azimuth: expression(
this.shimmed = this.shimmed || 'shimmed:'+this.insertAdjacentHTML('beforeBegin','<iframe style="filter:progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0);position:absolute;top:0px;left:0px;width:100%;height:100%" frameBorder=0 scrolling=no src="javascript:false;document.write('+"''"+');"></iframe>'),
'inherit');
}
ref: this gist by subtleGradient and this post by Zach Leatherman

Prior to IE7 the drop down list was a "windowed" control meaning that it was rendered as a control directly by Windows rather than the browser synthesizing it. As such, it wasn't possible for it to support z-indexing against other synthesized controls.
In order to appear over a DDL, you must use another windowed control, like IFRAME. You can also use a little known IE-only feature called window.createPopup() which essentially makes a chromeless popup. It has limitations, like unstoppable click-out, but they are actually kinda helpful if you are building a hover menu system.

The simplest and most elegant solution to that annoying IE bug is found at: http://docs.jquery.com/Plugins/bgiframe using jQuery.
I reached that conclusion after trying for 2 days to make it work with WebSphere Portal / Portal Applications where everything is dynamic, including the fly-over menu.

There's also the activex method, which I'm starting to explore. It requires creating conditional code to use an activex control instead of a select box for ie6. There's a demo script showing the technique, which is discussed in more detail here.
Update: it appears that MS Office is required for the active-x control to be on the user's machine. In theory, it might be possible to include that somewhere, somehow, but that's getting a lot messier.

I know many people suggested their own tips, but in my case, I just simply hide select using jquery like the below.
$(':date').dateinput({
format: 'dd/mm/yyyy',
onBeforeShow: function(event) {
$('select').hide();
},
onHide: function(event) {
$('select').show();
}
});