Jump to content

COBOLdinosaur

Members
  • Posts

    175
  • Joined

  • Last visited

About COBOLdinosaur

  • Birthday 02/20/1945

Previous Fields

  • Languages
    php, html, css, javascript, sql

Contact Methods

  • Website URL
    http://coboldinosaur.com

Profile Information

  • Location
    Canada
  • Interests
    anything to do with technology, programming, or the web; Stock car racing; searching for Atlantis

COBOLdinosaur's Achievements

Member

Member (2/7)

8

Reputation

  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 logical to expect correct rendering with defective code.
  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 maintenance standpoint you may be creating more work for yourself instead of less when you look at how simple it is to add, remove of change CSS rules.
  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 make sense. the margin means it cannot be 100vh and remain in the window and setting position fixed without setting top, left, right, or bottom, defaults to top:0;left:0; which would force the margin to be outside of the viewport and actually result in the height of the element being being 100vh+10rem; There is an exploration of calc used with vh/vw on my site: http://coboldinosaur.com/pages/css-calc-function.html that might help you dig through the issues.
  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 the source: http://www.w3schools.com/TAgs/tag_nav.asp When W3C upgraded HTML3.2 to HTML4 it took 4 or 5 years to figure it out and there was enough disagreement that W3C had to create the transitional doctype that made things worse. There is no agreement on most of HTML5 among developers, manufacturers ot W3C itself where the gap between traditional W3C methods and the helter skelter WHATWG approach where anything is allowed that Hixie says is okay. Somewhere down the road it might shake out so one of us (or possibly both us) turns out to be right.
  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 because the amount of damage a multi-level drop down does is far more than can be mitigated by semantics. It is the single worse way to do navigation in terms of higher bounce rates, lost ad presentation opportunities, lost opportunities to upsell, reduce page exposure for potential backlinks and a reduced footprint in the SE index. When someone is a novice developer it is not a favor to ignore flaws so they learn bad practices and then need to "unlearn" the bad habits if they decide they want to do the work professionally. If I come across as harsh it is because I care about people struggling to learn what I already know; and I respect them enough to express honest opinions which frequently are not what they want to hear or padded with soft expression to please mods.
  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 that something is wrong then I guess we need to also clear up the "endorsements" as well. The issue and debate have little to do with the semantics as it does with maintenance issues because poorly written CSS declarations will have to be changed so developers do not continue to bloat the code with unnecessary ul and li tags that carry styling that should have been inherited from a wrapper. If you look at the supporters of the nested format they are also the one who use things like #nav ul li a {properties... instead of #nav a{ properties The second works for either format, but the first first format ties presentation to content structure and fails if you don't keep the ul and li tags.
  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.
×
×
  • Create New...