The Web Design & Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

Leshy: Jun 21, 2004

Loezi posted:

Isn't the whole idea of CSS and HTML that content is separated from the visual representation? What the hell am I not getting here?

That is the idea, but there is quite some discussion on exactly how far they can be seperated. Specific designs and browser limitations may require the use of extra elements (such as wrappers), which are then by default only there for visual representation since they add no further semantic information about the document.

Grid systems, for example, are quite popular. They create a grid on which you can lay out your content so that your site has a pleasing visual harmony and becomes responsive as the individual elements reflow according to the screen size of the visitor. All good stuff, but they do tend to require a lot of extra markup and almost recreate the old table-based markup by creating columns, rows and blocks.

There's also an OOCSS (object-oriented CSS) trend; CSS files block rendering of the page until they are fully loaded, so it pays off to have your CSS files as small and lean as possible. By creating smaller sets of declarations in your CSS and sprinkling your HTML with classes to apply the right ones, the CSS file contains less repeating or overriding statements and ends up being smaller. The speed increase from the CSS loading faster tends to outweigh the size increase in your HTML file.

And of course as Maluco Marinero already said, many CMS's and frameworks add a ton of extraneous stuff since they need to cater to a lot of use cases and designs; their strength lies in having many options and being able to set something up quickly and easily, not in being highly optimized.

# ¿ Jan 18, 2015 14:04

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 18:29

Leshy: Jun 21, 2004

Loezi posted:

I have my doubts about the assumptions behind this.

Keep in mind that the reasoning is mostly relevant for large corporate websites where a few extra tenths of a second in pageloading times directly result in less conversion and revenue, and which can easily serve a few hundred KB of CSS. They want to get their pages � and most importantly by a wide margin, the first page a visitor requests � to load as fast as possible. Images and scripts form the bulk of the page size, but they are (or can be) loaded asynchronously either without the user noticing it or it not being an issue.

External CSS files can't be. Or rather, they can, but it leads to an unstyled, possibly dysfunctional page that suddenly re-renders as the proper styles are loaded. Leading to...

quote:

Many times, there's a reason you want (some of) your CSS to block the rendering. [...] serve the CSS in multiple chunks: Really basic CSS that provides a "usable but bad looking" user experience and blocks the rendering, followed by non-blocking "make it pretty" CSS.

Another way to solve the problem would be to embed the basic CSS in the .html file but then you are serving the same CSS with every page the user requests, making caching the "get-this-first" CSS file impossible. This is even worse.

You're mostly right, but not entirely.

In the ideal scenario you load all of your CSS asynchronously so that it doesn't block rendering. You identify the minimal amount of CSS that you need to properly style the part of the page that a user first sees when he visits your site and you inline that in your page. When a user visits, that page will immediately start rendering and apply the needed CSS to make everything look normal, while in the background the full CSS files load and style everything that the user doesn't see immediately.

To avoid the inline CSS from cluttering up each page and making the HTML files unnecessarily large, you set up a check for a cookie on the users system, which you set after the first page load. If the cookie isn't present, the user hasn't requested and cached your full CSS files yet, so you inline the critical CSS; if the cookie is there, so are the cached CSS files and no CSS needs to be inlined.

quote:

So you are adding essentially saving a few milliseconds from the fetch-to-first-view time but adding possibly hundreds of milliseconds more to the fetch-to-complete-site time. Is this a sensible trade off?

Essentially, yes. You want to retain users, and you do that by serving them (relevant) content. The sooner you start serving that content, the more likely you are to do that, even if it means that the page being fully loaded takes slightly longer. That doesn't matter too much if users are already able to engage with your site while it finishes loading (assuming that it doesn't lead to any jarring visual changes or important functionality being missing).

As a hobbyist, non-professional web designer I can't say how OOCSS compares to 'traditional' CSS in terms of maintenance or change time in a large-scale environment, so I can't comment on that. I would say that the user time is not non-noticeable if it leads to an increase in conversions, however. And all signs point to a direct 'less loading time = less users impatiently turning away' relation, so :v:

quote:

Furthermore, I'd say that going from "sensible and minimized" CSS to "really optimized" CSS should probably be the absolutely last thing to optimize in your website considering that 90% of websites built in the last year or so are serving the user absolutely huge background images for those fancy new parallax scrolling sites that everyone and their dog ignores.

I think generally users mind waiting for an image to finish loading less than they mind waiting for actual content to appear, but yes, it obviously isn't much use optimizing your CSS if you don't optimize the rest.

I don't really know of any completely neutral articles with a lot of data, but an interesting read I know of was Smashing Magazine's article on their optimization process which covers some of this topic.

Leshy fucked around with this message at 17:15 on Jan 18, 2015

# ¿ Jan 18, 2015 16:56

Leshy: Jun 21, 2004

The floats wrap automatically since they're in an element of fixed size; there's not a really good way to overcome that, as far as I know.

A quick and easy solution that seems to work fine from some testing in Firefox and Vivaldi (Webkit) is changing the individual result boxes from floats to inline block elements. Coupled with a white-space nowrap on the container, they'll line up horizontally without wrapping. A few tweaks to the overflow properties and it should work as you want it to, although you'd have to test it with whatever other browsers you're serving to make sure it works there too. These changes should do the trick:

code:

.result {
  display: inline-block;     // instead of float: left;
}

#results {
  overflow-y: hidden;
  overflow-x: auto;
  white-space: nowrap;
}

You'll have to add some height to the #results container too to accomodate the horizontal scrollbar.

# ¿ Feb 8, 2015 02:00

Leshy: Jun 21, 2004

Chris! posted:

If you could make me understand why the window.resize is ignoring the conditional, I'd be really grateful! I'm quite new to jQuery so this is a learning experience for me.

The window.resize is not ignoring the conditional.

If you load the window at a > 1024 size, it will attach the .hover() handler to the .hasDropdown li's. If you then shrink the window down to a < 1024 size, it will go through the conditional again and not attach the .hover() handler again, but since you're not removing it either, it will still be there from the previous time. The .hover() handler is basically a shortcut for checking the 'mouseenter' and 'mouseleave' events, so you'll need to specifically remove those in the else portion of your conditional:

code:

} else {  // for smaller viewports, the subnav is revealed by clicking the "open icon" and slides down.
  $(".hasDropdown").off("mouseenter mouseleave");
  $(".hasDropdown .open-icon")[...]

Also, .bind() and .unbind() have been superseded by .on() and .off(), so you might want to use those instead.

You may also want to consider moving the functions in your conditional to seperate functions, have them set a variable to true/false and only use the conditional to check whether the variable is set. Currently, every resize of the window > 1024 has the script setting up the .hover() functions all over, and every resize < 1024 sets up the .click() function all over. Your users will get better performance if the conditional only has to check whether the .hover() and .click() functions have been set, and do nothing if that's the case.

# ¿ Feb 11, 2015 10:49

Leshy: Jun 21, 2004

Chris! posted:

Hey, thank you for taking a look at this for me! That makes total sense and is a huge help.

No problem, good to hear it's working. The code you pasted seems to work fine.

quote:

But if the window size is small, and I hit the Maximize window button (or double click the title bar or whatever), the leftnav doesn't resize at all / it stays small. If I then resize the window manually, it resizes as required. The window.resize event is definitely being recognised, if I put an alert in there it fires as a window.resize event, but it's not resizing the content to match the image height. Any idea what I'm missing here?

Not sure about this one, though. By all rights, it should work - and the codepen example seems to behave just fine for me on the browsers I checked it in (IE, FF, Chrome, Opera, Vivaldi). Not sure what's going on if it isn't working properly for you.

# ¿ Feb 14, 2015 13:20

Leshy: Jun 21, 2004

I'm reminded of a question of my own.

Recently, I redesigned my personal website and took the step of building the CSS using SASS, which is indeed pretty awesome. Of course I did fall into the beginner trap of nesting styles too much, thinking more about organizing my SASS file neatly than the CSS output, which became needlessly verbose. I was also still using ids as styling hooks rather than classes, which I learned is somewhat frowned upon these days (or at the very least advocated against by a sizeable group).

So after some reading up, I decided to rebuild my SASS file and see whether I could reduce the resulting CSS file size. Using class selectors instead of ids did allow me to remove some code to deal with specificity issues and coupled with better nesting the file size came down nicely. I then wondered whether I could leverage SASS' @extend for further efficiency. Unfortunately, I didn't have (m)any elements which were similar enough to really make good use of them.

I did realise that I had quite a lot of font and color declarations sprinkled throughout my stylesheet and figured that making placeholders for those and extending these individual declarations might be more efficient. So I gave it a go, ending up with a SASS file that looks roughly like this:

code:

$serif:               'Georgia', 'Times New Roman', serif;
$sans-serif:          'Helvetica', 'Arial', sans-serif;
$color-default:       #111;
$color-page:          #eee;
$color-accent:        rgb(0,150,250);

[...]

%serif-regular        {font: 400 1rem/1.5rem $serif;}
%serif-large          {font: 400 1.25rem/1.5rem $serif;}
%sans-serif           {font-family: $sans-serif;}
%bold		      {font-weight: 600;}
%italic		      {font-style: italic;}

%bgcolor-default      {background-color: $color-default;}
%bgcolor-page         {background-color: $color-page;}
%bgcolor-accent       {background-color: $color-accent;}

%color-page           {color: $color-page;}
%color-accent         {color: $color-accent;}

[...]

nav {
  a {
    @extend %serif-regular;
    @extend %color-page;
    display: block;
    padding: 10px 20px;
    &:hover {
      @extend %color-accent;
    }
  }
  .active a {
    @extend %bgcolor-default;
    @extend %italic;
    @extend %bold;
    padding-left: 13px;
    border-left: 7px solid $color-page;
  }
}

h2 {
  @extend %serif-regular;
  @extend %sans-serif;
  @extend %bold;
  @extend %color-accent;
}

At first sight, this seemed like a terrible misuse of the extend functionality, but it does seem to work rather well. As long as the selectors are shorter than the declaration and the declaration is used several times throughout the stylesheet, you end up with a smaller CSS file. With the intended use of @extend, you still have to check the properties of a different element to see what styles are being extended, but in this way you still see what's happening as easily as with regular CSS.

In this example, you can tell at a glance that the h2 has the font settings applied for the regular serif font, which is changed to the sans-serif font, has bold applied and the accent color applied. With h2 being a very short selector, adding it to four declarations is more efficient than the other way around. It also makes it easy to apply multiple styles to an element without having to litter the HTML with classes as OOCSS does (which I'm not a big fan of) and it doesn't violate the DRY principle.

Admittedly, it does lead to a horrible CSS output where the styles for the h2 are spread across four different declaration statements, but most CSS these days tends to be viewed through a document inspector and I figure that ease-of-use is more important for the actual SASS file than for the minified output anyway.

Having said all of this, I still feel like I'm overlooking the reason why the above way of doing this is a terrible idea. I've Googled, but don't really come across any articles where this sort of use is discussed. All @extend examples seem to be about extending a full set of declarations for a standard item and then adding a few individual rules to it.

So yeah, to sum up: why is this a terrible idea and shouldn't I be doing this, or alternatively, why is this a pretty good idea and aren't people (discussing) doing this?

Leshy fucked around with this message at 18:13 on Feb 14, 2015

# ¿ Feb 14, 2015 18:11

Leshy: Jun 21, 2004

chami posted:

Here's a good set of guidelines to look at.

Thanks, I knew there had to be some good arguments why the above isn't a good idea. I think there's some points to be made against the relationship argument, insofar that this relationship only ends up existing in the output CSS file, which isn't something that anyone maintaining the project should be working on anyway.

The media query limitation equally isn't that much of an issue (for me), but I wasn't aware that gzip compression was so efficient in nullifying the duplicate statements as to nearly negate the file size savings. That pretty much makes the @extend method pretty much useless in itself, especially considering the drawbacks.

Thanks for the link, much appreciated. It contained links to a couple other good articles on the subject, so now I'm a little bit wiser than I was before!

# ¿ Feb 14, 2015 23:35

Leshy: Jun 21, 2004

ArcticZombie posted:

I guess I wasn't too clear. If you go to the website, you can see the problem in 2 ways. If you make the window narrow enough so you have to scroll horizontally to see the entire board, when you scroll to the right you'll notice the black bar does not extend to cover this area. Likewise, if you make the page short enough that you need to scroll vertically and then press the help button, you'll notice the white background does not extend down into that area.

These are actually two separate issues, but they're easy enough to fix.

The horizontal issue is due to the <body> being only as wide as the viewport, the part of the browser window that displays the website. When it's contents are wider than that, the <body> doesn't stretch out to accommodate, but the contents overflow outside of it. So your #banner item fills up 100% of the <body> width with the dark background, but the #header and #main items overflow out of the <body>, and you see the background color not continuing on. You can easily see what's going on if you apply a few colored borders to the <body>, #header and #main.

The easiest fix for this would be to give the body a min-width: 650px, so that it is always wide enough to accommodate the game board.

The vertical issue of the #help background not stretching all the way, has to do with positioning. When you position an item absolutely, it is positioned within its first parent that has relative or absolute positioning itself. The <body> by default has position: static, so your #help item is positioned within the <html> element, which is always exactly as wide and high as the viewport. Here too, your #help background matches that width and height, and scrolling reveals it not continuing on.

Setting the <body> to position: relative will position the #help within the <body> element instead and make it cover the entire page.

E:F,B: And different solutions, too!

Leshy fucked around with this message at 12:23 on Feb 18, 2015

# ¿ Feb 18, 2015 12:14

Leshy: Jun 21, 2004

ArcticZombie posted:

Thanks to both of you, I've implemented the the first solution as I had already done so before I saw the second post. Is there any gotcha's with either solutions that would make the other better?

Both solutions work from a technical perspective and shouldn't lead to any problems.

I personally do prefer mine since they don't require the adding of extra elements/CSS, adhering a bit better to the KISS principle and keeping your code leaner.

# ¿ Feb 18, 2015 23:52

Leshy: Jun 21, 2004

The idea of using partials is that you split up your CSS into easy to read and manage chunks. If you later want to change some fonts on your site, you don't have to search through your complete CSS file for all the font statements, but you simply open up _typography.css and have them neatly organised right there.

It is a bit more work when you write your CSS for the first time as you have to pay attention as to which declarations go into what file, but it makes management after that easier. It really depends on what kind of site you are running, how much CSS you have to begin with and how many other people will be editing the site in the future.

Are you running your own small-scale homepage with a limited amount of pages and little CSS? Then decide for yourself if using partials is worth it (but if you're already using SASS, why not?). Are you managing a large-scale site which has a ton of CSS and which will have other people working on it in the future? Then splitting up your working files into easy to use, documented partials might be a good idea.

Lumpy posted:

to me, typography is headers, body copy, lists, etc. Buttons and navigation aren't those things, they are "functional".

Typography is the art of setting text. The color of the button itself isn't typography, but the font-size and line-height of the text on the button are.

down with slavery posted:

The reason you do this is to ensure that EVERY button looks the same.

While your post is otherwise correct, using partials doesn't ensure this at all and visual consistency isn't the reason to use them

Leshy fucked around with this message at 21:11 on Mar 10, 2015

# ¿ Mar 10, 2015 21:03

Leshy: Jun 21, 2004

Lumpy posted:

Correct, but for breaking up my styles into partials, I think of that as belonging in a _controls file rather than the _typography one.

Of course, you're entirely free to use partials however you want. As long as you're consistent and any people you might work with are on the same page, it's all good. But see also below:

caiman posted:

Just to be clear, I am using partials. It's just that none of my rule sets are divided up between multiple partials. The rules for .button are included in one, and only one, .scss file.

Imagine that six months from now, you decide on a different font for your site; say you've decided to get a subscription to a webfont service and you're switching from Arial to Proxima Nova. The fonts don't entirely match up in size, so you'll have to do some tweaking to make sure everything fits nicely.

If all of your typography CSS is in a separate _typography.scss, you open that up and see exactly where you've declared what font and which elements are using which variations. Did your .button use a bolded, 2px larger version of the default 16px Arial? Easy enough to make the necessary changes so that your Proxima Nova text fits nicely onto the button as well.

Or did you decide to keep your font styles together with the class when you declared it? Now you're going to have to hunt it down. Did you declare .button in your main stylesheet, or did you consider it a control and did you put it in your partial _controls? And where did you put the font styles for that dropdown box in your navigation bar? Was that in _controls too, or was that in _navigation? And in what other partials did you also make font declarations that you'll have to adjust? Better go check them all.

# ¿ Mar 11, 2015 00:16

Leshy: Jun 21, 2004

unpacked robinhood posted:

Anyone with a clue as to why the pictures in my gallery open halfway in the bottom of the page instead of using the existing space on screen ? I used a jQuery plugin called Boxer

Got a link to an example page where the issue happens? It's hard to tell where it's going wrong from just a screenshot.

# ¿ Mar 11, 2015 10:03

Leshy: Jun 21, 2004

I would say that the consensus for that scenario is: don't, but it depends on the mail.

Spam e-mails frequently include an (invisible) image that's hosted, allowing the spammers to see where and how often their mails are viewed based on the requests for the image. Many mail clients block images by default to prevent this. Generally they will offer the option to "always allow images from this sender", accompanied by a warning about the risks involved. If your recipients know who you are and choose to accept images in your mails, this is the best solution. If they don't know who you are, do not trust you or are less tech-savvy, the warning may add an air of insecurity to your mails.

Sending the image as an attachment should avoid the issue, but it does make your mails considerably larger, impacting both your own and possibly your recipient's bandwidth. You are also sending them mails which display as having attachments, when in reality you're not sending along any files with your e-mail that you want them to download and check, just some decoration for the e-mail itself.

If you're sending out a newsletter, marketing mail or anything that needs to be branded, by all means use HTML e-mail with hosted images. For your day-to-day correspondence via e-mail, I would stick with not using images and applying your branding through typography only.

# ¿ Mar 11, 2015 15:57

Leshy: Jun 21, 2004

Does anyone know why Google and Bing seem to be ignoring my robots.txt and displaying images from my site in their search results when they should not be allowed to do so?

The other day I was checking my access logs for something, when I noticed a handful of requests from Googlebot and Bingbot to some images that they shouldn't have access to, according to my robots.txt. A search on both Bing and Google showed that their image search results are in fact returning a number of images from folders on my site that are disallowed and have been for a long time. My robots.txt:

code:

User-Agent: *
Disallow: /istanbul/img/
Disallow: /luxemburg/img/
Disallow: /praag/img/
Disallow: /kroatie/img/

I checked the Google help files, and they explicitly state that folders of images that should not show up in GIS, should be disallowed via the robots.txt file. Webmaster Tools tells me that the robots.txt is being properly read, and when I enter the URL of one the images, it also tells me that it is being blocked. Except I am looking right at that image at that URL in Google Image Search. I can't really find any detailed instructions for Bing, but I assume pretty much the same goes for them.

I've tried throwing an .htaccess file into the image folders, only allowing my own domain as referer (or empty referer), but that actually breaks them from displaying on my own pages in most browsers, and doesn't prevent Google or Bing from listing them either.

code:

RewriteEngine On
RewriteCond ${HTTP_REFERER} !^$
RewriteCond ${HTTP_REFERER} !^http(s)?://travel\.leshy\.net [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

I'm a bit stumped as how tell Google and Bing: do not index these images and remove the ones you already did from your image search results. Anyone have a bit more experience with this?

# ¿ Mar 17, 2015 10:30

Leshy: Jun 21, 2004

bartkusa posted:

If you have the copyright to those images, then I guess Google is violating your copyright, therefore maybe you can DMCA them?

Throwing the DMCA at Google might be a bit much and I'm not entirely certain it's applicable in this case.

It's not that there are photos in there which really need to be off of Google and Bing right now, it's more that I'd rather have them not listed there and I thought I had taken the appropriate steps to prevent that. In addition, DMCA'ing them will likely not prevent their crawlers from re-indexing those images again at some point in the future, if they managed to do so the first time. I'd prefer to find the correct technical solution.

Thanks for looking into it and finding a good suggestion, though!

# ¿ Mar 18, 2015 14:43

Leshy: Jun 21, 2004

The Merkinman posted:

Any idea why Foundation and Flex-box don't get along or what exactly is going on here?
In Chrome and IE, the padding to the right of 'add' gets ignored so the copy isn't centered. Not including foundation fixes the issue, but I don't see why. All I see is the calculated width is different, but I don't see WHY it's different. Firefox doesn't have the issue.

That took way too much time figuring out, but it was a nice puzzle!

Both the textbox and submit button are flex items, due to the display: flex; statement on the parent div. That means they want to sit next to each other on the same line. The imported Foundation ~~6000-line monstrosity~~ stylesheet, however, contains the statement input[type="text"] {width: 100%;}, which makes the browser attempt to give the textbox as much width as possible. As the submit button is a flex item, it can be shrunk down to give the textbox more horizontal space.

Apparently Gecko and Trident/Webkit have a different opinion on how far it is allowed to be shrunk down. Gecko (Firefox) will not shrink the flex item down beyond the width of its content, whereas Trident (IE) and Webkit (Chrome, Vivaldi, Opera) will do so. This causes the content to overflow over the right padding, giving the illusion that the right padding is ignored, which it isn't. The statement flex-shrink: 0; on the submit button will tell the browser that it should not be shrunk, which fixes the issue.

See this jsfiddle for a more minimal example.

# ¿ Mar 30, 2015 21:11

Leshy: Jun 21, 2004

Yes, that is exactly what the flexbox layout system is for. See http://jsfiddle.net/ujrk8Lcj/.

Edit: VV No problem! See https://css-tricks.com/snippets/css/a-guide-to-flexbox/ for some more info on flexbox and its properties.

Leshy fucked around with this message at 17:10 on Apr 18, 2015

# ¿ Apr 18, 2015 17:00

Leshy: Jun 21, 2004

That's a bit of a broad question, really.

Not every browser and operating system will display fonts the same, due to varying implementations of font rendering, hinting and smoothing. Especially at smaller font sizes this can lead to differing appearances between browsers. It is, as far as I am aware, pretty much impossible to predict and simply requires testing. Most good serif fonts should have no problem displaying at 16px, but if you are having issues then your options boil down to adjusting the design of your page to accommodate larger font sizes or simply picking a different font.

Another thing to keep in mind is that web fonts come with a few caveats. What happens when the web font is slow to load or does not load altogether? If you go the route of hiding your text until the web font has loaded, this may provide the user with a page in which the content appears noticeably late (or worse, not at all). If you opt for using a fallback font, then your user will likely experience a flash of unstyled text (FOUT), which may be jarring. Many sites therefore choose not to use web fonts for actual body copy, but limit them to headings and the like.

Also note that web fonts do not work for e-mail. Since your e-mail correspondence is going to be in a default font anyway, it might also not be a bad idea to use a default font on your website for copy and match that to your e-mail font for better visual consistency between those two.

I don't really know of a good primer on web fonts, but if you want a number of good web fonts, then generally browsing the 'popular' category of web font services (Typekit, Google Fonts, FontSquirrel, Fonts.com) will provide you with suitable and usable fonts. There's this article from 2012 on good fonts for body copy as well.

# ¿ Apr 28, 2015 13:18

Leshy: Jun 21, 2004

o.m. 94 posted:

ugh i am you intolerable poo. That's not the question I asked

It's a bit unclear what you're asking then.

A duplicate lang attribute shouldn't really hurt anything, but why are you serving multiple language versions of the same element in the first place? If you handle localization server-side, you set the language attribute on the html element and then only serve the appropriate language version of your content. In that case you shouldn't end up dealing with duplicate lang attributes to begin with.

Edit: Upon rereading your original post, I think you are trying to say that you are serving a page where not all the content may have a French translation, and in cases where it doesn't, it defaults to English. Your example is somewhat confusing in that case, as you included two <h2> elements which suggests you're serving both versions at the same time, and you also wouldn't have a French text appear in a page set to English.

If this is the case, you apparently have some server-side logic that grabs the English content whenever a French translation is unavailable. It should not be too hard to modify that logic to add an appropriate lang attribute in cases where it does, which seems more efficient and a better way of doing things than always setting the lang attribute on everything.

Leshy fucked around with this message at 09:49 on May 7, 2015

# ¿ May 7, 2015 09:37

Leshy: Jun 21, 2004

MoosetheMooche posted:

Sorry for the rudimentary questions, if anyone has the time to help me out, I would really appreciate it.

No problem, that's what we are here for! Your menu looks pretty good, but as you have noticed, using a list with floats leads to some problems, which makes it tricky to deal with. Fortunately, everything is easily fixable. I've made a Codepen for you: http://codepen.io/anon/pen/zGqKBN. It may require some explanation, so here goes:

First of all, do not use # (ids) for styling CSS, only classes. This makes it easier to avoid specificity issues where some CSS takes priority over other CSS. It is a good practice to adopt and you should do this.

Second, don't use floats. While powerful, they lead to all sorts of messy situations that can be tricky to deal with. The float: left; on your <ul> prevents it from centering, for example. By setting display: table; and margin: 0 auto; instead, you are essentially saying "Make this a block as wide as it needs to be" and "I want an automatic equal margin on the left and right", which centers your menu.

You can then make the <li> elements line up horizontally by either setting them to display: inline-block or display: table-cell. Since we set the <ul> to display: table, I've gone with the latter.

These things will make your menu center nicely. Your next question was how to prevent the link to the current page from being a link:

The short answer is that you can't. At least, not with HTML/CSS. You can do it with things like PHP or JavaScript, but you really shouldn't bother. You could style the link so that it does not appear to be one and have the cursor not change upon hovering over it, but best practice is to apply a class, such as .active, to the link and style it in such a way that the user can see that they are currently on that page and have them decide whether they want to click it or not. You could, as I have done in the Codepen, not apply the :hover effect to the active link to give some extra indication that you do not need to go there.

And your last question was how to add a website title to the menu that isn't a link.

This is easy enough by simply adding a <li> that contains a <h1> or something instead of an <a>, but... you should not have the website title in the menu bar, right next to a link saying "Home". People are pretty accustomed to being able to click on a website title or logo to go back to the homepage, so if you add the website title to the menu, get rid of the "Home" link, and make the title link to the homepage. I have done this in the Codepen.

Hope this helps!

Edit: Fixed the link and removed something that wasn't really necessary.

Leshy fucked around with this message at 12:08 on May 13, 2015

# ¿ May 13, 2015 10:30

Leshy: Jun 21, 2004

Note: If you're randomly redirecting people to different varieties of a survey, check on whether it is important that you end up with a (roughly) equal amount of each survey. The above solution is truly random, and may have you end up with 80% going to survey variant 1, 15% to survey variant 2 and 5% to survey variant 3, which could invalidate your survey results.

Building in something to equalize it is much more complex, in which case you might be better off setting up a survey with LimeSurvey or some such.

# ¿ Feb 2, 2016 09:42

Leshy: Jun 21, 2004

My first thought was "too little, too late", with SASS etc. already having adequately addressed them. But then I read that link, and realised that having them available to modify at runtime actually makes them very useful.

It's going to be annoying having to provide and manage fallbacks during their period of adoption, however.

# ¿ Feb 9, 2016 19:25

Leshy: Jun 21, 2004

On the earlier topic of CSS variables, I actually have a site that is the perfect use case for them, but I am not quite sure on the best method to implement them with a proper fallback.

It is a site with multiple sections, which each have their own accent colour; this affects the font colour of some elements, the background colour of some others, as well as a few border colours here and there. It is currently set up so that the PHP template inserts a <link> tag to a small secondary stylesheet that sets the appropriate colours for that specific section. Works perfectly fine, but it does add several requests and a downloads (albeit very small) when navigating through various sections, and it requires the maintenance of several of these stylesheets in addition to the main one.

With CSS variables, I can simply have the PHP template insert "<style> :root{ --accent-color: [section-colour];} </style>" into the page to replace all of that, which is of course a very enticing prospect. However, as of course wide-spread support of CSS variables is still a while off, I'd like to keep the above method as a fallback for browsers that do not support CSS variables, for the time being. That means I can't rely on the built-in CSS variables fallback.

I essentially need to build in a "Do you support CSS variables? If so, here is <style> --accent-color: [blah] </style>. If not, here is <link src='accent-color.css'>." check. The most straightforward way of doing this that I can see, is doing some browser sniffing and checking the useragent for browser version, then presenting the appropriate solution. However, as browser sniffing is it's own :can:

, I could use some input on whether this is a good idea or not or whether there is a better way of approaching this.

# ¿ Feb 14, 2016 20:22

Leshy: Jun 21, 2004

Sergeant Rock posted:

You could look at the new-ish '@supports' feature query. So apply your fallback styling by default, then use @supports (in JS or CSS) to see whether native variables are available...

See https://developer.mozilla.org/en/docs/Web/CSS/@supports

Sedro posted:

You could use CSS.supports('--accent-color', 'blah') but that won't work in IE. If you care about IE you can create some DOM using CSS variables and examine the output with getComputedStyle.

Thanks a lot both for your suggestion; I didn't know about CSS.supports yet, and it's pretty much the perfect answer to what I needed!

After some Googling, I ended up writing basically this snippet of JavaScript, which sets a CSS variable for browsers that support it, and links a second stylesheet with colour overrides for browsers that do not support it. As MSIE does not and will never support CSS variables anyway, I do not need an alternative solution for it in this case.

code:

  if (window.CSS && window.CSS.supports && window.CSS.supports('--css-variables', 0)){
    var nodetext = document.createTextNode(":root {--color-accent: <?php echo($color); ?>;}");
    document.getElementsByTagName("style")[0].appendChild(nodetext);
  } else {
      var node = document.createElement("link");
      node.setAttribute("rel","stylesheet");
      node.setAttribute("href","accent-<?php echo($color); ?>.css");
      node.setAttribute("media","all");
      document.getElementsByTagName("style")[0].appendChild(node);
  };

Note: I believe it's not considered good practice to insert PHP variables directly into JavaScript like this, but as the variable in this case is being set by the PHP script itself and does not rely on any user input, it seemed to be the most straightforward way of doing it in this particular case.

Leshy fucked around with this message at 16:22 on Feb 17, 2016

# ¿ Feb 17, 2016 16:19

Leshy: Jun 21, 2004

kedo posted:

Seems like you're using a twenty ton nuclear powered pneumatic hammer to drive a nail.

Quite probably, yes. But isn't it a lot more fun to play around with and learn how to operate a twenty ton nuclear powered pneumatic hammer than a regular one, even if you only have a nail?

Your solution would work, but it's not a very efficient one either. As the CSS file for each accent colour consists of over a dozen selectors (text colour, background colour and various border colours across multiple media queries), and there are currently five diffferent colour sets with likely more being added in the future, that would add quite a chunk of CSS to the main stylesheet. Factor in having to declare every colour twice (once by CSS variable, once by fallback colour) and it quickly becomes quite a lot. In addition, it doesn't seem very elegant or efficient to serve visitors all the code for five (or more) colour schemes when they may only need one or two.

The true simple solution would be to simply add a few variations of class='accent-color' throughout the HTML, so that you only need to style and override this handful of classes. However, going through all of the pages to add these classes to every element that needs them is not the most enticing prospect, and I am personally not a fan of the trend to sprinkle the HTML with a million-and-one classes to begin with either.

# ¿ Feb 17, 2016 19:42

Leshy: Jun 21, 2004

It's a hobby project, so there's no cost involved, and otherwise I wouldn't even start on implementing CSS variables yet

I just quickly checked out of curiosity, and adding in the declarations for all the colours to the main stylesheet would increase the size from ~15KB to 22.5KB (+1.5KB per colour) when compressed. Not much either way in absolute terms, but that's a huge relative increase. I'm pretty okay with a solution that serves an additional 1KB stylesheet when needed and if the browser does not yet support CSS variables, and requires literally only a single CSS declaration in the <head> for browsers that do.

# ¿ Feb 17, 2016 21:25

Leshy: Jun 21, 2004

The Wizard of Poz posted:

Also why are you setting colours inside media queries? Are they actually different colours at different display sizes?

There's only one colour for each section, but some elements are differently styled at different display sizes, yes; most notably the menu items.

The Wizard of Poz posted:

How? Do you mind posting an example of one of these colour sets?

Note that the mentioned figure of 1.5KB is based on the notion of having to add both .accent-color to each selector and declaring each color twice (both as a CSS variable and as a fallback colour), which would be required if they were to be merged into the main stylesheet as per the suggestion above, which ends up roughly doubling the CSS output.

This is an example set of SASS styles which compile into a 0,7KB CSS minimised CSS file.

code:

aside, h1, .backtotop, .photogrid span, .pg-previous, .pg-next {
  background-color: $color-accent;
}

.menu-button {
  &.active, &:hover {
    border-color: $color-accent;
  }
}

article>ul:not(.photogrid) li::before, footer a:hover, a, blockquote p, cite, .site-title, .nav-secondary a:hover, .intro, h2::before {
  color: $color-accent;
}
  
@media all and (max-width: 1023px) {
  .nav-primary ul {
    background-color: $color-accent;
  }
  .language-bar a:hover {
    color: $color-accent;
  }
}

@media all and (min-width: 1024px) {
  .nav-primary a:hover {
    color: $color-accent;
  }
  .nav-primary .active a, .language-bar .active {
    background-color: $color-accent;
  }
  .nav-secondary .active a {
    border-color: $color-accent;
  }
  .language-bar a {
    &:hover {
      background-color: darken($color-accent, 10%);
    }
  }
  .prev-link {
    border-top-color: $color-accent;
  }
  .next-link {
    border-bottom-color: $color-accent;
  }
}

# ¿ Feb 17, 2016 22:03

Leshy: Jun 21, 2004

ModeSix posted:

Create separate stylesheets for the theme specific colors and have TWO stylesheet links, one for your generic sheet and one for your color specific sheet. Using the exact same style property naming in all the sheets.

I haven't written php in about 10 years and yeah I think I just came up with a way better and much easier to maintain piece of code than you've written.

You didn't follow the discussion very well; the method you describe is pretty much exactly what I am using at the moment.

The point is that with CSS variables, that second stylesheet is no longer needed at all. You declare the colours for the elements as a CSS variable in the main stylesheet, at which point you only need the page to re-declare the CSS variable to update all colours as appropriate, which you can do with a single declaration in the <style> tag. Hence I was looking for a solution that specifically says:

1. Does the browser support CSS variables? If so, add "<style> :root {--accent-color: [section-color]} </style>" to the page.
2. Does the browser not support CSS variables? Then add "<link rel='stylesheet' href='styles-[section-color]'>" to the page. [eg. the secondary stylesheet from your solution, which is already what's in place].

Hence, I added a small piece of JavaScript to the page which does exactly this through feature detection. As I have the required section-color in a variable in the PHP template alrady, it made sense to pass it directly into the javascript.

Fake edit: I realised after logging off yesterday that I made a thinking error with regard to the 'throw everything in the main stylesheet and switch through setting an class on the body' yesterday. It doesn't require setting all colours twice, so would be slightly less of an increase in CSS size. However, it also directly negates using CSS variables (which declare everything once, rather than declare everything n times for each colour) and requires the continued maintenance of the same extra stylesheets (now as partials), making it not really very different from the current situation.

As previously said, this exercise was specifically to build in support for CSS variables for browsers that support it.

# ¿ Feb 18, 2016 09:00

Leshy: Jun 21, 2004

The Wizard of Poz posted:

I can't figure out what you mean by this and can only assume I'm missing something obvious.

I meant having to provide a fallback colour for every declaration where you use a CSS ~~variable~~ custom property, like this:

code:

h1,  h2, h3 {
  color: #f00;
  color: var(--css-color);
}

aside, footer, .inset {
  background-color: #f00;
  background-color: var(--css-color);
}

.button-previous, .button-next {
  border-color: #f00;
  border-color: var(--css-color);
}

And so on for each time you declare a CSS custom property. Although in my initial response, I overlooked that if you end up putting all your colour declarations in the same stylesheet and switch through a class tag on the body, it obsoletes the use of CSS custom properties altogether, which was against the point of my exercise to begin with (to implement the use of CSS custom properties for browsers supporting it).

Heskie posted:

Just seen this article in a newsletter that may help you out:
https://justmarkup.com/log/2016/02/theme-switcher-using-css-custom-properties/

I saw it too, it was mentioned on Smashing Magazine I believe

The basic solution that this article uses is indeed the one that I ended up using as well, so it would have indeed been helpful. The article doesn't really provide any fallback beyond "serve a basic colour that does not change to incompatible browsers" either, however, although their use case also differs somewhat from mine as I don't need on-the-fly theme switching.

# ¿ Feb 23, 2016 19:50

Leshy: Jun 21, 2004

There are multiple survey tools out there that can easily do these things. Popular ones include SurveyMonkey and LimeSurvey, although there must be a dozen others. Google Forms probably also allows you to do this, although I don't know whether it can do one of these 'result calculations' at the end.

# ¿ Nov 21, 2021 08:27

Leshy: Jun 21, 2004

outline: 1px solid red; superiority.

Although border is so muscle-memory-ingrained that I use it all the time as well.

# ¿ Dec 10, 2021 21:37

Leshy: Jun 21, 2004

I was going to make a joke about that page certainly having to be accessible via the URL https://www.geocities.com/tokyo/yahoo, but had to look up the most appropriate neighbourhood name on Wikipedia. Then I read the following snippet: "The GeoCities Japan version of the service endured until March 31, 2019."

So yeah, up until recently, it may very well have been :v:

Leshy fucked around with this message at 10:47 on Feb 10, 2022

# ¿ Feb 10, 2022 10:45

Leshy: Jun 21, 2004

Cory Parsnipson posted:

I sat down today and made a pie chart component instead of doing something important. (link to demo) I accidentally had a lot of fun.

I recently went through a similar exercise, except that for ~reasons~ I had to do it in vanilla HTML/CSS only :suicide:

I wanted to create something that would be easy to modify and re-use, that was as accessible/responsive as possible, and allowed for copy-pasting the data. It turned out to indeed actually be quite a fun exercise to do, and I was pretty pleased with the result. Being able to layer on some JS would drastically reduce the CSS required and further simplify the HTML, but for a super vanilla solution, I think it works well enough (Link to Codepen).

I ended up using the system to also create a bunch of horizontal and vertical bar charts, which are actually also quite tricky to get right.

Leshy fucked around with this message at 00:54 on May 12, 2022

# ¿ May 12, 2022 00:51

Leshy: Jun 21, 2004

As per the W3C specification, the overflow value 'visible' for either -x or -y is treated as 'auto' if the other one is not set to either 'visible' or 'clip'. See also the MDN overflow entry.

If you set your overflow-y value to 'clip', then the outlines should correctly show on the left and right hand side ('visible' is now actually 'visible'), while they should not show on the top or bottom if they were to overflow in those directions.

As for why this is the case, you'll need someone wiser than me.

# ¿ Jul 6, 2022 00:12

Leshy: Jun 21, 2004

How should the browser then deal with overflowing content on the x-axis colliding with the scrollbar it needs to display on the right hand side of the container for y-axis scrolling?

(Incidentally, I now realise that is why the 'visible' and 'clip' values only work with either value on the other property.)

Leshy fucked around with this message at 06:41 on Jul 6, 2022

# ¿ Jul 6, 2022 06:37

Leshy: Jun 21, 2004

I think the behaviour that you want can be achieved by setting a grid on the container, with a vertically wrapping flexbox on the container for the lists. See https://codepen.io/LeshyNL/pen/BabqMKr

The left-hand grid cell with the lists will be as wide as it needs to be to fit all columns, and the lists will show vertically as long as they fit, then wrap into additional columns as necessary. Which I think is what you want?

# ¿ Feb 12, 2024 00:27

Leshy: Jun 21, 2004

The Merkinman posted:

If you set the height to something smaller, so that the list doesn't fit in one column --height: 400px ... it does weird stuff.

With the current lists in the CodePen, it looks as expected down until about a minimum height of 260px, where the number of columns starts exceeding the width of the container. Changing the explicit width on the lists to flex: 0 1 166.67px will alleviate it a little bit by allowing the lists to shrink as needed, but again you will hit a lower limit at some point.

In the end, the lists are individual items that will not break into multiple columns, and when you have more lists or longer lists than the container can handle, you will have issues. If you also want the individual list items to wrap into new columns, you would have to put all list entries and headers into a single list � that would allow flexbox to automatically wrap them correctly, but you would lose the individual list semantics. This is pretty similar to what your suggested JS-based solution would do, by evaluating each individual list item and placing it manually.

This exercise shows why fixed sizes are generally not recommended in webdesign, especially when dealing with variable content. The moment you end up with an unexpected amount of content, things will break in one way or another and you're going to have to set up a bunch of contingencies to deal with those. Having said that, I do not know what your specific use case is here.

# ¿ Feb 12, 2024 21:45

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 18:29

Leshy: Jun 21, 2004

Ah, you're right. On Firefox (and presumably Safari) the auto setting on the Grid container does not play nice with the actual width of the flexbox it contains.

Setting it to fit-content should work: https://codepen.io/LeshyNL/pen/BabqMKr

# ¿ Feb 13, 2024 22:56

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread