Surely there is an easier way of doing this. The IE comment tags were the only way I could make the page look right in IE 7 and below.
EDIT: I'm not too sure why this got down-voted. It's a legitimate question. If anyone should get down-voted, it's those who have discussed this as of now. Nobody is answering the question. They are either too vague or telling me what not to do. I already know that. That is why I am asking what the better way is.
You shouldn't need to use an html table just to get IE7 working, and in fact you shouldn't use them at all if you're not intending to display tabular data.
Instead of all those messy conditions, just use one immediately after your stylesheet import to add an IE specific stylesheet.
Consider creating another container for your form, and instead of trying to make the form display as table use positioning to place your new container in the corner instead. This is more likely to translate well into older versions of IE, and so your IE specific styles will only be needed to correct minor box model differences.
Related
I'm trying to extend the VisualEditor by adding custom functionality.
It was pretty easy to add stuff which is realized with a single HTML-tag without parameters. But now I try to add textcolor. I tried to replicate the LanguageAnnotation as that's pretty similar (using span lang=.. while I want span style=color:..).
But it looks like there are a lot more things which I have to change here & I don't understand.
I'd be very grateful for any kind of help here.
Edit: To provide more information: Currently I am trying to replicate the .toDomElements function which I struggle with because I can not find the place where to modify the exact tag syntax (style instead of lang).
Well, I'm not sure if it's the best possible solution, but I've managed this problem by replicating the LanguageAnnotatation, including the widget-system (I chose it because it was the closest one to what I wanted to accomplish as it uses CSS and the span-tag).
I've replicated the following classes, adjusting the attributes (language has lang and dir attributes, my color-annotation only the color attribute):
ve.ce.TextColorAnnotation.js
ve.dm.TextColorAnnotation.js
ve.ui.TextColorContextItem.js
ve.ui.TextColorSearchDialog.js
ve.ui.TextColorInspector.js
ve.ui.TextColorInspectorTool.js
ve.ui.TextColorSearchWidget.js
ve.ui.TextColorInputWidget.js
ve.ui.TextColorResultWidget.js
It works pretty good imo. The only problem I see right now (and which I am working on next) is that with this implementation, text (or background)-color can only be applied to text, but not to tables (only when marking the text inside a cell).
I'm putting together a page, and am really struggling with backgrounds across browsers.
The page uses a number of alpha-blended backgrounds, box shadows and border-radii and it is composited almost entirely using inline styles (essentially there are few/no CSS classes used).
IE9 is my primary browser, and in it, the page looks great. However, on Chrome (and I'm told Firefox), most of my alpha-blended backgrounds render either not-at-all (transparent), or as solid colors! I'm using Standards Mode with an HTML5 !DOCTYPE declaration, so it's not as though I'm leveraging IE quirks or anything!
Clearly on IE versions before 9, the backgrounds (and other things are problematic). But I'm not concerned with supporting ancient software, and those users get a browsing experience that they deserve.
The common refrain for years has been that "transparency on IE sucks!", so I was comfortable in expecting that if I got it to work adequately on IE (typically the worst platform), then the others would just fall in line, but here I am struggling in the opposite direction! I'm using the standard "rgba(r,g,b,a);" directive on the "background-Color" attribute so I'm not using any radical DirectX filters or other magic, nevertheless, on (NOT Internet Explorer 9+) browsers, I'm getting some non-alpha-blended results (sometimes it works, sometimes it doesn't).
The site can be previewed at: https://net-xpert.com/ -- All of the pull-down menus are supposed to have translucent backgrounds, and so too the hovering link-bar at the bottom of the page. Also if you go to the "Ask us a Question" page, the dialog there should have tinted backgrounds on all of the input fields...
Oh, lastly, I am ENTIRELY LOATHE to implement ANY b/s, browser/platform-specific, 'experimental' style-codes! Anything in CSS2/3 is fine, but I simply REFUSE to use any kind of "-browser-some-quirky-CSSAttribute" styles! (I wish more developers would do this too! -- then browser manufacturers would be under greater pressure to adopt these STANDARDS and our lives would be SO MUCH EASIER, but I digress...)
Anyway, any insight on a standards-compliant solution would be greatly appreciated (even if it's just a communal acknowledgement that "ya, Chrome et al is currently not implementing this correctly...", at least then I'll know there's nothing to be done about it...)
Thanks!
Well, this is a very late answer, but maybe this'll still be of use to you (your site still seems to be up and running).
I have a should-work-for-you solution, assuming that you can modify one of your stylesheets. As to WHY you've encountered this problem ..? I can only speculate, because I don't know how to recreate your exact configuration.
The fix;
div[id^=mainMenuOverDiv] {
background-color: rgba(128,128,128,0.9) !important;
}
I'm not a fan of using !important unecessarily, and you may be able to remove that by using greater specificity. I've tested this in Firefox, though and it seems to work - obviously, you'll want to substitute the actual rgba(x,x,x,x) values with your own.
You seem to be using some JavaScript (I'm assuming) which randomizes the DIV ID every time you hover over the menu - but the beginning remains consistent (i.e. one time it will be #mainMenuOverDivjkhasdfsd89f9f9sdfl3l4l34lfdbvbc, then the next, it'll be #mainMenuOverDivLSDklsdkmlzxncbzmxnc90234xcvassf). Using the 'starts with' CSS selector (as provided in the example), you can still isolate the menu despite this potential spanner in the works.
It's interesting (and probably insightful) that this even works, given that inline CSS usually can't be overridden.
As for why this is happening, one possibility is that some JavaScript generated code is not correctly porting over to the non-IE browsers. Alternatively, if you're using it anywhere, code minification may also break some functionality (and vary between browsers) - many minification plugins need to be tweaked for individual setups to ensure that everything continues to work fine as one size does not necessarily fit all. For example, you might find that on one site you can minify everything except the JavaScript, while on another site, JavaScript is fine, but you can't minify inline CSS, etc. Google Analytics code sometimes falls victim to this.
So to my eye, the issue possibly isn't to do with IE/Chrome/Firefox or Safari - transparency is working fine on all of them - I think it's most likely the way your code is being manipulated or delivered to the browser.
Hope that helps in some way. Let me know if you can't use an external stylesheet and I'll try to find an alternative.
I have some special tags on my blogsite which need to be as simple as possible so that my colleges who don't know anything about HTML can use it. For example
<question>...</question>
and
<answer>...</answer>
and then these are styled in CSS. It's far easier for HTML-idiots than to use the <div class="answer">...</div> format.
I've just found out IE8 is displaying it all wrong while Firefox and Chrome do it right. Is that expected or am I doing something wrong? Do you know of any hack to fix this since there are tons of blogsposts I'll have to manually change otherwise!!
You want to create <question>...</question> etc.
These are not HTML (not even HTML5), and you will struggle to get browsers to understand them reliably.
A quick tip that might help you:
You say you've got it working in all browsers except IE. If so, you might be able to hack IE to get it working as well, using a technique similar to the hacks like HTML5Shiv that are being used to get IE to work with the new HTML5 tags. These use Javascript to create a DOM element with the new tag name, after which IE suddenly starts to recognise that tag as being valid HTML.
It might just work. But be aware that it is a hack, and it only targets IE. And since you're using non-standard tags, you also have no way of knowing what will happen in the future in terms of it breaking browsers, even if they work now. (in fact, I would say the worse case scenario would be if one of the tags you've invented is added to the HTML standard at a later date, because then you'll start getting weird layout glitches as it gets added to the default stylesheet)
If you can get it working that way, then well done. But consider yourself warned that it's not good practice.
What you have actually asked for is not HTML, but XML markup. This is perfectly fine, but shouldn't be put directly into a web page in the way you're hoping.
There are a number of well-documented ways to get raw XML code into a browser.
One option is to use XSL to transform it into valid HTML. Another way would be to load it into a DOM object in Javascript and process it using a script. (this is where the 'X' comes in 'Ajax').
My guess is that a simple XSL transformation would do the trick for you. (In fact, it sounds like your use case might be simple enough that even just basic string replacement might suffice for the same end result). You can get your colleauges to create the code using <whatever> <tags> <they> <want>, and you write a script that parses it and converts it to regular HTML prior to merging it with the rest of the page.
In the long term, this would probably be a far better solution than the hack I've described above.
Hope that helps.
I don't know if this answer fits your needs but imho using custom html tags is basically NOT using HTML. Therefore the absence of compatibilty.
If you need to render data in HTML wouldn't be better using XML + XSLT?
You can find guides on w3schools
You can't add new elements like that. HTML has some fixed elements that browsers understand, but if you add your own, browser don't know what to do with them.
HTML5 has some new elements you can maybe find useful : http://www.w3schools.com/html5/html5_new_elements.asp but this won't work with older browser without some kind of javascript to fix things. For example http://remysharp.com/2009/01/07/html5-enabling-script/
However, if you really want to add new tags, it is possible to do so and then "modify" them via javascript to known tags (actually it's what the html5 enabling script of IE do), but it won't be possible to apply CSS easily to the new tags.
In short, I strongly advise against adding new tags. It's not that hard to understand something like <div class="answer">.
sounds like you want to write XML and convert to HTML using XSLT. This is an old tutorial (includes defining an DTD), but a further web search will garner more results that might suit
here you go fella:
http://net.tutsplus.com/tutorials/html-css-techniques/how-to-make-all-browsers-render-html5-mark-up-correctly-even-ie6/
You need to use createElement :)
The question covers most of it, but I'm trying to present a well articulated argument towards a senior developer who wants to abandon conditional stylesheets altogether (IE6, mobile, etc). Bear in mind we're not actually eliminating IE6, just the stylesheet.
Or am I being crazy and should just accept this?
What is the alternative? CSS hacks?
I have conditional stylesheets for IE7 and IE6. This compartmentalizes fixes for those specific browsers. When making changes, it easily lets you test/fix in standards browsers, test/fix in IE7, then test/fix in IE6. Testing flows more naturally. It doesn't break standards, it's easy, and it's basically free. It makes more sense to explain why you wouldn't use them.
You may want to look into the Yahoo Reset CSS Library. It has eliminated the need for conditional stylesheets on many of the projects I've done.
If you can meet your needs without conditional style sheets, then by all means it's a good idea to have a single style sheet for all browsers. However, if you cannot do this without losing functionality, then a pretty good argument would have to be presented to justify going to a single style sheet.
You shouldn't. With enough work, both of the popular browsers can be made to render a page the same way. Take mine for example - Complex yet simple at the same time.
[edit: changed 'never' to 'you shouldn't', having thought the title said 'when']
Because IE 6 and IE 7 are broken in various well known ways. Conditional Stylesheets that modularize the fixes are the easiest and supported way to deal with these breaks.
When you say your senior developer wants to "abandon" conditional stylesheets, what exactly does that mean?
Generally, what's the best way to tackle a layout bug in IE6? What are the most common bugs or problems that one should look for when trying to figure out why your page suddenly looks like a monkey coded it?
First Things First
Get yourself the Internet Explorer Developer Toolbar. It's a life saver and works great with IE6 and/or IE7. It's no replacement for Web Developer Toolbar or Firebug for Firefox, but it's better than nothing.
Know Thy Enemy
Read up on the quirks of IE — particularly hasLayout and overflow and the like. There are also many CSS niceties that you'll have to either do without or find alternatives. Look into how many of the popular JavaScript toolkits/frameworks/libraries get around different issues.
Rome Wasn't Built in a Day
The more you have to work with it, the more you'll remember off hand and won't have to lookup as often. There's just no replacement for experience in this. As several have pointed out, though, there are great resources out there on the net. Position Is Everything is certainly up there.
http://www.positioniseverything.net/ will certainly address your problem.
It provides comprehensive and in-depth descriptions of browser bugs along with options to work around them. A must read, in my opinion,
One good way to start learning about how IE happens to be mangling the page is to turn on red borders on different elements with CSS (border: 1px solid red;). This will immediately tell you whether it's a margin problem or a padding problem, how wide the element really is, etc.
The box model is usually the culprit. Basically what this means is that any div you are trying to position and use unsupported CSS with will cause this problem.
You may find it happens if you are using min-{width,height} or max-{width,height}.
this provides a great reference for checking compadibility with different versions.
http://www.aptana.com/reference/html/api/CSS.index.html
Noticed that Marc's post is at a -2 =D. He's only saying "resort to tables" even though they blow, because in sucky browsers like IE6, some of the broken CSS commands work in tables only (who know's why... dam you Bill Gates!!!). Here's a good reference to see what works and doesn't work as far as CSS goes. http://www.quirksmode.org/css/contents.html . It's a great reference to check on what cool effects work/don't work with various, widely used browsers. Also, always have a go-to plan for users who browse with IE6 (even though it's just about as old as mechanical dirt) as many businesses still use older browsers (including non-profits/3rd world countries etc.) So by all means, create the bugged out drop-down menu that looks WAY better than a standard horizontal menu, but create a secondary one specifically for IE6 that becomes the default when the page receives a request from an IE6 browser.
how do you define layout bug? the most frustrating layout implementation (i don't know if this should be defined as bug) in IE is we need to always specify style="display:inline" in the HTML <form> tag so that a blank line won't appear to disturb the form layout.
This question I believe has far too much scope.
Validate your code, and if pain persists, well, good luck.
The only real solutions, as with any other ballpark bug type are to google for a solution, or ask somebody who knows, ( ie: give the exact problem to us here at stackoverflow ).
You can use the IE Dev toolbar to glean an Idea, but many of the bugs are random, inexplicable, and esoteric. IE: the guillotine bug, the random item duplication bug, etc etc, the list goes on, and you can spend hours literally goofing with stupid variables everywhere and achieve nothing.
I have a simple strategy that works every time.
First, I develop the site using commonly accepted CSS to look good in Safari and Firefox 3. See w3schools.com for details on browser support.
Then, I go into IE6 and IE7 and alter the CSS using conditional includes.
This is hack free and lets you handle different browsers (IE6 and IE7 have separate issues).
Most of the issues you'll find come from unsupported features in IE (like min-width), errors in the box model (IE adds unseen extra padding (3px) to some boxes), or positioning issues. Go for those first as they are often the issue.
A common problem is padding not getting added to the width of a block element. So for layout div's, avoid using padding and instead use elements within them to define the padding.
I use Rafel Lima's Browser Selector when I need to tweak differences between IE/Standards browsers. It greatly reduces using "hacks" in your HTML to solve common problems.
You can target CSS statements for different browsers, or even different versions of browsers (Hello IE 6). It's very simple to implement, but requires the user has JavaScript turned on (most do).
.thing { ....}
.ie .thing { ....}
.ie6 .thing { ....}
We had a floating div issue that was only evident in a particular version of IE6. It was fixed by downloading the latest service pack.
In theory, use CSS compatible with IE6 layout bugs, utilise only well known workarounds (css and html filters) and code for them in a way that wont break forward compatibility, test for quirks/strict mode.
In reality, resort to tables.