Jump to content

COBOLdinosaur

Members
  • Content Count

    175
  • Joined

  • Last visited

Everything posted by COBOLdinosaur

  1. The page has validation errors and is bloated with excessive scripting. It is likely the change is cause by sme scripting referring to the referral values or that the server side scripting is referencing it. Trying to fix a page full of errors generally needs to start with the elimination of the errors, otherwise most of the effort is wasted, and the underlying instability may cause additional problems.
  2. The validation error on the input may have something to do with it. However the rel problem is trying to use Dreamweaver design view and expecting it to render like a browser. If you want to see what something is going to look like in a browser, then the only reliable way to do it is by looking at it in a browser; actually a selection of browsers to cover those you are going to support is the only way to test rendering and know how it is going to present. Your first step in any testing should be to put the markup through the validator (takes less than 10 seconds) because it is not logica
  3. You might want to re-think putting in a lot of styling that you are not using. There is no way for the parsers to kinow what will actually be used by the page so they must parse and serialize all declarations and properties. That will add a small additional time to the page load and make the display slightly less responsive because the re-paint cycles take longer and you end up with fewer paint cycles per second because the rendering engine has to work with a larger amount of data then is actually needed. The degradation is not big unless you create a really big mess, but from a maintena
  4. The first thing you need to do is make sure the image can actually be found by the CSS parser. The url you are using might need a path depending on the location of the image file in relationship to the location of the page file, and the css file.
  5. Hmmm.... there seems to be a communication problem here. CSS is worthless to you if the HTML is not correct. The code you posted does not come anywhere near being valid and until you have correct HTML you cannot expect any consistent performance of either layout or presentation. So let me see if I can make this clear. YOU WILL NOT GET ANYTHING TO WORK RELIABLY IN HTML OR CSS UNTIL YOU FIX YOUR ERRORS
  6. The browser cannot process BBcodes. On the server there is scripting to convert the BBcodes to HTML. BBCodes are used, because allowing HTML codes in postings is a security risk. For some very primitive implementations of BBcode to HTML it is possible to use javascript to do the replacement and then re-write the page, but that is pretty much worthless because the post needs to go to the server to be saved; and very few developers would accept the text containing HTML without stripping it and sanitizing the post before it is sent to the DB.
  7. Without seeing the code or a link to the page, I can only guess that you have conflicts coming from inappropriate combinations of properties that impact positioning.
  8. You're right, which can make it strange if you don't set the position; get real weird in a mobile friendly design using media queries.
  9. That would be counter to the nature of the unit of measure. if you need to modify the the value thenyou need to use the CSS calc() to adjusted. however the value has to be a literal as there is no support for variables in calc(). So you could use height:calc(100vh - 50px); or whatever value you need the bugs that plagued both IE and Chrome for that kind of format seem to be resolved. As for the other two issues it might simply be that the browser is choking on: .pageWrap { margin: 10rem 0 0 0; width: 100%; height: 100vh; overflow: auto; position: fixed; } which does not seem to mak
  10. Of course. Why would that not be the case. You will also see top results for pages with no doctype, misspelled titles, no keywords, broken layouts, hundreds of validation errors, and duplicate content. They are all there because because they have enough content of value to be well placed in the index. They are also likely to have been around for a while, be in a specialize niche, carry Google ads, by ads from Google, or are cross-domain login partners. All of which add to Google juice. I'm only going to give you a single reference where I'm sure you will be impressed by the example and t
  11. Hmmm. at what point do we teach children the right way to cross a street; is it ever alright to just let them learn without guidance. when someone care enough about what they are doing to post in a forum for help with it, then they deserve enough respect to receive an honest response whether it is positive or negative. With modern browsers and the range of CSS presentation options available then is no menu presentation or effect that cannot be presented in a nav wrapper. If we are going to go to the silly approach of multi-level drop downs it is irrelevant and ul or nav does not matter bec
  12. I would just use a nav for each link list within a div wrapper to cascade the styling I want to use. <div class="menu"> <nav> <h2> Cat1 </h2> <a etc...> <a etc...> </nav> <nav> <h2> Cat2 </h2> <a etc...> <a etc...> </nav> </div>
  13. While <ul> <li> <a> ... etc. is at least clear on semantics it is a list and if the list contains links I guess they can be treated a item. However <nav> <ul> <li> <a>... etc does not make semantic sense because it says this is a list of navigation link; no wait it is a list of items! So it is wrong. BTW concerning the reputable sites. I am a member of the communities for three of them and the support for list inside of nav is split in those communities.. I was going to let it pass, but if I have to justify pointing out t
  14. If the amount of data is small enough that downloading all of it does not cause a noticeable reduction in load time, then I would just download it all. 99.9% of the time AJAX methods are fast enough to result in no serious lag, however the other .1% can result from the user having a poor connect, the load on the server is at a stress level, the user is running something else which can slow down javascript, or the user has a heavy download going on in background.
  15. The action on the form need to be the url of the target page which is where the script should be inside the container element that you want to hold the data.
  16. Post a link to the page. Post your code. Provide some detail. Those are all possible starting points. Unfortunately we have not been able to master telepathy to the point where we can read minds across the internet.
  17. Hacking the page by overwriting after it is loaded will work, but you need to understand that you will be making the page worse for future maintenance, reliability, and efficiency. If you you have the url to the script you should be able to download it. though if the jquery is minified it might be a little difficult to do anything with it. Even if you cannot directly download it, it should be in your cache. If you have the coding skills to fix it, then you might want to consider getting rid of the script and writing your own. Anything that is so restrictive that you cannot do simple chang
  18. I assume by "dropdown" you are talking about a select, and not a datalist which behaves quite differently and not the save across all browsers. Instead of sending the value of the option, you need to send the text of the option. The easiest way is probably to add a hidden input <input type="hidden" id='selVal" name="selVal"> then in the scripting: SEL=document.getElementById('Idofselect'); target=document.getElementById('selVal'); target.value=SEL.options[sEL.selectedIndex].text; You can trigger the code as part of whatever client side validation you are doing, or just a
  19. Let's start with this CSS rule : div#container {background-color:rgb(106,183,239); color:rgb(0,0,0); float:left; border:1px solid black; padding:0%; margin:0% 10% 1% 8%; width:83%; border-radius:25px; width is 83% plus right margin 10% and left margin 8%. That is 101%. Not only is it already too wide, it has no slack and when you specify in percentages, you can run into problems is there is no slack because the percentage has to be converted to pixels which cannot be fractional so when the browser rounds up you get broken lay out. What is even more curios is floating an elemen
  20. Really nav h2:nth-of-type() is no longer valid ... see this page as for the list of "reputable sources"... reputation has nothing to do with it. None of them is the authoritative site for setting the standards. If we go back far enough we can probably find "reputable sources" advocating all kinds of things like table layouts, framesets, activeX, and transitional doctypes; all quite legitimately, and with the best of intentions. However web sites present content to attract users and sell adds not set the standards. The only research I have done is the effect on SEO. When I changed a
  21. I'm not sure what you think you need for documentation. Most of the values are not named colors. The standard color pickers list the named values. In the full rgb range there are over 16 million colors, and I guarantee you that no one is going to try and give them all names. The important thing with the numbers is not so much the colors they produce, but the calculations to determine contrast between foreground and back ground. After you look at the color pickers on w3schools and other sources you might find the approach to producing good contrast in this article written by a colorbl
  22. IE and Chrome do not calculate 100% the same way because they treat the space for scrollbars differently. You could try using 100vw for the width instead of the percentage and that might work, but trying to get multiple browser to render the same when you are using 100% of the available canvas in either dimension is always a challenge and they never look 100% the same. A small margin might give you your best shot at getting the rendering close.
  23. The nav can contain most other elements which makes it possible to apply a heading, p, or span to label them; unlike ul and ol which cannot contain anything except li elements. So if you want to label a list you have to either do it externally or use the semantically questionable technique of using the first item in the list to define the content of the list. As for the structure posted what is wrong with: <nav> <h2>Area 1</h2> <a href="#">Link</a> <a href="#">Link</a> <a href="#">Link</a> <h2>Area 2</h2>
  24. Actually the definition in the specification defines it pretty narrowly: "The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases, and no nav element is necessary for those links." The fact that neither w3c
  25. Try that with a screen reader, and tell me it makes sense.
×
×
  • Create New...