SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 48 of 48
  1. #26
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Okay, what I'll do is copy over basically what I said in a mail earlier. I was PMed asking if the advice given here was any good... but by then it had kinda gone quite a ways, so I was hesitant to answer here. But someone on the SitePoint staff mentioned other people find threads via google and search and whatnot, and that it probably would be bad to just leave it without mentioning what's going on.

    I used a premade template from the internet and css, which I changed then manually, I liked the images for the menubars and headers and so on, and the lay-out, so I used that as an example.
    That probably expains a lot of it. You'd get the same problems whether it was a template from some site, or a template from any of the popular WYSIWYGs like DreamWeaver or iWeb. Basically: templates always have horrible code, and they are meant for users with little/no knowledge to have something to start with; in order to be flexible for anything weird a user may want, they usually have too much code so that users have more choice.

    The better you get in writing your own HTML/CSS from scratch, the better your markup gets and/or the better you can tweak templates later on.

    I do know it is necessary to change some drastic things in my designing for to next sites that are to come. I currently got 3 little companies wanting me to make a site for them.
    This is good; depending on how much time you have for them, you can learn on these. I learned both by starting out doing exercises from books and seeing code on forums, but also by practicing what I learned on sites for our company. So of course the stuff I did in my first two years makes me cringe. It's supposed to. As one member here likes to say, if code you wrote two years ago doesn't make you vomit, you've stopped learning : )

    I do think that the site(like it is now) is running and looks good, for simple users (in most browsers as I noticed). Therefore I think rewriting the whole thing is a bit harsh.
    As I said, depending on your situation it may not be worth it. However in a few years you'll very likely agree with me about rewriting : )

    Anyway, here goes my (modified) mail:
    First, Maxx's post:
    the javascript he posts, is clearly 15 years old or maybe more:
    Code:
    if (document.getElementById) { // DOM3 = IE5, NS6
    First the code checks for the w3c way to get elements, which today all browsers in popular use can do.
    Big clue there when it's talking about IE5 and Netscape Navigator 6.
    The code then tests for document.layers (some old Nutscrape thing), and finally the ancient document.all (very old IE and also old Opera).

    While some libraries still start out with a check for document.all or not, it's mostly to see if the code is dealing with some of IE's other problems which do persist up to IE8 (like, IE uses attachEvent instead of addEventLoader).
    However changing someone's style from display: none to display: block works everywhere with just the first (w3c) version, so this code he's using he must have plucked out of the Wayback Machine: it's only testing for ancient browsers simply to grab an element.

    Quote Originally Posted by Maxx
    I want to expand the text (in <p>-tag) by clicking on header 1. When I click on header 2, I want to collapse text of header 1 and expand header 2 text.
    For accessibility reasons, requiring that users have a mouse and who can see is also kinda shortsighted (and in some countries illegal, but currently not for some Mom and Pop Interior shop in the Netherlands (edit or Belgium)). These things need to work with keyboard too, meaning you need a focusable element somewhere. Usually we fix this by having an anchor inside the header who doesn't go anywhere.

    ----------------------

    <a href="#first" onClick="shoh('first');">
    Inline Javascript... think of a nun... no, think of the Queen of England, frowning furiously and saying "hmph! We are NOT amused, young man." And disappointment flowing from her in waves. Instead, in today's code we let Javascript find the elements it needs and do whatever it needs to do (by giving the anchors id's or classes or something), so JS doesn't pollute our fine markup.

    The reply:
    Code:
    var me_obj = document.getElementById(me_id);
    var me_height = parseInt(me_obj.style.height);
    me_height = me_height + 5;
    me_obj.style.height = me_height + "px";
    I notice that code repeats this for every single function. Usually that's a big sign that you can write it much more compact. Don't Repeat Yourself, it's called. It's not that it won't work, it's just unweildy to maintain. In later posts of code, the variables were set just once. That's what you strive for.

    Also, as Maxx noted, text isn't the same on every browser or every machine... and people with eyes over age 40 may need to start enlarging it. Which browsers do gladly. Setting height in pixels will work in some browsers some of the time but breaks easily. Another solution would be to, for example, have the text absolutley positioned offscreen and then just set it back to position:static when it's "open". That way, the text will take up whatever room it needs.

    Reply had:
    Code:
    <form id="form1" runat="server">
    Runat="server" is a sign of ASP satan himself. Run screaming. Now.

    Even if it's used at work. Run. Now. Save your soul.

    (also, wrapping entire pages in forms is also a bad idea anyway)

    Code:
    <font size="6">Heading 3</font>
    Font tags pretending to be headers will never rock as hard and awesomely as real header tags. Don't fear <h3>Heading 3</h3>, it does lots of stuff you may not realise (like help the blind navigate a page when using a screen reader or Refreshable Braille Display) and sets a document structure.

    This was all a bit of a 90's flashback for me, you see. It's not that it all doesn't mostly kinda work— browsers don't quit supporting stuff when it's deprecated in the spec, mainly to keep those pages who really were written in the 90's available— but they aren't good practices and even if you see them in the wild, they're endagered species who should not be saved from extinction.

    Quote Originally Posted by Maxx
    When i make my screen smaller, on IE, my site looks like it should be on half the screen, just some scrolling needed to be done, on firefox I'm getting an oversized header, and my content with the table with photo and text in it, is floating somewhere in the topleftcorner..
    While a Javascript-looking-at-window-size may help, the problem is due 100% to his already broken layout with the table and whatnot. Fixing it the "right" way would entail a rewrite, which Maxx may not be interested in or may have a deadline or something. I can suggest he's wrong, but that does sound kinda hollow without offering a solution, or with a (totally rewritten) solution, it sounds kind of elitist. Not that there's anything wrong with elites, I'm happily a web standards elitist nazi pig myself, but sometimes it doesn't help people, depending on their situation.
    *edit with the downloaded text and css files, I can't see the header so don't know if it's still too large in Firefox, but really want to know why a table for the big section in the middle... what is it supposed to do? There may be a better element we can use. But we definitely don't need JS to fix it. Right now the middle part isn't in the top right corner in my Firefox though, it's in the middle of the page, but doesn't fit when browser is smaller.

    Finally, with his overflow-scrollbar problem... if he has a set width on those elements, instead of setting them to overflow: scroll (which creates scrollbars both directions), he could just take the overflow: hidden being set and let it go back to the default, overflow: visible. Or, the original overflow: hidden can be set separately on x and y axes... called overflow-x and overflow-y. If the width of the p doesn't exceed whatever width he's set on the box holding the p (the div) he shouldn't get a horizontal scrollbar, only a vertical one (though I agree, they look pretty ugly anyway).

    If it were my page I'd redo it and use some other method than setting height to hide/show those p's... as I said earlier, using position: absolute and moving it off the screen removes the p's from the document flow, so no space taken up by them... and putting them back in the flow by setting them to position: static means no worrying about heights at all.

    If you'd like to see an example of something similar I had to do (and it's not great, and the Javascript is... convoluted due to n00bness), http://stommepoes.nl/Homeselling/SHL/shlinks.html and today, if I were to do it again... I would have display: none'd the stuff. I normally don't, because normally I want screen reader users to be able to get to it... and screen readers *usually* take display: none seriously: the element is not on the page, so it doesn't get read out. However here, some browsers would tab through the sub-anchors who were offscreen (hidden) while Opera for example didn't. Opera's way was best. I should have display: none'd it to prevent that. With Javascript setting it, instead of CSS, it would have been safe, and with the anchors being created in the headers, it's naturally keyboard focusable, etc.
    Turn Javascript off, and you get the default: all the information shows. This is accessible and JS is just making it nice.


    End mail.
    In other words: knowing the best way to do layouts with CSS will help make a page act mostly the same cross-browser. Absolutely positioning stuff everywhere is probably the most-common way people get trouble when screens are different sizes (I can see you did not fall into that trap), though it's not the only problem people can run into.

    I only have your html and style.css to work from, but I can go through some things I would do differently. Tho without the images or javascript I'm not seeing what you're seeing.

  2. #27
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    If I get a screenshot of the menu before any hover and after hover, I can figure out how that was supposed to look. And if I get either images or dummy ones of exactly the same size then I can see where those are (which is another thing you'll be aware of as a web developer: you can never assume users download any images, so when using background images for contrast, usually you want/need to set a background colour, which is covered up by the image but shows through when images don't load... so text has enough contrast to be read. Right now I have light light light grey text on white, which is hard to read. Also the file seems saved in a windows standard meaning I have lots of ? in the text instead of the correct character).

    Beyond that though, I can go through the markup I have now and point out where I would do things differently. Mostly they are things most web-standardistas would do differently as well, and I'd point out where something is more of a personal choice and where it's something really set by web standards. If you want.

  3. #28
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OMG, that's one hell of a post .. Gonna take my time this afternoon to analyze and put some things in a document to keep it close to me everytime ..
    As it stands now, I put the site as it is close to its completion temporarily on this site:
    http://www.maxx-it.be/Aanbod/Webdesi...ts/index2.html

    You can have a look if you want. I know, even now some things make me cringe, like tables within divs, and divs within that table etcetera :-p. Just all t make it work. THerefore with all the messing around the css is a mess, BUT at least I got it to work. Off course the deadline urges me not to rewrite the whole thing and adaptions will certainly be made in my next few sites.
    Didn't know templates were that bad though for webdesigning, but indeed as you state, you learn most from writing it yourself obviously!

    I must say, I am truly impressed by the effort and time you want to put in this!!

    I really am very appreciative and if I ever could thank you in any way, name it please!

    Kind regards
    Maxx-iT

  4. #29
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I know, even now some things make me cringe, like tables within divs, and divs within that table etcetera :-p. Just all t make it work. THerefore with all the messing around the css is a mess, BUT at least I got it to work.
    Yeah, I'm still in that phase when it comes to Javascript. If I'm not good enough to do it the right way, I settle for what works before the deadline, and try to figure out how to do it better for next time. So, totally understand.

    Thanks for the link, I'll be able to go through that much easier than the text files you linked.

    Also I'm on Linux, so I'll be able to see some things you won't if you're only testing on Windows (I also have Windows so I'll check there too). I like the idea of being able to test on at least two platforms, if not 3 (I don't have a working Mac if but I did, I'd be testing there too).

  5. #30
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    omidog!
    I was logged in and typing, and when I hit submit, it wanted me to log in again! And my whole book I was writing was lost!!!
    Arg!

  6. #31
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Retype!!!

    Okay, sorry I didn't get to this yesterday, I'm kinda juggling a couple of things this week.

    I'll start with the markup. I realise much of what I'm going to comment on is due to the template, but, now you'll be aware of it.

    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml"><!-- InstanceBegin template="../../Templates/index2.dwt" codeOutsideHTMLIsLocked="false" -->
    <head>
    <!-- InstanceBeginEditable name="doctitle" -->
    First, no matter if you're using DreamBeaver or Turdpress or whatever, you'll want a Strict (not Transitional) doctype. Not for browsers, just for yourself: when you send your page to the W3C validator (validator.w3.org), with a Strict doctype it will tell you every syntax error and deprecated tag you have. It can't say whether your code is good or bad; it can't say "don't use tables for layout" or "you've got divitis/classitis" because it doesn't know what those things are. But it can say <font> tags are deprecated and aren't allowed here, and it will catch you if you try to wrap inlines around blocks for example.
    Transitional shuts the validator up about a lot of that. That doctype was meant for people transitioning crappy pages built in the 90's to modern code.

    If your template has the HTML5 doctype (<!doctype html> only) then it's handy to tell the validator to validate *as if* you had an older Strict doctype. As you learn the differences between the specs you'll understand more the differences in errors you will/may get between them (example, HTML5 allows anchors to wrap blocks, while HTML4/XHTML1 do not. However due to IE bugs it's still not a great idea to do it unless there's no sane way to get what you need).

    Second: while editing the template, the template comments are probably handy. But you should make another version when you're done editing where the comments are stripped out. It's just byte bloat.

    Third:
    Code:
    <html xmlns="http://www.w3.org/1999/xhtml">
    It's always always a good idea to add the language here. This is mostly but not entirely for screen readers, who when they come across your page, they should pronounce the text on the page in the language you have set, rather than whatever default language they use (for example mine default to English and so without the language attribute they will try to pronounce Dutch in a very strange way :)
    With XHTML it's this:
    <html xmlns="http://www.w3.org/1999/xhtml" lang="nl" xml:lang="nl">

    with HTML4 and 5-when-not-intended-to-be-XHTML, it's just this:
    <html lang="nl">

    And any significant text inside a tag that's in another language, add the lang attribute there as well. If you've got a span with some French in it, do <span lang="fr">some french text</span> and the language will be limited to that tag and any other tags inside it.

    Fourth:
    Code:
    <title>Mira  | Binnenhuisinrichting</title>
    <!-- InstanceEndEditable -->
    <meta name="keywords" content="" />
        <meta name="description" content="" />
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    There is a small and rather unknown security issue here. The first tag you want inside the <head> is the utf-8 one. Before the title even.

    When browsers get to that tag, it confirms what the server has told them via the sent HTTP headers, and they go back to the top and start over parsing the page (knowing that they are indeed using the correct charset). The security hack is called the utf-7 hack, where anything between the <head> tag and the urf-8 tag that could possibly be used by an agent (like, a script tag), if an "evil" server gets between the client and the requested server, it could send fake headers saying "this is utf-7" and since the browser believes the server first, it could possibly be tricked into falsely interpreting the whatever that comes before the utf-8 meta tag.
    BTW, regarding charsets. There are three places you set the character set: the server via HTTP headers, the markup via the meta tag, and the way the document itself is saved.
    If the meta tag and the server conflict, the server wins out.
    If there is only a meta tag and no headers from the server, the meta tag wins out but the browser starts its parsing under an assumed charset (either whatever the user has set as default, or for example IE6 used to use some kind of weird heuristics to "guess" the charset).
    If the server (or lone meta tag) and the way the document is saved conflict, you get ?'s everywhere (wherever non-ASCII characters are and, if you're saving in Windows, you'll get ?'s also wherever Windows' characters use the same code for different characters (smart quotes, British-pound signs, control characters)).

    When you save your document, make sure it's saved as utf-8 (not saved as Unicode (which may make the editor add a BOM to the page), and definitely not saved as Windows 1252!). Then set your meta tag as the first child of the <head> tag, and make sure the server is sending the correct HTTP headers.

    If you suspect your utf-8-saved documents may be hosted on a server who serves as Latin-1 (ISO 8859-1), you could do the work of writing any non-ascii-7 characters as HTML numerical or character entities which I do (I do it mostly because my keyboard doesn't let me type stuff like é anyway, so I manually type out the &#233 ; without space all the time). This is a lot of work though so it's something you can decide to do or not. I never get to choose server headers over here so I just use the entities to play it safe, because I'll never save an international-intended document as anything other than UTF-8.

    Code:
    <script src="../../SpryAssets/SpryMenuBar.js" type="text/javascript"></script>
    <link href="../../SpryAssets/SpryMenuBarVertical2.css" rel="stylesheet" type="text/css" />
    <link href="../../SpryAssets/SpryMenuBarHorizontal2.css" rel="stylesheet" type="text/css" />
    Spry sucks. It's a bloated steaming pile of code. I prefer a modified-for-keyboard Sons of Suckerfish (or, many people use something called Superfish) with (a modified/fixed version of) Blake Haswell's Suckerfish slight-delay Javascript. You could modify this into a slide/fade in/out as well if you wanted. The modification is in the CSS: Gecko (Mozilla) browsers and IE6 have trouble when you're both hovering and focussed on a submenu at the same time, so I CSS that out.

    Somewhere around these forums Crusty (deathshadow60) wrote out an overflow-hidden version of a dropdown menu that seems to be just as good. It works a bit differently than suckerfish-style with keyboard, but it is accessible.

    Code:
    <script language="JavaScript" src="../../SpryAssets/collapse_expand_single_item2.js"></script>
    This has been deprecated since forever. And it's all screwed up anyway: the correct MIME type for Javascript was set at application/javascript. However it was if you actually used that on a web page, IE puked (did not understand it), so everyone has been putting 'type="text/javascript" ' on their scripts.
    But in real life, it turns out that so long as you don't say something that confuses IE, no browser actually bothers checking anyway. Same goes for references to CSS: they don't bother checking the MIME type to see if it's "text/css". So actually, for stylesheets and javascript, you can actually just leave out the type declarations. Which is why HTML5 doesn't demand them (they wrote HTML5 to deal with what browsers actually bother looking at).

    Code:
    <link href="li-scroller.css" rel="stylesheet" type="text/css" />
    It may be easier for you while developing to have separate stylesheets, but when you launch, stuff the code in this one over to the main stylesheet. Each HTTP request takes *at least* 200 ms. Another reason Spry sucks, it's a crapload of requests. Even when I'm using jQuery, if I'm using it for one thing, I stuff the (slider/accordion/whatever) code right after a copy of the main library code (unless you're calling from another website). Just to reduce HTTP requests. This is one of the things that really makes a web site seem slow or fast to people; even if they have lightning-fast internets, if your server is slow for any reason, it's still a slow-loading website.

    Javascript is known as "blocking", meaning that while a browser is loading and parsing JS in the <head>, it's not loading anything else. It will resume loading/reading the HTML when it's gotten all the scripts in the <head>. So combining scripts, and setting the scripts as the last things in the <head> help (since the CSS and everything else get loaded first). If there's lots and lots and lots of JS, you can try a serial loader, which is a single tiny script who manually builds the other <script> tags in the document. Scripts called by scripts don't block : )
    (yeah, it's document.writeln... if that page had been *real* XHTML that wouldn't be allowed and I'd need to manually add to the DOM which is harder since the page isn't loaded yet... bleh)

    Another solution is to put your external script tags at the bottom of the page, like you do where you call the menu scripts. There are arguments for and against this... which you can find if you search the Javascript section here.

    Code:
      <div class="header"><div class="image"><img src="images/logo mira wit.jpg" width="300" height="235" /></div>
    Bah. When no images load, there's just a blank space. Also, in a screen reader you don't hear anything. But, there's text in that image. So here's where you want alt text (and the validator with a Strict doctype will yell at you for not having an alt attribute anyway).
    An inline like an img can't be the direct child of the body element, but you have everything wrapped in a container div. You have the choice of just letting the img hang out (and setting its display property to block in the CSS) or wrapping it in something else (one div or one p would do it).
    If you consider the text inside to be a paragraph then you could use a p:
    <p id="logo"><img src="images/logo mira wit.jpg" width="300" height="235" alt="Mira Interieur Inrichters" /></p>
    Or
    <div id="logo"><img src="images/logo mira wit.jpg" width="300" height="235" alt="Mira Interieur Inrichters" /></div>

    I'm using an ID because there's only one thing in it, and that's a very direct way of reaching the image:
    #logo img {
    display: block;
    }

    But that's a bit of personal taste. What I object to mostly is the (illegal) lack of alt attribute, and personally I think two wrapping divs is overkill. Esp when the other thing in that header div is
    <div class="empty"></div>
    Yikes! Kill it with fire!
    The menu doesn't have to be in a header tag. It can just come after the image. The natural document flow will set this anyway.
    Code:
    <div id="logo">
      <img src="images/logo mira wit.jpg" width="300" height="235" alt="Mira Interieur Inrichters" />
    </div>
    <ul id="siteMenu" role="navigation">
       <li><a href="index2.html">Home</a> </li>
       <li><a href="bedrijfsinfo.html">Bedrijf</a></li>
       <li><a  href="kijker.html">in de kijker</a> </li>
       <li><a href="contact.html">Contact</a></li>
    </ul>
    
    <div class="sidebar" role="navigation">
      <ul id="servicesMenu">...</ul>
    is an example of what you could do. Because there's a unique token (an id) on the sitemenu (just a name I use... menu1, menu2, menu3 don't mean anything! Use meaningful names! This menu is for navigating the website as a whole, so I called it siteMenu. The other menu is listing the products/services, so that was another name I used. Use what you want, but make sure when you're reading the source in a few months, you know what these menus are by name), it can be targetted in CSS without anything special added.
    #siteMenu {
    float: right;
    width: whatever lets li's fit in a row;
    }
    #siteMenu li {
    float: left; (an example; you could also display inline them, or display inline-block them, or whatever)
    ..etc..
    }
    so the product menu won't accept these styles, and the two menus are styled very differently, so there's no benefit adding another class for sharing styles.

    The role="navigation" is an ARIA landmark role. It's an idea from XHTML2 that was brought over in HTML5, though today it's its own, separate spec. It works fine (in fact, better) with HTML4 and XHTML1. Users with current browsers and new enough AT (accessibility technology) get these landmarks announced to them on page load, and they can choose to navigate directly to any landmark. This means, landmarks stay scarce. You don't mark up every navigation list with a role. Here I think your two main lists are both "primary navigation" so I've got a role on both. Screen reader users don't need skip links if they can navigate with landmarks, however I still use skip links for sighted keyboarders. Below I have a link to a Motorcycle site which, if you tab through it, you'll see the skip link appear, so keyboarders don't have to tab through the whole menu just to get to the links on the main part of the page.

    <li id="langmenu">
    Now that I can see this in action on your page, I'm going to say even though you've pulled it up, it's still too long. I have enough rows of plugins and whatnot on my screen that I still have a "short" browser viewport. Unless I F11 the page, I need to use my mouse's scrollwheel to see everything. Lots of mice don't have scroll wheels, and with keyboard you're just out of luck.
    You did the right thing by having the main menu item go to a page. But on that page, there's no new menu showing the items offered in the submenu.
    This is especially bad when your menu is only available with Javascript enabled and the user has a mouse (with a scrollwheel). One reason I like the suckerfish menu, after adapted for keyboard, is that without Javascript you still have a mostly working menu, and with Javascript you're just making it nicer to use.
    Example (try with and without Javascript enabled here): www.motorrijschoolemo.nl
    The markup on that page is old enough to make me puke now, but I'm still happy with the menu. It's a suckerfish with Blake Haswell Javascript in it. You can tab through it without a mouse. Also the .htc file to make IE6 hover from Peter Nederlof was useful there. It also helps IE7 :focus too.

    Code:
      <div class="content"><div class="inner"> <table id="tabelhome"><tr>
    The only reason I can think of why you'd use a table for this is for vertical-aligning text in neighbouring boxes.

    Code:
    <li><img src="images/A welkom/SF_VWG_01_bruin.jpg" width="500" height="450" /></li>
    Since these images look like decoration, and are in the markup because they are part of the slideshow, I would have alt="" here. Alt attributes are required, but if they aren't really content, the images should just have an empty string. This lets screen readers just skip over it... without an alt attribute, many readers will try to do something... usually read out the url of the image. Which is useless babble. Save your blind users from that.

    Code:
        <div class="slideshow"><ul id="nav">
    			<li id="prev"><a href="#">Previous</a></li>
    			<li id="next"><a href="#">Next</a></li>
    		</ul>
    Possibly I would consider putting an off-screen header here to explain why there are these links that don't go anywhere. I sometimes use offscreen headers, for example if I have a lot of the same type of tag (a lot of lists, or a lot of forms or something) where visually it's so obvious how they are different that there is no on-screen text stating the difference.

    <h2 class="ac">Klein product menu</h2>

    <h2 class="ac">Slideshow navigation</h2>

    .ac {
    position: absolute;
    left: -999em;
    }

    Screen reader users (and also Opera users) can navigate from heading tag to heading tag. Using heading tags where appropriate give your document more structure, better for SE's and other programs making sense of your page, and so also of course those using Assistive Technologies. These technologies usually sit "on top of" a browser. The browser has to pass structural and accessibility information over to the AT, and then the user interacts through the AT with the browser and thus the page.

    Speaking of headers:
    Code:
       <p class="home">Welkom bij MIRA-Zele, interieurinrichters </p>
    
        <p class="home">&nbsp;</p>
        <p class="home">Uw specialisten voor behang, verf, raamdecoratie, huislinnen en vloerbekleding
          </br>Uitvoering van alle schilder-en decoratiewerken  </br>    Interieuradvies - totaalinrichting voor privé en bedrijf</p>
    </td></tr></table>
    That first line looks like an h1.
    That second line needs to go away. It belongs with font tags and spacer.gifs. Use CSS to create more space.
    The third line is fine as a p. It's a sort of tagline.
    </br> does not exist. BR (like IMG and META) are EMPTY tags. They cannot contain content, and so cannot have a separate closing tag. At best, you can "self-close" them in an XHTML environment.

    You should have something like this:
    Code:
    <h1>Welkom bij MIRA-Zele, interieurinrichters</h1>
    <p>Uw specialisten voor behang, verf, raamdecoratie, huislinnen en vloerbekleding</p>
    <p>Uitvoering van alle schilder-en decoratiewerken<br/> Interieuradvies - totaalinrichting voor privé en bedrijf</p>
    </td></tr></table>
    Even then I'd consider using a span instead of that last br and setting the span to display: block;
    Visually, that text is justified. Which not only looks terrible, but makes your text less readable by dyslexics and others... for this reason, it fails WCAG2.

    Not only that, but justified text outside of a newspaper column looks especially terrible in Dutch. Justification works best with languages that have many short words.


    What you can try are
    -soft hyphen, character called &#shy ; or &#173 ; which, if the user's font and browser settings allow a long word to fit, don't show a hyphen (-), but if the word can't fit, a hyphen will be created where you place the soft hyphen (graceful hyphenation). Supported by most common browsers.

    -word-wrap: break-word; is a non-graceful way to force words to break. It breaks them right where the next character cannot fit. This is really better for things like long URLs, where some browsers (like Firefox) will break on a / character, while others (like Opera) will not. This was pioneered by IE, so all versions of IE support this. It was later added to CSS3, first adopted by Safari/webkit. By now, I believe every major browser supports it.

    Code:
    <table id="tabelwords"><tr><td class="words">creativiteit</td><td class="words">kwaliteit</td><td class="words">vakkennis</td><td class="words">veelzijdigheid & diversiteit</td></tr></table>
    You may have used a table here to get at some tabley properties like vertical-align, or maybe to make each td stretch and shrink to always fit the available space there. But you know deep in your heart that this is not tabular data.

    You could consider trying the CSS display: table setting. Not supported by IE6/7 is the worst thing about it, so it leaves things to be desired, but for example I've used it here (the menu starting with Huisgegevens). Stretch and shrink your browser to see what it does.

    Visually:
    I think the way the page shrinks and causes a scrollbar in the table area is worse than increasing your min-width on your container and forcing a page-wide scrollbar. 440px really doesn't let you do much.

    CSS:
    Code:
    body {
    	font: 100%/1.4 Verdana, Arial, Helvetica, sans-serif;
    Excellent. Not only are you setting the font-size to whatever the user's default setting is, but using a % gets around an IE7 resizing bug as well. ++ for using a line-height with it as well: my older code, unfortunately, does not list one, when it should have.

    A note about your font stack though: Verdana (like Georgia) was designed for reading on screens, and has a larger x-height than other fonts in its generic (sans-serif) family. This means if a page looks the way you want when you view in your computer, users on Macs without Verdana or users on Linux without MS fonts are getting a smaller text. You should temporarily remove verdana from your font stack to check if the resulting size with your font settings is still legible and doesn't cause any weird wrapping where you don't expect it.

    I try to keep my large fonts together, and my small fonts together. For example
    font-family: verdana, 'lucida grande', 'dejavu sans', sans-serif;
    those are all larger fonts, and then I still check what the default sans-serif size would be.

    Code:
    ul, ol, dl {
    Actually, I believe it's the dt's or dd's with the margins, not the dl's themselves. Similarly, it's not the ol's and ul's with the mismatched cross-browser margins and padding; it's the li's.
    I do something like
    html, body, ol, ul, li, dd, th, td {
    margin: 0;
    padding: 0;
    }
    or so. I haven't found out if anyone actually adds padding to the html element, and if nobody does I would remove it. The th and td are only there when I have a small table, like a calendar. Firefox adds 1px padding, which on most tables is not noticeable (you'd add your own padding anyway), but on tiny calendars it breaks horribly. DD's have left margins usually.

    Code:
    	font-family: Verdana, Geneva, sans-serif;
    	font-size: 26px;
    If you're not aware, the font shorthand (unlike the background shorthand) requires two properties: font-size and font-family. If you have those two listed, though, you can use the font shorthand.
    Though what you currently have allows the original line-height of 1.4em to get inherited, so this isn't bad.

    Code:
    h3 {
    	text-decoration: none;
    Heading tags don't have text-decoration. If there's an anchor inside it, it's safer and more direct to target the anchor instead:
    h3 a {
    text-decoration: none;
    }

    especially because when it comes to colour, browsers often let default anchor colours override. Esp in IE.

    Code:
    font-family: "Century Gothic";
    Be aware, if you aren't already, that by not listing a generic (sans-serif, serif, monospace) family, users without this font (which isn't free and either needs to get purchased, or come with some program who has it) get the default generic family listed in your body tag. You may have meant that, but if you didn't, list generic families in all your stacks.

    Code:
    #DIV1_title, #DIV2_title, #DIV3_title, #DIV4_title, #DIV5_title, #DIV6_title, #DIV7_title, #DIV8_title {
    The names are rather meaningless, and looks like an excellent place to use a class instead.
    .div_title {
    styles;
    }

    I like id's. They are unique and specific, and one of the fastest ways to reach an element in Javascript with getElementById()... however, from what I hear, the CSS parser is faster with classes. And in this case, this is exacly what classes are good for: shortening a list of elements who all share a style.

    Code:
    img {
    
    }
    If you have img's in your HTML that haven't been set to a block state (like display: block or floated), you may notice in some browsers a bit of space underneath the image. This is known as the "mysterious gap beneath images". It's because images are inlines by default, and even though they look like blocks when they call a file with dimensions, they have a default vertical-align of baseline which makes room for those dangly bottoms of letters like p q j and g.

    If you want an image to remain in an inline state, setting the vertical-align to anything other than baseline removes the gap.

    Code:
    a img { /* this selector removes the default blue border displayed in some browsers around an image when it is surrounded by a link */
    	border: none;
    }
    Actually, it's all images, not just those in anchors, who can get a border.

    In my "reset" area of my stylesheet, I have
    img {
    vertical-align: bottom;
    border: 0;
    }

    hits all these at once.

    Code:
    a:link {
    	color:#EEE;
    	text-decoration: none; /* unless you style your links to look extremely unique, it's best to provide underlines for quick visual identification */
    }
    a:visited {
    	color: #DEDFDE;
    	text-decoration: underline;
    }
    a:hover, a:active, a:focus { /* this group of selectors will give a keyboard navigator the same hover experience as the person using a mouse. */
    	text-decoration: none;
    	
    }
    I'm so not a fan of styling :link, because it's usually a worthless waste of code. Here, you're not even giving anyone any feedback when they focus or hover (except focus has the default outline).

    To prevent repeat code,
    a {
    all anchor styles here. Whatever you don't list, the browser default will show;
    }

    a:visited {
    only list differences for visited links;
    }

    a:focus, a:hover, a:active {
    list differences for interaction;
    }
    I strongly suggest good visual feedback on interaction, like underlining and changing colour. Generally it's good to avoid only using colour or brightness since how well that shows can depend on monitor settings or users being colour blind... see the SitePoint menu for an excellent example of how NOT to do it.
    :active I tend not to style, unless I want to hit IE6 (who thinks :active==:focus), or styling buttons (who should move a but when pressed).

    Code:
    }
    .content {
    ...
    	overflow:visible;
    }
    Unless you're overriding something, visible is the default of blocks.

    Code:
    .footer {
    ...
    	position: relative;/* this gives IE6 hasLayout to properly clear */
    Actually, while position: relative does trigger some weird things in IE6 and 7, it does NOT trigger Haslayout. http://www.satzansatz.de/cssd/onhavinglayout.html

    Code:
    .clearfloat { /* this class can be placed on a <br /> or empty div as the final element following the last floated div (within the #container) if the #footer is removed or taken out of the #container */
    	clear:both;
    	height:0;
    	font-size: 1px;
    	line-height: 0px;
    }
    This is known as a clearing element (usually clearing divs or clearing br's). They do work cross-browser, always, but they are frowned upon by the high-ranking members of the Web Standards Evangelical Army of God. Mostly because, it's adding markup to fix a problem caused by CSS (containers not enclosing their floats). There are a variety of CSS solutions, each with their pros and cons. I made a list once, long ago: http://stommepoes.nl/floaties.html click through them with a modern browser and with IE6 or 7.

    I suppose eventually when enough current browsers fully support multiple background images per element, "sandbags" (empty elements or excessive wrapping elements used solely to hold background colours, images or borders) will be considered similarly.

    Code:
    ul.nav a { zoom: 1; }
    You have this twice.

    I don't tend to use zoom (I prefer trying to use "out in the open" haslayout techniques where possible, with a comment afterwards stating it's haslayout), but that's a personal choice.

    Okay, I've written this twice. I think I'm done for now :)

  7. #32
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    LOL!! :-)

    Had some time to look into your post...
    The JS you were talking about that is 15years old, well, since I don't know how to write JS (yet), I also got my Jquery and JS-codes from the Internet, downloaded from links Sitepoint-users gave me, so I thought they were good and up-to-date... Now I know to check and analyse the codes more, but as newbie still pretty much latin :-)... So you suggest to just let "if (document.getElementById) { // DOM3 = IE5, NS6)" out of your document, or is there something similar needed?

    About your second remark about the mouseclick expand/collapse. NEVER even considered indeed the problem that people REQUIRE a mouse :-).. So you are right, and there has to be another anchor point. Also the disadvantage of working with height here is, that the title cannot be longer then say 5-6words, because then he places the last word or 2 on a new line, which is disastrous for the height offcourse, and its not our intention to write a new code for every long title. Second, you are also limited in the amount of titles.
    In my case, my container is 450px of height. A title is 20px high, and the text expands for 370px. So there is only space for 4 titles(if you have 5 titles: 5*20px=100px+370px= 470px > 450px foreseen) or my container becomes higher then wanted. Off course this can be solved by making the 370px smaller and make the title_content overflow:scroll, but it isn't ideal...
    So how to put an anchor inside it, so people can also read without having to click on the title?
    I guess your solution lays in this line: "<a href="#first" onClick="shoh('first');">" with a getElementbyId JS-code, but how to implement this in his whole into AND JS-script, AND into my htmlcode to make this entire thing to work.

    I also use gladly a document structure, and I love to work with the header tags like <h3>. But that also changes a bit in different browsers. I understand your absolutely positioning offscreen and then back to static, but now aswell I encounter the same problem as always: how to implement this into my code?

    The problem with the screen is already fixed, I guess by putting another div above my table, as you maybe could see in the link to the site. I used a table because a friend of mine always said: In a container if you need wo colums, easiest to work with is a table, they are much more easy to make the layout and they will never interfear which eachother and you don't get float problems and stuff. In the future I will stick to entire divs, if that is the best solution?
    Nonetheless the screen-problem and making it smaller, my header still isn't 100% correct when shrinking the screen. Is there like a basic-tip for EVERYONE to make a basic website (header, sidebar, content, footer), that is well floated when shrunk and doesn't loose accessibility?

    At last still 1 question: Is there any way to make the site "better" as it is now, I mean user-friendly? Or does that require as you said: rewriting the whole thing? I mean: is there anything I can do now, to make it a bit more "correct"?

    Note: I also discovered a problem with the shadows.. I played a bit with the shadows of the container, and offcourse all looks nice in the most recent browsers, but in IE on an older computer, my shadow is an entire block to the right in red, and it's pretty much just plain ugly . I know it has something to do with
    Code:
    moz-box-shadow: 10px 50px 100px #4E1B1A;
    webkit-box-shadow: 10px 50px 100px #4E1B1A;
    box-shadow: 10px 50px 100px #4E1B1A;
    /* For IE 8 - 9 */
    ms-filter: "progid:DXImageTransform.Microsoft.Shadow(Strength=250, Direction=135, Color='#4E1B1A')";
    /* For IE 5.5 - 7 */
    filter: progid:DXImageTransform.Microsoft.Shadow(Strength=250, Direction=135, Color='#4E1B1A');
    but I know nothing off those specific direction codes for IE... They also don't allow a preview and I don't have a old computer with IE to my disposal, so testing is also hard. Are those shadows even widely used? And do they really require specific coding for IE ?

    Note2: Forgive to lol at your postfailure and the login :-)! It did urge me to copy/paste a couple of times this post into a textfile :-)

    Thanks alot Stomme Poes!!!!

    Kind regards
    Maxx-iT

  8. #33
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    So you suggest to just let "if (document.getElementById) { // DOM3 = IE5, NS6)" out of your document, or is there something similar needed?
    It means instead of the
    else document.layers...
    and
    else document.all

    for what you're doing, you should get everyone working with just the
    document.getElementById() line.

    Also the disadvantage of working with height here is, that the title cannot be longer then say 5-6words, because then he places the last word or 2 on a new line, which is disastrous for the height offcourse, and its not our intention to write a new code for every long title. Second, you are also limited in the amount of titles.
    Correct. Now think about users with larger default texts. Your single-line headers may be wrapping in their browsers anyway, causing exactly the same problem.
    A title is 20px high, and the text expands for 370px.
    Even if you set fonts literally to those, every browser except IE can override those, and IE7+ can zoom. IE7 zooms horribly, tends to break other things when it does it.

    Only way I can think around this right now, not changing lots of other stuff, is to not limit the height of the table on pages where you're doing that. Yeah, might look ugly, but...

    So how to put an anchor inside it, so people can also read without having to click on the title?
    The anchor doesn't prevent them from needing to click, it just means they can "click" with the keyboard.
    http://stommepoes.nl/Homeselling/SHL/shlinks.html is an example of how I did it, but that's complicated enough JS that I have trouble "reading" it today.

    And mostly the complication is because with no JS, I did not want anchors. It's a good idea to create things with Javascript who only work with Javascript anyway. Without Javascript, ALL your text would be showing, ideally. However you don't have the room to do this. You could I suppose just manually add the anchors to inside the headers and in your javascript change the header getting the click event to the anchor child.
    <h3><a href="#void">Some header</a></h3>
    <p>all the text...</p>
    or a div wrapping the p if multiple p's.

    So the firstChild of the h3 gets the onclick event, and causes its parentNode's (h3) nextSibling (the div or p) to show.

    Usually someone would have pointed you to some various, better ways of doing what you want, but as I said earlier, we staff kinda missed this thread.

    I used a table because a friend of mine always said: In a container if you need wo colums, easiest to work with is a table, they are much more easy to make the layout and they will never interfear which eachother and you don't get float problems and stuff.
    Understandable. However a good web developer knows that choosing your markup for visual reasons is the path to giving sweet big-eyed orphans face cancer, and we avoid it unless it's really not possible (CSS *does* have shortcomings).

    And yes, you probably want to be much more comfortable with floats before replicating your table with floated boxes. However that's exactly what I would have chosen: a few divs in a .main box or something. I'd even consider letting the jQuery thing get a whole line of its own and the text elsewhere, but I can understand you may be stuck with this design.

    Nonetheless the screen-problem and making it smaller, my header still isn't 100% correct when shrinking the screen. Is there like a basic-tip for EVERYONE to make a basic website (header, sidebar, content, footer), that is well floated when shrunk and doesn't loose accessibility
    For now I'd increase the min-width on the container. So long as floats have room to fit side-by-side, they will. But the moment there isn't enough room, they drop. Float drop sucks. However it's also pretty cool when you're building for a wider range of screens: smaller screens get more vertical content as floats sit underneath each other, while wider screens they can sit side-by-side.

    Your design isn't built for that though, so since it only works and makes sense at a minimum width, I'd set it to that minimum width. I feel with the current design it's better to force a page scrollbar rather than have content cut off and a scrollbar on a little chunk of the page.

    Frankly, the fact is that a design with any sidebars that must *always* be there will never deal perfectly with smaller screens.

    You might be interested in the raging "responsive web design" movement, for inspiration.
    http://www.slideshare.net/bryanriege...e-web-by-yiibu
    These slides are awesome, though they do assume you've heard of @media queries. Some progressive people started using them, like the Colly site you see featured in the slides, but you see how the way they did it at first caused problems.

    The idea is, if you really want one set of content to display well on *all* or at least most widest range of screens, your design has to be more carefully thought out, much more tested, and built so it can deal with those screens, and take them as they come. This does lead to design compromises: you can't build "responsive" web pages if some designer has insisted on certain structures.

    Examples where I've done the design "responsive": scooterverzekeren.com and jeansselling.nl though the code on my servers is nicer: http://stommepoes.nl/Scooterverzekeren/scooter2 (directory list of pages), http://stommepoes.nl/Jeansselling/jeansselling2/ (same)

    Shrink your browser, or view on a mobile device. They still have plenty of usability problems but I feel this is kinda the right direction for many web pages.

    Do a web search for "responsive web design", where you'll see a bazillion articles about it. Ethan Marcotte has released a book on it. If you're interested, there'll prolly be a Dutch translation soon. Then again, maybe not: the Dutch version of Steve Krug's Don't Make Me Think! only came out last winter or something, and that's an old book. Bleh. But there are plenty of Dutch web designers/developers talking about it as well. Have you heard of http://fronteers.nl? They've started having meetings in Belgium sometimes too.

    At last still 1 question: Is there any way to make the site "better" as it is now, I mean user-friendly? Or does that require as you said: rewriting the whole thing? I mean: is there anything I can do now, to make it a bit more "correct"?
    Well, a bit on what my post above says (which got ninja'd in right before yours)... adding proper heading structures (h1-h6) helps immensely (you have CSS for headers, so you have headers, but I point out above some "headers" which indeed should be <hx> tags).
    Possibly finding a different way of doing the very-long product menus... like letting the main link go to a page which simply lists all the submenu products.

    The text shadow actually makes the text quite hard for me to read. But that's ultimately a design decision you have to make yourself. Text shadow in general is best subtle.

    but I know nothing off those specific direction codes for IE... They also don't allow a preview and I don't have a old computer with IE to my disposal, so testing is also hard. Are those shadows even widely used? And do they really require specific coding for IE
    If they don't look good, I'd leave them out. Or, if you *must* support IE, you may need to fall back to images, like we all used to use back in the day.

    The only filters I've ever used are for opacity, so I'm completely unfamiliar with how IE deals with shadows. But I tend to be of the mind that, if I'm using new CSS3 techniques to reduce server load (not using images) then I let IE go a bit bare. IE users use IE, so they never notice what they're missing anyway. And shadows are... extras. Pretty. Not necessary. Which is why for example I'd never rely on text-shadow (not even with IE versions) to make text readable (using the shadow as contrast). If the shadows are 100% required, then it does mean the extra calls to the server for the images.

    Deathshadow has a nice png that you can use and re-use for many shadows though: http://battletech.hopto.org/html_tut.../template.html

  9. #34
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, I'm gonna reread all the posts and answer/ask where needed, for a resumé for me aswell:

    1. How can I change my doctype from transitional to strict? Can this just be done by replacing the word transitional in my doctype, or it isn't thihs simple. Just leave it like it is for this site and begin with it in my other sites?
    2. You say: save your template as a UTF-8 and not as unicode, but how can I do this? If I press save as, I can choose a Unicode Normalization Form and the standard is C, but there is also "none, D, KC an KD" to choose between and then a ticker box to tick "Include Unicode Signature (BOM).
    I never changed anything to this so standard with me it's C and unticked BOM...?
    2b. Edit, just found out that while adding lang ="nl" and xml:lang="nl", I stop seeing the special characters like &, é, à,... so on.. SO any solution there? I can't add span="fr" every time I have to type "privé" or something?
    3. I know spry sucks by now and thanks to Sitepoint :-)! Had lots of work to make it work on every browser, and It's still not optimal. Due to the many efforts for making and changing the lay-out of it, I choose to keep the spry menus for now. But noted: Suckerfish it is next time!
    4. Concerning the spry menu: Just discovered at work on an older computer with a smaller resolution(800x600 AND even 1024x768 that my vertical sidemenu works, BUT my submenu when hovered on an arrow to make it appear, appears BEHIND my photos in the content. So You can't see the submenus, thus no clicking is possible? ANy idea what this may cause? And any solution? On 1024x768 basically the entire site looks like crap :s
    5. <CODE><script language="JavaScript" src="../../SpryAssets/collapse_expand_single_item2.js"></script></CODE>: As I understand your explanation--> In every line where I put "<script type="text/javascript" src=..." I should delete the type: text/javascript?
    6. Don't add the css files AND js script files as seperate files to your site when upload, but copy/paste them directly into your source code?
    7. About the alt-tag: Forgot to put a description there.. That was something I was gonna keep for the last thing to do, because for every photo you see, the company requires an alt-description aswell. SO I totally agree with you on putting alt-attributes!
    8. DId change the header image to div id: logo with display block, and that doesn't change anything on the look of it, but I guess it is more correct!
    9. Ok, so I pulled the horizontal topmenu out of the header tag. <CODE><!-- end .header -->
    <div class="horizontalMenu">
    <ul id="MenuBar2" class="MenuBarHorizontal">
    <li><a href="index2.html">Home</a> </li>
    <li><a href="bedrijfsinfo.html">Bedrijf</a></li>
    <li><a href="kijker.html">In de kijker</a> </li>
    <li><a href="contact.html">Contact</a></li>
    </ul>
    </div></CODE>
    .container .horizontalMenu {
    float: right;
    display:block;
    }

    So that's my code right now for the horizontal menu. HOWEVER, he puts half of my menu BEHIND the photos in the content? Actually I put the horizontal menu in the header, to let it float INTO the header, so that there won't be so many white space in the right side of the header. SO I actually want it on top of the content aligned with where the header ends on the right. Right now, I've got it on the right, but it is IN my content, and aligned not on the bottom of the header but on the top of the sidebar and content.
    I uploaded it so you can see it like it is now: http://www.maxx-it.be/Aanbod/Webdesi...ts/index2.html
    10. WHile changing the name of the Ul id from "Menubar2" into "Sitemenu", I got the error: "while executing inspectSelection in spry_menubar.html, a Javascript error occurred". It seems to work fine though!
    11. I have now ul id="Sitemenu" class="menubarHorizontal". I let the class like it was, because my entire sprymenu css layout is based on that class...
    12. THe adding of role="navigation", does that then actually mean the menu is accessible by both Keyboard AND mouse?
    13. About the <li id='langmenu'>: I puked aswell when I saw how many subitems the company wanted, but yeah, that's the wish of the client I guess, so no other option then to pull it up like I did I guess.
    I agree with you in adding the link from the main menu-item 'raamdecoratie' to the content, but the company also wanted some information on that page, so adding links there would mess up the pretty horizontal site they wanted, without having to vertical scroll 3 times... I also had that in mind, but it would mess up the horizontal layout of the page. MUnless off course you would add a scrollbar, but that doesn't look so good with all the other scroll bars in the expand/collapse titles.

    14. <QUOTE> Possibly I would consider putting an off-screen header here to explain why there are these links that don't go anywhere.</QUOTE>: What do you exactly mean by this?
    I got that code from the cycle plugin tutorial to add the buttons to the pages. So can I delete them, or what is just the function of putting some off-screen headers? And where in my code do I add those off-screen headers?
    15. <p class=" home"> Is indeed not such a good choice from me. I choose this because I wanted a seperate layout just for the homepage text. And I thought I wanted to use h1, h2 somewhere else in my site. So I agree in making that headers!
    16. <QUOTE> Even then I'd consider using a span instead of that last br and setting the span to display: block;</QUOTE> Could you please elabroate this some more? So you say I can't use </br> anymore, but I have to use seperate tags instead? And then change the height or something? Or how can we adapt some single lines distances? E.G. In some cases I want the distance between some lines smaller because they still belong to the paragraph, while when I start 2 p-tags, the distance can be a bit larger...
    17. I understand what you are saying about the newspaper colums! But how and where can I soft hyphen the words, just add some? code to the p-tag?
    18. <QUOTE>I think the way the page shrinks and causes a scrollbar in the table area is worse than increasing your min-width on your container and forcing a page-wide scrollbar. 440px really doesn't let you do much.</QUOTE>: Ok I agree but I had a look at the site on an old 24"inch computer screen, and there aswell, he didn't put the entire site on the screen, but you could only read the text with a scrollbar and it wasn't even visible! SO would it be an option to indeed set the min-width to +- 500px, would it change the entire layout automatic or do I have to manually adapt the entire thing? Any faster solution?
    19. the ul, ol, dl markup is something I got from the internet template, so I guess I just let it the way it was...
    20. <QUOTE>The names are rather meaningless, and looks like an excellent place to use a class instead.
    .div_title {
    styles;
    }</QUOTE>
    Got that aswell from the cycle plugin tutorial, so I just took it from there, because changing that AND analysing the codess and adapting the JS script, was at first a bit too much for me :-). In the future (I do understand the coding a little bit more now) I will change it into classes offcourse!
    21. Agree on the a-tag layout, will keep it in mind for the next sites!!!
    22. <QUOTE>Unless you're overriding something, visible is the default of blocks.</QUOTE> DO you mean I have to delete this line out of my content css?
    23. <QUOTE>Actually, while position: relative does trigger some weird things in IE6 and 7, it does NOT trigger Haslayout.</QUOTE> SO do we really need this line of code? We can just delete it?
    24. I don't use that class clearfloat at all so I guess I can just delete that stuff...

    25. Read your last post aswell and got a good look at the Rethinking mobile websites. I sure want to give this a go, but I think with my knowledge now, that I still got a way to go before I can do this. Hell I don't even know how to make a proper mobile website. That brings me to next: On my Iphone I an't see any text from the site, there should be a scrollbar in the content, but it's not visible on my iphone. So is there a solution, other then that entire slideshow from "Rethinking the Mobile Web by Yiibu" to make my site at least readable on iphone. It looks very good, just the text doesn't show... Maybe with the min-width here as well?
    26. I deleted the shadows for Internet Explorer bleh

    27 AND LAST: Am I desperate?

    I can't thank you enough for all the effort you put into this!! Thanks alot alot alot!!! I Love Sitepoint :-)

    Kind regards!!!
    Maxx-iT

  10. #35
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Goddam it. Damn it. ARG!

    Everything I typed... is gone again!

    I had just highlighted a bunch of it to copy it!!!! And then something got touched and my browser went back a page!

    ARG!

    Sitepoint did NOT used to have this problem. It used to NOT try to MESS with a browser's HISTORY. Normally my browser would remember the static page I was typing into, but now it seems a new request goes to the server and it sends me a blank edit page.

    Hate this. Really, really hate this.

    I'm going to have to think about whether or not I'm going to retype all that again, because this week is hell week and I'm jjuggling several projects. I may have to complain to the staff here about this. This is new from the stupif vbull4 upgrade.

  11. #36
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I'll post every few questions. Take that, SitePoint servers!

    First, take a look at this http://www.thecssninja.com/demo/css_accordion/
    it uses css :target element and then slows it with some transitions. Doesn't work well in older IE but something to be aware of.

    1. How can I change my doctype from transitional to strict? Can this just be done by replacing the word transitional in my doctype, or it isn't thihs simple. Just leave it like it is for this site and begin with it in my other sites?
    Copy and paste from the W3C page (so you can't make mistakes. I used to type them and a double-space between words... sent someone into Quirks Mode): http://www.w3.org/QA/2002/04/valid-dtd-list.html
    However don't listen to them when they talk about <?xml?> crap. Back in 2002 they still thought XML was the future. XML doesn't even need that prologue, unless you're saving as UTF-16. But you're not cause that doesn't work on the web, and you're not really writing XHTML anyway cause that doesn't work in IE... if your server says the page is text/html, then that's what it is, regardless of doctype.

    But so copy HTML4.01 Strict or XHTML1.0 Strict. To keep IE6 from going into Quirks Mode, start at character 1 line 1 (so the <?xml?> junk also breaks IE6, ha ha).


    2. You say: save your template as a UTF-8 and not as unicode, but how can I do this? If I press save as, I can choose a Unicode Normalization Form and the standard is C, but there is also "none, D, KC an KD" to choose between and then a ticker box to tick "Include Unicode Signature (BOM).
    I never changed anything to this so standard with me it's C and unticked BOM...?
    Keep BOM unchecked. Some editors (like Notepad) silently add the BOM without asking you if you "save as unicode". Your editor should have, somewhere, a place to set the character set. You should see options like iso-8859-1 or Latin-1 or Western Something, and utf-8, and maybe Windows 1252... they should be choosable options somewhere. In Notepad apparently it's the samee place where you can say save as unicode, but I don't know what editor you're using.

    2b. Edit, just found out that while adding lang ="nl" and xml:lang="nl", I stop seeing the special characters like &, é, à,... so on.. SO any solution there? I can't add span="fr" every time I have to type "privé" or something?
    It shouldn't be able to affect what letters you see... but setting the charset does exactly that. Lang attributes are pretty much for screen readers tho ideally any software that needs to know the language would use it.

    You will need to know what header your server is sending out. Unfortunately if you can't set server headers and they are sending stuff as windows 1252 then you'll have to save your pages that way :( and not utf-8.

    3. I know spry sucks by now and thanks to Sitepoint :-)! Had lots of work to make it work on every browser, and It's still not optimal. Due to the many efforts for making and changing the lay-out of it, I choose to keep the spry menus for now. But noted: Suckerfish it is next time!
    Yay


    4. Concerning the spry menu: Just discovered at work on an older computer with a smaller resolution(800x600 AND even 1024x768 that my vertical sidemenu works, BUT my submenu when hovered on an arrow to make it appear, appears BEHIND my photos in the content. So You can't see the submenus, thus no clicking is possible? ANy idea what this may cause? And any solution? On 1024x768 basically the entire site looks like crap :s
    jQuery is prolly setting position:relative or absolute on those images. Make sure the menu always has a higher z-index. Most of these dropdown menus have z-index set on the subs, which makes sense cause they're absolutely positioned usually. But IE only listens if you set the z-index on the main menu itself (who then also has to be position: something). http://annevankesteren.nl/2005/06/z-index

    5. <CODE><script language="JavaScript" src="../../SpryAssets/collapse_expand_single_item2.js"></script></CODE>: As I understand your explanation--> In every line where I put "<script type="text/javascript" src=..." I should delete the type: text/javascript?
    language="Javascript" is absolutely deprecated everywhere, never use it. Doesn't break anything, it's just Nutscrape retardation.

    type="text/javascript" is legal, and you can have it if you want. I'm just saying you can save yourself some typing by leaving it out since browsers don't actually use it for anything. I can't remember if the validator complains about no type with HTML4/XHTML1 doctypes... it WILL complain about language="Javascript" though.

    6. Don't add the css files AND js script files as seperate files to your site when upload, but copy/paste them directly into your source code?
    What I mean is, while it's fine to have your files separate for development (and keep them separate if you're giving all files to your client later), but the version that's online shouldn't have what you've got:

    -call a main js library
    -call the cycle script
    -call a ticker script
    -call some other script
    -also call the spry script

    and then

    -call your style.css (can't help that)
    -call spry.css
    -call another spry.css
    -call jquery css
    blah blah.

    Add all those scripts together (keep them in the same order you have them on the page to be safe). One js file, one CSS file (again, add the spry and cycle css to the bottom of your style.css). Fewer requests by visitors.

    7. About the alt-tag: Forgot to put a description there.. That was something I was gonna keep for the last thing to do, because for every photo you see, the company requires an alt-description aswell. SO I totally agree with you on putting alt-attributes!
    It's easy to forget them. So when you're writing the tags, add the alt text in right away at the same time. Built-in easier than bolt-on-later.

  12. #37
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    By the way, for code and quote tags, this forum uses bbcode. Meaning, square brackets [ and ] work.

    8. DId change the header image to div id: logo with display block, and that doesn't change anything on the look of it, but I guess it is more correct!
    yeah the point wasn't the change how it looked, it just seemed like a lot of containers for not much.

    9. Ok, so I pulled the horizontal topmenu out of the header tag. <CODE><!-- end .header -->
    <div class="horizontalMenu">
    <ul id="MenuBar2" class="MenuBarHorizontal">
    <li><a href="index2.html">Home</a> </li>
    <li><a href="bedrijfsinfo.html">Bedrijf</a></li>
    <li><a href="kijker.html">In de kijker</a> </li>
    <li><a href="contact.html">Contact</a></li>
    </ul>
    </div></CODE>
    .container .horizontalMenu {
    float: right;
    display:block;
    }
    A note: ul's are blocks by default, so display: block is redundant. But also, floating stuff automagically puts it in block context, so 99% of the time you still don't add display: block. Even if you're floating an anchor or a span.

    So that's my code right now for the horizontal menu. HOWEVER, he puts half of my menu BEHIND the photos in the content? Actually I put the horizontal menu in the header, to let it float INTO the header, so that there won't be so many white space in the right side of the header. SO I actually want it on top of the content aligned with where the header ends on the right. Right now, I've got it on the right, but it is IN my content, and aligned not on the bottom of the header but on the top of the sidebar and content.
    I uploaded it so you can see it like it is now: http://www.maxx-it.be/Aanbod/Webdesi...ts/index2.html
    I can't remember now if the menu was at the same level as the bottom of the logo or underneath it. If it was aligned to bottom of the header then yeah we'll have to do something else.

    <div id="logo">
    <img.../>
    </div>
    <ul id="Sitemenu" role="navigation">
    ...
    </ul>
    <ul id="Servicesmenu" role="navigation">
    ...
    </ul>

    where #logo has to be floated left and given the same width as the img (it's no longer required to give explicit widths to floats cause they shrink-wrap, but because of IE being weird it's a good idea when you can, so give it a width here), and float the sitemenu right.
    Then the sitemenu should be aligned to the top of the image. To push it down, you can give it a top margin.

    Then the Servicesmenu has to clear it. I would use clear: both since IE doesn't like floats clearing floats in the same direction (logo is floated left above it, and servicesmenu is also floated left).

    If IE really does not comply then we would indeed have to go back to your original idea, something like
    <div class="header">
    <img id="logo"/>
    <ul id="sitemenu" role="navigation">
    ..
    </ul>
    </div>

    <ul id="servicesmenu...>

    Where
    #logo floated left (this makes the image a block)
    #sitemenu floated right (add width and top margin to push it down)

    and .header encloses those floats, while #servicesmenu still clear: both. You can set a width or min-height on .header for IE for example. If you set a height don't use overflow: hidden for other browsers (why width is safer) since your menu may have to get taller if users have bigger text.

    10. WHile changing the name of the Ul id from "Menubar2" into "Sitemenu", I got the error: "while executing inspectSelection in spry_menubar.html, a Javascript error occurred". It seems to work fine though!
    11. I have now ul id="Sitemenu" class="menubarHorizontal". I let the class like it was, because my entire sprymenu css layout is based on that class...
    Likely it's using the id too. You'll either have to go back to the old id OR you could see if you can find all instances of the old id in the spry javascript and change it to your new better name.

    12. THe adding of role="navigation", does that then actually mean the menu is accessible by both Keyboard AND mouse?
    The only thing landmark roles do is get announced to (newer) screen reader users and offer then the possibility to skip straight to that landmark. They could be in the middle or bottom of the page and decide they want the contact page. Now they can simply call up the landmark list and choose the navigation landmark (if they know how landmarks work). Or any other landmark.
    Landmarks don't change how your menu works with keyboard. It's pretty much just for screen reader ussers, but since web pages are more difficult for them with regular HTML anyway, landmarks and other ARIA roles are a pretty easy way to make tags more meaningful and therefore easier to use for the blind.

    13. About the <li id='langmenu'>: I puked aswell when I saw how many subitems the company wanted, but yeah, that's the wish of the client I guess, so no other option then to pull it up like I did I guess.
    I agree with you in adding the link from the main menu-item 'raamdecoratie' to the content, but the company also wanted some information on that page, so adding links there would mess up the pretty horizontal site they wanted, without having to vertical scroll 3 times... I also had that in mind, but it would mess up the horizontal layout of the page. MUnless off course you would add a scrollbar, but that doesn't look so good with all the other scroll bars in the expand/collapse titles.
    On the motorcycle site, the original designer had already had in-page links, so no problem for me. What you might be able to do is have the main menu items go to a page with only the submenu links. Anyone clicking on those links goes to teh same page as people who hovered over the menu and clicked directly on a sub link.
    The thing is, most people with mice will only hover on the menu, so they'll mostly skip that intermediate link page. This likely includes your clients. They may never know :)

    14. <QUOTE> Possibly I would consider putting an off-screen header here to explain why there are these links that don't go anywhere.</QUOTE>: What do you exactly mean by this?
    I got that code from the cycle plugin tutorial to add the buttons to the pages. So can I delete them, or what is just the function of putting some off-screen headers? And where in my code do I add those off-screen headers?
    The cycle thing has links that it uses as buttons: they don't do real link stuff. Screen reader users hear that it's a link (it's announced as a link) but if they click it, it won't take them to a new page or anything. it's just part of the UI of the plugin.

    So since I know they (and anyone using a text browser too) will see links and those links won't do anything, I sometimes like to add a bit of text explaining..Yeah, it's easy to go too far with this stuff, and more verbose is not better! But something like
    <sometag>Slideshow navigation</sometag>
    (and ideally with at least titles, if not hidden text, in the next and prev anchors themselves...)
    explains what those "dead" links do. Since anyone who can see well can tell what they do right away, the text is redundant... so I pull it offscreen.
    See the thumbnails on this page... if you View Generated Source (or use Firebug, to see what Javascript adds to the markup) you'll see the prev and next buttons have text. Titles aren't great but they're better than nothing here. Also had to change from engrish to Dutch. Silly, but lightbox2 puts text in the javascript. Silly silly.

    Since here there's text above saying click the thumbnails and what happens if you do, I don't have a hidden header there. I do have one above the breadcrumb though (not a header, just text).
    <p class="acc">U bent hier:</p>



    15. <p class=" home"> Is indeed not such a good choice from me. I choose this because I wanted a seperate layout just for the homepage text. And I thought I wanted to use h1, h2 somewhere else in my site. So I agree in making that headers!
    \o/
    16. <QUOTE> Even then I'd consider using a span instead of that last br and setting the span to display: block;</QUOTE> Could you please elabroate this some more? So you say I can't use </br> anymore, but I have to use seperate tags instead? And then change the height or something? Or how can we adapt some single lines distances? E.G. In some cases I want the distance between some lines smaller because they still belong to the paragraph, while when I start 2 p-tags, the distance can be a bit larger...
    It's not that you can't use br tags ever, it's that it is a fine line between choosing tags for content reasons, and choosing tags for purely visual reasons. Now sometimes, HTML is just too limited, or CSS is limited, and we do still choose some tags based on visuals, but the idea is not to.

    If you're creating breaks in text purely because it fits in a particular visual design (but let's say that same text elsewhere would look really silly being broken up in to little lines), then a br tag is the last tag to use. You could use multiple p's, though sometimes I think a sentene fragment wwho's really short isn't the same as a "paragraph" (the w3c is pretty loose with their definition of paragraph) so sometimes, when I need text on a new line only because of the design, i'll try another tag. P's can only have inline tags in them so one way you can do is a span, then set the span to display: block. The article page here I have chunks of text and I'm using many inlines for that. Without CSS, a lot of it is one long line.

    Now poetry, postal addresses, other things... you want those bits of text on a new line whether there is css or not. That's what br is really good for. It means "there needs to be a break in this content".

    it's also semantic nitpicking, and the black clad jack-booted web sstandards storm troopers aren't going to break into your bedroom in teh night-time and haul you away for using br tags for pretties. It just usually means there's a better tag you can use.

    Remember that if you don't manually set margins on p's, browsers have defaults. You can have smomething like, p's have bottom-margin of .6em, except if they're in a container called ".home" then make them .2em.


    17. I understand what you are saying about the newspaper colums! But how and where can I soft hyphen the words, just add some? code to the p-tag?
    Yeah you add them manually, so the problem with them is you can't use them if your client is adding text themselves or anything, just static text you know won't change.

    You look at your page and if teh container is narrow (like on your page) and you see a long word like interieursversorging, then in the HTML you'd change it to interieurs&#173;verzorging. I don't like the idea of mangling words in HTML for visuals (see all my reasons above), but I've used it in mobile versions of voorwaarden like on the scooterverzekeren page I linked to above... that was static content and no way those words would fit on smaller mobile screens. There are javascript libraries out there who will add hyphens for you, but I don't know which ones. That's kind of a better solution.

  13. #38
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    18. <QUOTE>I think the way the page shrinks and causes a scrollbar in the table area is worse than increasing your min-width on your container and forcing a page-wide scrollbar. 440px really doesn't let you do much.</QUOTE>: Ok I agree but I had a look at the site on an old 24"inch computer screen, and there aswell, he didn't put the entire site on the screen, but you could only read the text with a scrollbar and it wasn't even visible! SO would it be an option to indeed set the min-width to +- 500px, would it change the entire layout automatic or do I have to manually adapt the entire thing? Any faster solution?
    Increasing the min-width means isntead of letting the table area get smooshed, the whole page makes a scrollbar. Like wikipedia does. Your layout simply isn't adaptive to really tiny screens (or larger screens with low resolutions like 600x800). You simply have too much stuff trying to fit horizontally.
    You can add a max-width to stop it from getting wider than something if users have ginormous Cine-Macs too. Min and max width don't work in IE6 tho.

    19. the ul, ol, dl markup is something I got from the internet template, so I guess I just let it the way it was...
    But you'll need to understand what it was trying to do, because some elements, if you don't reset them, will cause you to lose hair when trying to get things to work cross browser. Not as many as some of these resets you see laying around the web: if you see a reset with center tags, applet tags, or a crapload of tags you're not even using, stay far away from it. Resets that are really long are resetting things you're not aware of, which also bites you in the end.
    Just, keep an eye on margins and padding on lists, the body element, and remember p's and hx's have default margins. Don't remove padding from form controls since some browsers won't let you add them back in (like Opera with selects was, dunno if it still is) and screws with submit buttons. This is why I don't use the * to reset padding.
    20. <QUOTE>The names are rather meaningless, and looks like an excellent place to use a class instead.
    .div_title {
    styles;
    }</QUOTE>
    Got that aswell from the cycle plugin tutorial, so I just took it from there, because changing that AND analysing the codess and adapting the JS script, was at first a bit too much for me :-). In the future (I do understand the coding a little bit more now) I will change it into classes offcourse!
    Yeah anything pre-written for other people to use, even other developers, will always be more garbagey than hand-written code. You can't escape it.

    21. Agree on the a-tag layout, will keep it in mind for the next sites!!!
    Forgot what this was, lawlz.

    22. <QUOTE>Unless you're overriding something, visible is the default of blocks.</QUOTE> DO you mean I have to delete this line out of my content css?
    You don't have to, it's just not doing anything.

    I mean, you don't want code like this:

    Code:
    div {
      position: static;
      display: block;
      width: 100%;
      margin: 0;
      padding: 0;
      overflow: visible;
      background: transparent none 0 0 repeat scroll;
    }
    None of all that long code does a single thing in any browser, because those are already the default (well, there's a special exception to the width statement, but let's skip that).
    At worst it's bloat, and I didn't check to see if you really were overriding some earlier code, so no, you don't have to delete it.

    23. <QUOTE>Actually, while position: relative does trigger some weird things in IE6 and 7, it does NOT trigger Haslayout.</QUOTE> SO do we really need this line of code? We can just delete it?
    It might still be keeping some bug at bay in IE6. I didn't check. For now you can leave it in. When you're building something yourself by hand, check to see if IE6 (or whoever) is actually having a problem first.

    24. I don't use that class clearfloat at all so I guess I can just delete that stuff...
    If you're sure it's not being used anywhere! You do have floats.

    Go ahead and practice floats and containing them and clearing them anyway. They weren't intuitive to me at all when I started. I have to think of them as Post-It notes: attached at the top but floating up at the bottom where the rest of the page can't see them and slides up underneath them.

    25. Read your last post aswell and got a good look at the Rethinking mobile websites. I sure want to give this a go, but I think with my knowledge now, that I still got a way to go before I can do this. Hell I don't even know how to make a proper mobile website. That brings me to next: On my Iphone I an't see any text from the site, there should be a scrollbar in the content, but it's not visible on my iphone. So is there a solution, other then that entire slideshow from "Rethinking the Mobile Web by Yiibu" to make my site at least readable on iphone. It looks very good, just the text doesn't show... Maybe with the min-width here as well?
    Uh, there's a problem I read about with iPhones/pads... scroll boxes don't make scrollbars or something, so if something is overflow: scroll it just gets cut off in those. I don't know what the workaround is for them... there is a mobile subforum here on SitePoint where you might want to ask. My own phone doesn't even do internet... it just makes phone calls : )

    26. I deleted the shadows for Internet Explorer bleh
    yay. Might make IE users think about upgrading to... any other browser!

  14. #39
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1. Thanks again for the retype . Now I type my entire text in notepad first and then copy it to Sitepoint
    2.So I changed my doctype of my template to strict . However, when I press save, my editor doesn't ask me to apply the changes to every page of my site.. I think this is due to the change to strict, because before every change was updated to every sitepage.
    Do I have to change EVERY page manually? ANd now I've made some changes with the header and stuff, so it's a disaster if he doesn't update automatic.EDIT: can't change some things in the other pages manually, because they find themselves in non-editable regions, so no changes possible, BUT my template doens't apply the changes to the other pages so whaaaaat ?
    3. I amusing Dreamweaver CS5, I know, its not the best editor, but at school they learned me to work with that :-). That being said, I still can't find how to set the charset. I'v added it manually as you told me <meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> in my headtag, but now I have the problem of the special characters like the é,à, that can't be viewed.
    4.I changed the z-index of the ul.MenuBarHorizontal li to 1000 so now, it shouldn't come behind the images.

    Before I can continue adapting, I must find a solution for the template to update all my pages again . Tried changing back to transitional, but no avail. New pages based on the template DO change automaticely, but my older pages don't.

    I've made an index3.html, based on the template, so I can test from there. I made a seperate file with the "newer" css like you suggested: http://www.maxx-it.be/Aanbod/Webdesi...ts/index3.html

    5. Inserted back the header tag, to place the Sitesmenu, and that turns out fine, BUT when shrinking the screen(AGAIN the shrinking problem ) my menu doesn't appear. When I make it half page my Sitemenu just disappears, and even scrolling doens't make it appear.

    So to sum up again:

    - I'm getting closer and closer of understanding the full layout of the site and the adjustments
    - I'm getting closer of making the entire code of the site better and correcter
    - My site looks a lot better crossbrowser related
    - My layout still sucks when it comes to different resolutions and screens
    - My layout absolutely sucks when it comes to shrinkin the screen ..

    So isn't there anything I can do to make it work when viewing on smaller screens/shrinking? I do understand the concept, my images are always fixes width, as is my sidebar, so we have to comply with the content next to the images offcourse.. There isn't anyway the images become smaller when shrinking the screen and you can still see the text entirely?
    Because on different resolutions, even fullscreen appears a scrollbar, and my client said she wasn't that happy that you don't see the text appearing in his total.. Sigh

    Thanks again!

    Kind regards
    Maxx-iT

  15. #40
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Question is, will the site ever be ready before november to put online ?

  16. #41
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Got the characters to work, I updated my meta-tags everywhere, and now my é,à,... work.
    Got the template back to work, he updates the site again!
    So then there is only the issue to get him online succesfully and without much layout differences crossbrowser and with different resolutions.
    If you could just help me making this a bit better, so my site doesn't transform at every browser of resolution, that would mean the world to me!

    BTW: Sorry if you had a difficult week, and then you put so much time in helping me aswell!! So thanks a million!

  17. #42
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    2.So I changed my doctype of my template to strict . However, when I press save, my editor doesn't ask me to apply the changes to every page of my site.. I think this is due to the change to strict, because before every change was updated to every sitepage.
    Do I have to change EVERY page manually?
    This was something I wouldn't have been able to answer, because it's 100% to do with your editor. I use vim : )

    5. Inserted back the header tag, to place the Sitesmenu, and that turns out fine, BUT when shrinking the screen(AGAIN the shrinking problem ) my menu doesn't appear. When I make it half page my Sitemenu just disappears, and even scrolling doens't make it appear.
    This is float drop. If you could see through the rest of the page, you'd see that eventually, the .header isn't wide enough for both floats to sit side-by-side, so the later one in source has to drop beneath the first one. The reason the header isn't growing taller to show the menu and pushing the rest of the page down is, you combined a set height with overflow: hidden. You really do not want to do this: if you set a height, don't use overflow: hidden. Setting a width and overflow: hidden would be okay because nobody inside has a width greater than your page.

    You could try just removing the height for .header and giving it a min-width. Set this to whatever amount still allows the two floats to remain side-by-side. This should mean if you try to make your browser smaller, the page gets a scrollbar.

    There isn't anyway the images become smaller when shrinking the screen and you can still see the text entirely?
    There are ways to shrink images, but a lot of them suck. One trick is to set img tags in the html to width: 100% and height: 100%, and have them inside a box with flexiwidth. But since making that box smaller means the browser has to compress the image, and browsers suck at that, the image looks crappy.

    In responsive pages, sometimes if an image MUST be present on the page, the server sends a smaller-dimensioned image when the screen is too small. I don't see this page ever doing this. Still better to force a minimum wide width of the page and make people scroll... the other option being, completely redesign the site and figure something else out for the jQuery slideshow. Which I don't believe is really an option for you.

    But, screens wider than that minimum shouldn't have a scrollbar.
    Because on different resolutions, even fullscreen appears a scrollbar, and my client said she wasn't that happy that you don't see the text appearing in his total.. Sigh
    If they want all that stuff to fit in a row, then someone's going to get a scrollbar. How many clowns can you stuff into a Volkswagen Beetle??

    But you might be able to allow more room in the grey area for text if you (in an image editor! like Photoshop or something) shrink all those slideshow images a bit and reset the sizes for the slideshow img tags...

    My browser has to be set at minstens 963px wide to get all of the image in the slideshow (also I'm missing some jquery so it's not running in version 3). To get some usable amount of text in the right side, browser needs to be at least 1348px. Which is rather wide.

    You could also maybe win some room by making the rand of the left menu smaller... that is, less room around the actual menu part. I don't like suggesting decreasing font size too because then you have a hard-to-read site.

    I think the general setup is just difficult to build well. It forces three large boxes to fit side-by-side (and the container being limited to non-full width as well), and at some point you must demand wide browsers to fit all that in there.

    The clients are demanding that a whole lot of information be crammed onto the page, but then also that it looks nice and clean rather than cluttered. I think here there is too much being pushed onto the main page: I'd reduce what's available in the left menu (making broader topic categories) and exchange those for an extra click on the part of the visitor. I'd also try to re-design the right side by allowing all that header+text to live underneath the slideshow rather than next to it.

    But the client likes the general design already so I think I'd do this:

    1. Reduce the rand of maroon around the left menu (you've got 30px on each side... try making that 10px on each side). Slightly reduce the size of the text in the menu (I don't like this because you've got 15px now and I do not like going below 14px when setting px fonts... and it looks bigger now because you have verdana, so maybe consider allowing only smaller fonts listed there? 14px Geneva, Helvetica, Arial or something? This might let you reduce the li's from 200px wide to like 180px wide or something).

    2. Then see if you can reduce the dimensions of the photos. Try 400px by 360px (which should be the same proportion).

    3. Then see if you can set the min-width of the container to something that allows it to be 100% of the page until about 1024px. That's a common resolution (though on many screens they will have less than that due to scroll bars and maybe sidebars like for bookmarks and things), and after that, wider screens get the centered look.

    .container {
    min-width: 1024px;
    width: 80%;
    }
    or something. See how small you can make the min-width before stuff just wants to get cut off... after the other changes above you might be able to get away with something smaller for min-width.

    This means any screens less than 1024px (or whatever) get a horizontal scrollbar on the page BUT the menu in the .header cannot drop and nobody can cover anyone else up.

    4. Finally see if you can change the sizes of the text on the right. Let the show-text be 14px and the koptext only 18px or something. Again I don't like reducing text size but it's probably the only way to stuff everything in this setup.

    I'm not sure how much more you could do to get more to fit in less.

  18. #43
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Changed most of your tips, the adaptation of the images to a smaller format, is something I am putting on the waiting list, and I'm gonna wait to see how the company will react.
    Overall, I think it is pretty much finished now.
    BTW: In the homepage, I added for the slideshow the alt-attributes, but I think due to the jquery adding of the prev/next buttons,the alt doesn't show when hovering/standing on the slideshow. And the company wanted something like that to show aswell for some extra information concerning the images.
    If you wanna have a look on the final result, here it is: http://www.maxx-it.be/Aanbod/Webdesi...ts/index2.html
    I'm posting it as a final result as soon as I'm getting your "GO"!

    I mentioned you and Sitepoint in the meta-keywords tags, as my final thanks!
    If you would see any errors or have any remarks, don't hesitate!
    P.S. in the final version on the site itself, I will add the CSS to 1 file. I'm a bit scared of the js files though in putting them all into 1 file:
    Can I just copy/paste everything under eachother and then link to that 1 file? Is that all there needs to be done for the js?

    Thanks heaps!!!!
    Maxx-iT

  19. #44
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    but I think due to the jquery adding of the prev/next buttons,the alt doesn't show when hovering/standing on the slideshow.
    Actually, alt isn't supposed to show when hovering... that's an old IE bug. Alt text should only ever be seen on the screen if/when the image doesn't load.

    What does appear on hover though is the title attribute. I'm usually against title most of the time because it's often redundant and not useful and isn't available to keyboarders... BUT if the company specifically wants some text to appear on hover then that's exactly what you want.

    <img src="blah.jpg" width="" height="" alt="you may or may not want alt and title at the same time" title="text you want to appear on hover">

    Usually you don't want alt and title to repeat each other. Some screen readers, if so configured (cause you can change the settings but we assume newbs don't change anything, like with browsers) will read out both. So depending on how important the text is (which you must decide), you might want alt="" and title="the text".

    If it's pretty important text then go ahead and repeat them. There are only 6 or so images in the slideshow anyway.

    In the future if you have alt attributes and you notice that IE is showing a tooltip when you don't want it, you can get around the bug by adding an empty title:
    title="" alt="your real alt text"

    Though I can't say there wouldn't be something jQuery does to make that not work quite right... for example the anchors are sitting right on top of the images and so hovering over them might not let a title tooltip from the image underneath to appear...

    I mentioned you and Sitepoint in the meta-keywords tags, as my final thanks!
    slimme poes! haha

    I'm a bit scared of the js files though in putting them all into 1 file:
    Can I just copy/paste everything under eachother and then link to that 1 file? Is that all there needs to be done for the js?
    Yeah, I seem to recall that when I did that and jQuery was involved, I had to be careful with the part I added...

    Ah, in my versions I also had the calling function at the very end, while you have it at the bottom of the page (shouldn't matter because the ready function is waiting for the page load event anyway).

    What you can do is just try it (make backups, or create a clone/fork of what you have so you don't lose what you've got now) and try putting the scripts together and see if they still work. If you get errors, separate the Spry stuff from the jQuery stuff. You'd still have just one spry library and one jquery line.

    Code:
          <li><a class="MenuBarItemSubmenu" href="vloerbekleding.html">Vloerbekleding</a>
            <ul>
              <li class="submenu"><a href="blah"></a></li>
              <li class="submenu"><a href="blah"></a></li>
              <li class="submenu"><a href="blah"></a></li>
            </ul>
    I didn't see .submenu in your style.css... is it for Spry? Without Spry, normally you don't need a class on each sub-li. You normally target them with ul li li {styles} or use the class you've got on the anchor.

    Code:
    <table id="tabelwords"><tr><td class="words">creativiteit</td><td class="words">kwaliteit</td><td class="words">vakkennis</td><td class="words">veelzijdigheid & diversiteit</td></tr></table>
    Similar. The class on each td isn't necessary... #tablewords td would hit them the same way.

    I forgot to mention this, but here's another role that's good to add:
    <div class="footer" role="contentinfo">

    There are mostly two roles you'll ever see on footers: contentinfo and complementary. Contentinfo is mostly information about who made the page and stuff like full company name, street address, etc... company info usually counts as contentinfo.
    Complementary is for stuff that you'd also maybe see in a sidebar. Sometimes people put stuff in footers that's stuff like, extra links, partner sites, side projects... often these are sitting in a "fat footer". Like the black area of fabrique.

    So you could add a role of contentinfo to the footer.

    If you were to add a role of main, it would probably either be the beginning of the slideshow (the table itself), or, likely better, the right td with the actual text in it.

    I happened upon raamdecoratie.html randomly clicking and there, it seems two grey areas, and the smaller one has the text? I clicked on another page and it looked fine.

    Check your site in the validator:
    http://validator.w3.org/check?uri=ht...Inline&group=0

    Most of those errors are explained below:

    XHTML sees META and meta as two very different things... it's case-sensitive. If you're going to keep all those, lowercase them. If you're going to use XHTML rather than HTML4/5, then you need to close the meta tags like /> in the <head>.

    You have two charset tags: <META NAME="charset" CONTENT="ISO-8859-1"> is later... it's possible that this one is making your letters okay since I'm not sure if it is able to override the other meta tag or not. Remove it and then check your letters.

    You still have </br> in the page. This tag does not exist. For XHTML, you'd need <br/>.

    Code:
    akkennis</td><td class="words">veelzijdigheid & diversiteit</td></tr></table>
    Ampersands (&) need to be escaped because they can have special meaning. Change them to &amp ; (without the space).

    This also means in URLs. If you have an & in a url, the validator will not only complain about the &, but it will also flag any trailing = as well. The = is not an error, it's just being triggered by the &. You can safely turn & into &amp's in URLs because browsers convert them to the correct character.

    The roles will give you errors because the validator with that doctype does not know what they are. These are errors we are willing to accept, because they aren't real errors.

    The last error is complaining about the type.
    required attribute "type" not specified

    <script> $(function(){
    It's up to you if you want to add the text/javascript to satisfy the validator or not. Under the HTML5 experimental doctype the validator would say nothing (same for roles) because it knows what that means, but XHTML will always flag it as an error... browsers don't care.

    It's up to you.

    Beyond that, triple check your pages by clicking through them, and then, I guess release it.

    Your next site will be so much better : )

    Don't forget to checkout fronteers.nl... they have meetings in Belgium (non-members can attend), where they talk about front-end stuff. A meeting is where I first heard of @media queries, ARIA roles, and Phonegap. :)

  20. #45
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    ha, heel toevallig: http://www.alistapart.com/articles/e...-made-elegant/

    Something to bookmark for the future

  21. #46
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, so added the title attributes, and hop, it works..
    the li class="submenu" is indeed styled in the spryvertical layout, and yeah, I shouldn't add that class to each li .. But!! That is something DW did automatic when I inserted the spry.
    On the suckerfish menus in the future, I won't be having this problem then^^
    Added the role-contentinfo!

    Analyzed the site with the validator. He says that all my meta tags give errors and that the "-characters aren't allowed, because of incorrect use of strict-document: lowercased them, EDIT: I need to change the Uppercase words like NAME and CONTENT aswell (something for tomorrow)!
    I happened upon raamdecoratie.html randomly clicking and there, it seems two grey areas, and the smaller one has the text? I clicked on another page and it looked fine.
    Well yeah, I saw that today aswell :s. It must have happened when changing the widths for the floats that shouldn't drop.
    Has it got something to do with the fact you adviced to put .content {width: 85%; min-width: 1024px}? Again, this is only noticeable at other(smaller?) screens then mine, because on mine everything was perfect.
    I changed the widths, and I hope that it's ok now! Don't even know how it came that some pages had that grey area next to the slideshow..
    Changed the </br>'s into <br/> !

    If you look at the page: http://www.maxx-it.be/Aanbod/Webdesi...ts/kijker.html, you notice that the content, doesn't reach the end of the page, with the grey backgroundcolor.
    This is due to the fact that every other page doesn't have this problem, because the width is adjusted to the quantity of the text. And just on this page, the sentences don't come long enough to extend the class tot the right end of the page. Any idea how to adapt this?

    Going to adapt the script type aswell tomorrow.. Have a meeting tonight

    Thanks!!

    Kind regards!

  22. #47
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,275
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Has it got something to do with the fact you adviced to put .content {width: 85%; min-width: 1024px}?
    It didn't correct itself as I played with my browserwidth, so no.

    What the css declaration should mean:
    at all times, .content is 85%
    except if forced smaller, always be *at least* 1024px wide.


    If you look at the page: http://www.maxx-it.be/Aanbod/Webdesi...ts/kijker.html, you notice that the content, doesn't reach the end of the page, with the grey backgroundcolor.
    This is how it looks on my end: http://stommepoes.nl/max.jpg it's supposed to look different?

  23. #48
    SitePoint Enthusiast
    Join Date
    Oct 2011
    Location
    Zele, Belgium
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I changed it already, and everything seemed to work. So I guess the release is a "GO" :-)!!!


    Thanks again!!!


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •