Skip to main content


The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 39 total)
  • Author
  • in reply to: text formatting in textbox #131357

    WYSIWYG editor. That is the general type of editor.

    in reply to: Getting around Chrome font display on PC #131065

    Whether you’re talking about poor antialiasing on Chrome, or the font being too thin on Chrome, there is definitely a solution:

    `@media screen and (-webkit-min-device-pixel-ratio:0) {}` will single out webkit driven browsers (Chrome and Safari). With this media query, you can increase the font size, AND you can use the `@font-face` directive to force the webkit browsers to take the `SVG` file-type over the `WOFF` file-type. NOTE: In the normal CSS, you’d have your cascading fonts under the `@font-face` directive, but you would eliminate all of them except `SVG` for your Webkit media query. Makes worlds of difference.

    @font-face {
    font-family: ‘League Gothic’;
    src: url(‘../fonts/League_Gothic-webfont.svg#LeagueGothicRegular’) format(‘svg’);
    font-weight: normal;
    font-style: normal;

    in reply to: Sidebar Menu Design #131063

    Do you mean sub-menus? It displays them as slightly indented (links 6 through 10).

    in reply to: CSS Menu Slider for Mobile Devices – Collaboration #131055

    I’ve updated it a little bit. Little more cosmetically pleasing, and I added support for sub-menus. Still looking for some collaboration on this.

    in reply to: Sidebar Menu Design #131054

    This may be something you’d be interested in: [Github]( “NicholasRBowers on Github”).

    Example of it live is here: [JSfiddle]( “NicholasRBowers on JSfiddle”).

    in reply to: CSS Menu Slider for Mobile Devices – Collaboration #119848

    @Koopa absolutely! IE is the bane of every web developer, but that’s what Modernizr is for. If the browser doesn’t support transitions, have it load some JS as a fallback to make it pretty.

    in reply to: CSS Menu Slider for Mobile Devices – Collaboration #119845

    @bkbillma I just got a chance to look at the site under 400px on both a laptop and my phone. I see what you’ve done, but there are obvious drawbacks.


    • Menu is only visible when the mouse button is held down, as soon as it’s released, the menu disappears. This makes it impossible to use the mobile version of the menu on desktop.
    • Does not respect scrolling, will jump up to a little lower than the top when the menu button is clicked.


    • Menu doesn’t pull out far enough, text is cut off.
    • Can still scroll when menu is extended.
    • Only way to collapse the menu is to click on one of the menu items.
    • Does not respect the user’s scrolling. Resets to top.

    A lot of these reasons are why I stayed away from the :target pseudo-class. Again, this is more of a proof of concept than something on which I would reliably base a business’s website.

    in reply to: CSS Menu Slider for Mobile Devices – Collaboration #119842

    @ChrisP those are the same issues I’ve been struggling with for awhile. Fixed positioning and overflowing out of the window will definitely create some problems on different browsers, and will cause you to be sent right back to the top when the menu is collapsed.

    in reply to: CSS Menu Slider for Mobile Devices – Collaboration #119230

    @bkbillma I thought about using :hover/:target/:active to make this work, but I forget why I ultimately decided to go a different direction. Obviously, I don’t like the idea of building a complete navigational structure off of a hack, but CSS offers very little opportunities to store state information.

    Which part of the website demonstrates your version? I couldn’t find it.

    Obviously, this entire thing would work much simpler with Javascript, but CSS-only is fun and challenging – plus it hasn’t been done yet. This is more of an exercise to see how we can leverage CSS to do many of the things people just appropriate to JS, which (in certain instances) negatively affects page loading times. I usually only use JS to make things pretty, but rely on HTML and CSS for functionality (although, again, this is a hack and not really best practice).

    in reply to: CSS Menu Slider for Mobile Devices – Collaboration #119228

    @ChrisP, that’s slick! I’ll implement that into my version on Github. I’m still trying to find a way to be able to make the `#page` panel unscrollable when the navigation menu is out. Thoughts?

    @chrisburton, no. That is caused by the same issue. Look at the header that says “Grand Opening!” and “January 2013”. Notice how in the landscape picture, it’s a nice, script font. Then in the portrait picture, it’s a very general sans font. These fonts are set in em’s, hence why the header is much bigger (proportionally) in the portrait picture. I think this somehow causes the font to fallback, but I’m not sure why..

    The first letter issue is borne out of the same problem (I think). The styling on the list items is such that I use the :first-letter pseudo-element, and set the font size to 1.5em. In portrait, this doesn’t render correctly, and renders smaller than the neighboring text (which is also sized in em’s).

    in reply to: Checkbox Hack on Mobile Webkit #115972

    Thanks @DesjardinsM! Definitely not best-coding practice, but interesting enough for those who want CSS-only solutions for storing state. Good to know there is a “legitimate” workaround.

    in reply to: Self-Processing PHP Form #113030

    @traq thanks for your input! I’m changing things up right now, and I thought of a way to handle things thanks to what you said. I’ll let you know when it’s committed and pushed. I haven’t got a chance to look at your gist yet, but I’ll do that very soon.

    Had a question about adding the header to the email though: if I add it do I have to change the returns in my body to carriage returns? and do I add these headers before the To: From: etc headers?

    in reply to: Self-Processing PHP Form #112907

    Okay, so I’ve created a self-processing PHP form that builds itself dynamically based on a configuration array.

    $inputFields = array(
    // Which fields do you want the contact form to include?
    // FORMAT: array(referenceKey (no spaces), Display Name, fieldType, isRequired?),
    array(‘name’, ‘Name’, ‘text’, true),
    array(‘phone’, ‘Phone Number’, ‘text’, true),
    array(’email’, ‘Email Address’, ‘text’, false),
    array(‘source’, ‘Source’, ‘text’, false),
    array(‘message’, ‘How can we help you?’, ‘textarea’, true),

    I’ve hit a slight road block, as I’m not sure how I should approach dynamic validation of the data passed into the forms. Each field has different validation that goes further than just determining if a required field is blank (email address will be validated via REGEX differently than a phone number). I need a way to be able to validate many different types of input, without knowing explicitly what they are.

    I can obviously use pre-fit reference keys (email for email address, name for name, phone for phone number, etc.), but that isn’t something that’s very user friendly, as that all has to be documented and places limitations on the code. For the complete code, you can visit [GitHub]( Ideas?

    in reply to: Self-Processing PHP Form #112904

    @traq check out where I’m at now on it, I think you’ll be able to help out. I’ve laid the framework for automated form building, but not validation (because validation is inherently different depending on the type of field) – trying to find a way to make it anticipate the kind of data meant for each form.

Viewing 15 posts - 1 through 15 (of 39 total)