I'm currently developing a responsive site and I'm also trying to keep the code nice and resuable. Now I've got a certain element text aligned right and I'm using a generic align-right class in case I want to use it later on. What just came to my attention is I don't want this element to be aligned right when the viewport is small so I can simply change .align-right to actually align the text to the left under a certain media query rule. However this is obviously illogical in terms of class naming so I was wondering what anyone on here does in this respect? I could make the class name more generic, e.g. "align" and set alignment in the CSS depending on the element but this defeats the object of being able to create one style rule and reuse that in the HTML as and when.

Well, I suppose you can by including both classes in the markup, say

<p class="left">...</p>
<p class="right">...</p>

CSS

.left { text-align: left; }
.right { text-align: right; }

and have one class with display: none; in the main CSS file and the other with display: none; in the media query style for the narrow page.

 

Forget the above. You should be able to do it just by including the same class in the media query with the different alignment, as long as the media query style is after the main stylesheet link, it won't apply to wide pages, only to the narrow page.

Edited August 8, 201214 yr by Wickham

Well, I suppose you can by including both classes in the markup, say

<p class="left">...</p>
<p class="right">...</p>

CSS

.left { text-align: left; }
.right { text-align: right; }

and have one class with display: none; in the main CSS file and the other with display: none; in the media query style for the narrow page.

 

Forget the above. You should be able to do it just by including the same class in the media query with the different alignment, as long as the media query style is after the main stylesheet link, it won't apply to wide pages, only to the narrow page.

 

Yes which is what I am settling for at the moment, deadlines and what not, but that's my point.

 

Say I have, <p class="align-left">words</p>

<p class ="align-right">words</p>

 

That's all well and good for my larger layout but for smaller ones I have to change the rule for "align-right" to "p.align-right: text-align:left;" So my point was this naming method is illogical. On smaller layouts the HTML says the class is aligned right but the CSS says it's aligned left.

In your media query you would have

.align-right { text-align: left; }

and in the narrow page all text from both styles would be aligned left.

In your media query you would have

.align-right { text-align: left; }

and in the narrow page all text from both styles would be aligned left.

 

I know how to do it and that is exactly what I'm doing. My point is the class name is illogical, i.e. it says align-right but the text is aligned left. So my question was, how do other people approach this.

Probably by using different class names so that it doesn't seem so illogical.

Don't attach semantic classes to elements like that and you won't have a problem. Just target the element more specifically in your css, keeping your markup lovely and clean, e.g.:

 

 

@media only screen and (min-width: 48em) {

[role=main] article {text-align:right}

}

Don't attach semantic classes to elements like that and you won't have a problem. Just target the element more specifically in your css, keeping your markup lovely and clean, e.g.:

 

 

@media only screen and (min-width: 48em) {

[role=main] article {text-align:right}

}

 

That would make all elements in article tags across your site align right. Assuming only a few things need that right alignment you need to give the elements classes, which need to be named. Say I have a bit of text in the footer that I want to align right then a bit of text in the main content somewhere, it's good practice to have a generic right-align rule instead of giving those 2 elements (plus potentially many more across the site) separate CSS rules each doing the same thing. A problem then arises when you want to adjust those rules according to viewports/media queries.

 

The only solution I can think of (I think this would work, it's late and I'm tired) is to give an element both align-right and align-left classes and use !important where relevant to override whichever rule based on the current media query. I can see that getting quite messy though.

That would make all elements in article tags across your site align right.

 

No, it targets only article elements in the main content area. It could easily be made far more specific to target only a single element, providing a flexible way to style elements that doesn't add uneccessary hooks to your markup.

No, it targets only article elements in the main content area. It could easily be made far more specific to target only a single element, providing a flexible way to style elements that doesn't add uneccessary hooks to your markup.

 

Though that is a solution, it's quite limited because you're relying on elements to have ARIA roles in your markup which you should only add where relevant not in regards to CSS, therefore I think you'd still end up having to use a CSS class. For example what if you had some content in an article tag where for whatever reason half had to be left aligned and half right but only on large screens. You couldn't target the element the way you described because that would target the whole article, thus you would need a CSS class and in turn you would need to name it which brings the problem right around again. Also that goes against my initial intention of having one generic right-align class rather than having to define the style for each right-aligned element.

 

Relying on HTML5 tags seems potentially problematic.

 

I'm not losing sleep over this , it seems like a catch-22 kind of thing, just thought it was worth asking/discussing.

Edited August 9, 201214 yr by jtuds

Dude, it was just an example. It doesn't have to target the elements role, you just need to add some specificity and you can target any element you want. My point was, add specifics to your css not your markup. Separate style from structure.

 

For example what if you had some content in an article tag where for whatever reason half had to be left aligned and half right but only on large screens. You couldn't target the element the way you described...

 

Sure you could. Something like;

 

@media only screen and (min-width: 70em) {

[role=main] article:nth-child(3) span {text-align: right}

}

You're completely right about it being a catch 22.

That's the problem with semantic CSS classes, you need to name them semantically without being to direct (is that even possible?)!

 

So .leftalign would be more descriptive of it's actual function such as .mainalign and .secondaryalign which themselves may not seem to semantic until they're paired with main content and secondary content. It's not ideal but it's probably the only smart way to go about it.

 

 

I also find it really silly when the function of those semantic classes will not remain constant throughout the stylesheet. You inevitably run into the situation when you write something like;

 

.floatright {float: none}

 

At that point it becomes clear that there is a basic flaw in such a method. Don't get me wrong, I used to do such things all the time myself. I frequently used to use .last for example to right-align grid elements. The problem with doing that in a truly responsive (not just a fluid) design is that the 'last' position does not remain the last position accross all viewports. In such cases classes like .last and .floatleft are not only non-sensical, they are counter-intuitive (if not downright mis-leading).

To be honest,

I also find it really silly when the function of those semantic classes will not remain constant throughout the stylesheet. You inevitably run into the situation when you write something like;

 

.floatright {float: none}

 

At that point it becomes clear that there is a basic flaw in such a method. Don't get me wrong, I used to do such things all the time myself. I frequently used to use .last for example to right-align grid elements. The problem with doing that in a truly responsive (not just a fluid) design is that the 'last' position does not remain the last position accross all viewports. In such cases classes like .last and .floatleft are not only non-sensical, they are counter-intuitive (if not downright mis-leading).

 

What should it be then? What grid do you use now?

 

I do use last, but to me it's okay because it's where the last information in a column or row goes. Whether it's a row or column makes no difference, it's still last.

I build a custom grid to suit the design at hand, so I have no extraneous layout code.

 

In my designs the layout is never that static that .last makes any sense apart from at a single defined viewport range. Imagine this scenario; a layout comprising 4 evenly sized blocks. At 'mobile' views I want those blocks stacked vertically, at 'tablet / small-notebook' sizes I want a 2x2 grid and at larger desktop views I want all 4 blocks in a line horizontally. As I want my blocks aligned flush with the container I apply a right margin to those elements and then remove that on the "last" item. You see the problem? In a 2x2 grid there are 2 'last' positions, dropping to only 1 on a larger screen.

 

For the same reason, I dislike frameworks like Bootrap that define item widths with markup classes. Once you do that you are either stuck with fixed widths or you are doing totaly non-sensical stuff in your stylesheet, e.g.

 

.sixty-percent-width {width:100%}

 

*a 'for example purposes' selector you understand

Last does make more sense than left/right. Last has a structural meaning whereas right/left are presentational but again you get an issue when what you're naming "last" is purely for styling reasons and the element isn't structurally last. I'm thinking a middle ground of say, "float-2" may be the answer, not semantic but the numbering allows you to define a certain generic rule in the CSS so as the developer you know if an element is going to float left or right by using 1 or 2 then from a semantic perspective it doesn't matter if those numbers change like it does if you have the words left and right.

 

@Inspired, that's the point, with responsive your wonderfully labelled tags become illogical when you start changing layouts. Maybe it's just the case that there isn't as much room for that kind of class naming in responsive layouts.

 

...I don't think it matters how your elements are displayed, last is last in a structural context, i.e. the last section in the HTML. In my opinion, that section remains structurally last regardless of the order it actually appears to be in.

Edited August 10, 201214 yr by jtuds

@Inspired, that's the point, with responsive your wonderfully labelled tags become illogical when you start changing layouts...

Umm, no they don't. I define the layout only in css, so it is simple to change, making the use of semantic classes in the markup rendundant. I remove rendundant code.

Edited August 10, 201214 yr by Inspired

By 'wonderfully labelled tags' are you referring to html elements like <article> and <span> ?

I'm not attacking you, the phrase "your wonderfully labelled tags" (I meant classes not tags) was aimed at developers in general not directly at your method. In that respect the point remains if you're naming classes like you say such as .floatright {float:none;} your classes become illogical. All I was saying was your absolutely correct and this was the initial point I was making in the first post.

Gotcha!

...In that respect the point remains if you're naming classes like you say such as .floatright {float:none;} your classes become illogical....

That was an example of what I don't do, to demonstrate why I think attaching semantic classes to markup makes no sense anymore. I'll be honest, I used to do it, but as I switched to mobile-first RWD I was struck by the senselessness of it all.

 

I'm not saying the way I do it now is perfect either, but I am certain that it is better than the way I used to do it.

 

What I do know is that one of the hardest parts of good RWD is questioning the way we all used to do things and developing new ways to do things that are better matced to today's demands. Change is hard, always has been. I'm old enough to recall the resistance to 'newfangled' css

Gotcha!

 

That was an example of what I don't do, to demonstrate why I think attaching semantic classes to markup makes no sense anymore. I'll be honest, I used to do it, but as I switched to mobile-first RWD I was struck by the senselessness of it all.

 

I'm not saying the way I do it now is perfect either, but I am certain that it is better than the way I used to do it.

 

What I do know is that one of the hardest parts of good RWD is questioning the way we all used to do things and developing new ways to do things that are better matced to today's demands. Change is hard, always has been. I'm old enough to recall the resistance to 'newfangled' css

 

I know it was, my point was that that was my original point.

 

I'm glad this has sparked a decent debate because your last paragraph is spot on. I look back on how I was developing not even a few months ago and think that it was just poor and ill thought out. I think that's what RWD is doing more than anything, making you think and having to have a bit of foresight. I think RWD is making us consider and plan for a lot more which can only make the web better and more robust.