The Web Design & Development Megathread

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

«‹›362 »

MrMoo: Sep 14, 2000

Opulent Ceremony posted:

Do you or someone you know work on Google Chromium? Would be really happy to have some official comment on this bug we've had for the last couple of months, even if it's to say that no fix is planned: https://bugs.chromium.org/p/chromium/issues/detail?id=899299

That�s by design for non-managed Chrome stations. Google enterprise wants you to pay $10/unit/month. There are lots of similar abandoned bug tracker entries, unless I�m misreading the notes. Then you can just call up support.

I went through a lot of material when porting digital signage to ChromeOS. It�s just not a sensible financial choice compared to almost any other solution out there. The changes are documented somewhere but it�s utterly non trivial finding them. Basically older accounts and apps had grandfathered permissions for this to work for the last few years, this version is probably the expiration of that plan.

MrMoo fucked around with this message at 14:10 on Feb 26, 2019

# ? Feb 26, 2019 13:58

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 18:51

Tei: Feb 19, 2011

I made a large application using Firefox XUL language, and then they dropped support for remote apps to use XUL.
It was more my fault than the browser developers fault, for using something propietary.

My lesson (at the time) was that browsers first customer is the people using the browser to navigate the web. If you are using a browser for any other purpose, you are on thin ice.

Opulent Ceremony posted:

Do you or someone you know work on Google Chromium? Would be really happy to have some official comment on this bug we've had for the last couple of months, even if it's to say that no fix is planned: https://bugs.chromium.org/p/chromium/issues/detail?id=899299

# ? Feb 26, 2019 14:28

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

The Dave posted:

Huh

It is easier to design for a thing that has no set horizontal or vertical size (and for which the text, which is the main part of the design, can be resized at will by a user), if there is no grid. This doesn't mean that grids aren't immensely useful, but if you find yourself in the position of not needing to use one (for example, if everything can go in a single column), the design and the development part are both easier. I'm not quite sure why people are baffled by this. Edit: as an example, the forum page I'm staring at at the minute doesn't need a grid system, it's unecessary

RobertKerans fucked around with this message at 14:58 on Feb 26, 2019

# ? Feb 26, 2019 14:52

The Dave: Sep 9, 2003

That's just not true. Of course a single column layout is simple and easy to make. Grids provide consistency and ease of consumption for layouts that are more complicated than that, and are such a solved 'feature' to implement that working with one shouldn't provide any extra difficulty.

# ? Feb 26, 2019 15:01

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

What do you mean it's not true? If you need the rigidity of a grid system then a grid system is the correct choice, if you don't then it isn't. Allowing things to naturally expand and flow is extremely common; grids purposefully constrain that and jamming a grid system in everywhere just because is silly

The Dave posted:

...and are such a solved 'feature' to implement that working with one shouldn't provide any extra difficulty.

Yes, adding an abstraction to the HTML takes no more code at all and no extra thought, and if you push the layout code out of the {framework} div soup and down into the CSS via the grid module, that grid module in no way has cryptic syntax

RobertKerans fucked around with this message at 15:24 on Feb 26, 2019

# ? Feb 26, 2019 15:18

The Dave: Sep 9, 2003

I don't disagree, the original comments came off as extremely anti-grid and didn't seem warranted.

# ? Feb 26, 2019 15:24

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

The Dave posted:

I don't disagree, the original comments came off as extremely anti-grid and didn't seem warranted.

True, sorry if it came across like that, I think I've just seen far too many [mainly Bootstrap-based] codebases when a couple hundred lines of CSS would've been all that was needed for the entire site

# ? Feb 26, 2019 15:26

kedo: Nov 27, 2007

Fluid width grids are things. The forums absolutely use a visual grid if not an actual code grid.

# ? Feb 26, 2019 17:09

Opulent Ceremony: Feb 22, 2012

MrMoo posted:

That�s by design for non-managed Chrome stations. Google enterprise wants you to pay $10/unit/month. There are lots of similar abandoned bug tracker entries, unless I�m misreading the notes. Then you can just call up support.

I figured this was going to be the case but hoped someone would at least say so in the bug. We've at least figured out how to configure the devices with Google Chrome kiosk licenses if necessary, but like you said it would probably be best to port our kiosk app to a different platform.

# ? Feb 26, 2019 17:26

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

kedo posted:

Fluid width grids are things. The forums absolutely use a visual grid if not an actual code grid.

I understand that, and you can get extremely reductive and say that anything that visually has a grid-like structure is a grid, but practically, in terms of coding an app/website, it's going to mean a code-based grid, either structured in the HTML or pushed down into the CSS using the CSS Grids module. cf the core of the forum is just series of things that could be structured like this:

code:

<postcontainer display:flex align-items:stretch>
  <userinfo width:someWidth display:flex flex-direction:column>
    <username>
    <joindate>
    <avatar>
    <usermeta display:flex margin-top:auto>
      <linkToThisPost>
      <showUserPosts>
      <postTimestamp>
    </usermeta>
  </userinfo>
  <post>
    <postbody>
    <postmeta display:flex justify-content:space-between flex:1>
      <userStuff display:flex>
        <profile>
        <message>
        <postHistory>
        <rapSheet>
      </userStuff>
      <postStuff display:flex align-items:end>
        <report>
        <quote>
      </poststuff>
    </postmeta>
  </post>
</postContainer>

You can draw a picture of it as a grid, and it would look like it was constrained into a grid, but it would just be a very few CSS flex properties used to push things into roughly the right place. Fluid grids are also fine but they're more constrained and aren't necessary all the time, lots and lots of things can just be layed out so that they are roughly in the right place

RobertKerans fucked around with this message at 17:54 on Feb 26, 2019

# ? Feb 26, 2019 17:33

Tei: Feb 19, 2011

Opulent Ceremony posted:

I figured this was going to be the case but hoped someone would at least say so in the bug. We've at least figured out how to configure the devices with Google Chrome kiosk licenses if necessary, but like you said it would probably be best to port our kiosk app to a different platform.

I feel you. It sucks when you depend on a third party thing and they remove the carpet below you.

# ? Feb 26, 2019 19:17

Dominoes: Sep 20, 2007

Re bootstrap: How do you organize a GUI without Bootstrap if not using CSS grid (Which I understand most people don't have the luxury of using)? I was only able to move on after learning Flexbox and Grid, since layout in CSS is painful without them. Even vertically centering things is obtuse without align/justify-items/content.

# ? Feb 26, 2019 20:18

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Centering something inside something else. https://jsfiddle.net/dgnxputo/

code:

#wrapper {
    position: relative;
}
#content {
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    margin: auto;
}

Doing it with dynamically sized things.

code:

#wrapper {
    position: relative;
}
#content {
    position: absolute;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
}

CSS is a bit quirky but I find a lot of people are holding it wrong.

People end up with websites that contain 1MB of CSS or more, how is anyone able to maintain that kind of code base without cyanide?

# ? Feb 26, 2019 20:48

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Dominoes posted:

Re bootstrap: How do you organize a GUI without Bootstrap if not using CSS grid (Which I understand most people don't have the luxury of using)? I was only able to move on after learning Flexbox and Grid, since layout in CSS is painful without them. Even vertically centering things is obtuse without align/justify-items/content.

Back in the day we'd get by using table hacks and booze.

# ? Feb 26, 2019 20:51

The Fool: Oct 16, 2003

i am the table used to assemble 200 segments of an image

# ? Feb 26, 2019 21:09

duz: Jul 11, 2005; Come on Ilhan, lets go bag us a shitpost

https://twitter.com/PPathole/status/1100406765156327427

# ? Feb 26, 2019 21:16

Clark Nova: Jul 18, 2004

Nolgthorn posted:

how is anyone able to maintain that kind of code base without cyanide?

In practice you don't maintain it, you make changes by tacking more entries on the end :downs:

# ? Feb 26, 2019 21:16

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Clark Nova posted:

In practice you don't maintain it, you make changes by tacking more entries on the end

I know you're right

# ? Feb 26, 2019 22:13

uncle blog: Nov 18, 2012

So, what are peoples naming conventions for CSS?

I'm in the process of redesigning the UI for a site. I started off following the block-element-modifier structure, but quickly started supplementing with some general classes as reuseability seemed low. So now I have classes like "block__element--modifier", and also general ones like "label", "clickable-flat" and so on. Very soon I needed both a "label" and a darker version, so I started adding modifier classes that do nothing on their own, but can be used with these general ones.

Example:

code:

.label {
    color: #D4D4D4;
    font-size: 0.9rem;
    font-weight: 600;
}

.label.m-dark {
    color: #A5A5A5;
}

Is this a horrible way to do things?

# ? Feb 27, 2019 15:22

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

Probs have a read of this: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/. He hit the same issues you're having. I dunno if I agree with his solution (reified in the Tailwind CSS framework he built), I think it's basically horrible, but possibly not. I've used the framework to prototype a couple of personal things, and putting stuff together was super duper quick. Unsure if I'd ever want it on anything real though. But the article is definitely worth a read anyhoo

RobertKerans fucked around with this message at 16:41 on Feb 27, 2019

# ? Feb 27, 2019 15:58

Doom Mathematic: Sep 2, 2008

uncle blog posted:

So, what are peoples naming conventions for CSS?

I'm in the process of redesigning the UI for a site. I started off following the block-element-modifier structure, but quickly started supplementing with some general classes as reuseability seemed low. So now I have classes like "block__element--modifier", and also general ones like "label", "clickable-flat" and so on. Very soon I needed both a "label" and a darker version, so I started adding modifier classes that do nothing on their own, but can be used with these general ones.

Example:
code:
.label {
    color: #D4D4D4;
    font-size: 0.9rem;
    font-weight: 600;
}

.label.m-dark {
    color: #A5A5A5;
}
Is this a horrible way to do things?

One of the main reasons BEM exists is that it makes it very easy to know at a glance what any given CSS declaration is used for, and where it takes effect in the rendering of the site. This helps in knowing what will change if you change that declaration, and whether it can safely be deleted.

A very common class name like .label is relatively difficult to search for. Its purpose is not clear. Is it guaranteed to be used in all <label>s in the site? If not, what are the exceptions? Is it guaranteed not to be used anywhere else? It also runs a risk of being independently reinvented by other people on the same project.

With .m-dark, it's not clear what the m means, or why it's dark sometimes. Can anything other than a .label be .m-dark? If so, is the effect the same or different? If it's the same, that's repetition; if it's different, then the .m-dark class is ambiguous and inconsistent in its effects. BEM would suggest something more like this:

code:

.label--m-dark {
  color: #A5A5A5;
}

Here --m-dark is clearly a modifier. Maybe something more descriptive like --selected would improve this more.

If you want to reuse common chunks of styling in multiple places, any CSS preprocessor should be able to do mixins. This would mean that the computed style of any individual element continues to come from a single class rather than from a multitude of classes. This avoids the cascade, and avoids problems relating to the order in which classes are listed, and interfering specificity levels.

Admittedly it does essentially shift the complexity of the style computation out of the cascade and into your stylesheets themselves. Now instead of tracking through a bunch of interfering declarations in the browser, you might need to track through a bunch of interfering style declarations and mixins in your SCSS/Sass/whatever source files. But at least your changes will have predictable effects.

# ? Feb 27, 2019 21:11

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

uncle blog posted:

So, what are peoples naming conventions for CSS?

I'm in the process of redesigning the UI for a site. I started off following the block-element-modifier structure, but quickly started supplementing with some general classes as reuseability seemed low. So now I have classes like "block__element--modifier", and also general ones like "label", "clickable-flat" and so on. Very soon I needed both a "label" and a darker version, so I started adding modifier classes that do nothing on their own, but can be used with these general ones.

Example:
code:
.label {
    color: #D4D4D4;
    font-size: 0.9rem;
    font-weight: 600;
}

.label.m-dark {
    color: #A5A5A5;
}
Is this a horrible way to do things?

As long as `m-` is a consistent naming convention, I prefer `is-` but it's the same idea. As long as you specify `.label.m-dark` like in your example it isn't any different from BEM and it is less tediously hip. In BEM are you expected to define `.label.label--m-dark` or do you just use `.label--m-dark` and if so why not `.label.m-dark`? Just stay organised it's simple.

I'd only suggest that `.label` is not a good class name and that all class names with very few exceptions outside of "css-reset" should be namespaced inside of an id. Such as `#header .my-super-label.is-dark`.

# ? Feb 28, 2019 00:54

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

When would you use .element--modifier vs .element.is-modified?

# ? Feb 28, 2019 04:58

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

The Merkinman posted:

When would you use .element--modifier vs .element.is-modified?

My guess is that �is-� things are for common modifications to a wide variety of elements. ex: is-centered for text. All sorts of text needs centering. The ��modifier� is for different versions of a specific component. ex: mediaCard�withBonusContent

# ? Feb 28, 2019 05:08

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

uncle blog posted:

So, what are peoples naming conventions for CSS?

I'm in the process of redesigning the UI for a site. I started off following the block-element-modifier structure, but quickly started supplementing with some general classes as reuseability seemed low. So now I have classes like "block__element--modifier", and also general ones like "label", "clickable-flat" and so on. Very soon I needed both a "label" and a darker version, so I started adding modifier classes that do nothing on their own, but can be used with these general ones.

Example:
code:
.label {
    color: #D4D4D4;
    font-size: 0.9rem;
    font-weight: 600;
}

.label.m-dark {
    color: #A5A5A5;
}
Is this a horrible way to do things?

That's more or less the way I do things, but for the sake of readability and maintainability in that case, I'd put color:#D4D4D4 in .label.m-light or some equivalent class, so only the things common to all .labels live in the style for .label.

# ? Feb 28, 2019 16:03

Doom Mathematic: Sep 2, 2008

The Merkinman posted:

When would you use .element--modifier vs .element.is-modified?

Always use .element--modifier, don't use .element.is-modified. The second case implies that the class .is-modified is an independent entity with a purpose of its own. This raises questions like: is it ever used in isolation, and if so, what does .is-modified mean/do? Is it ever used in other contexts e.g. .different-element.is-modified and if so, what does it do? If the effects in these other contexts are identical, then why the duplication instead of splitting out .is-modified by itself? If the effects differ in each context, then what's the benefit of recycling the class name when it means something different each time? All of these questions make it more difficult to reason about what will happen if you modify this declaration, and what other declarations if any should be modified to ensure consistent style in the applicaton. Also, increased specificity causes specificity headaches.

# ? Feb 28, 2019 16:54

Tei: Feb 19, 2011

I have very strong opinions about naming things, but not time to talk long about it, so I will just write a few "rules".

Practical example:
Bottle of Milk. Bottle of Acid.

- Don't name two things the same way. BottleA and BottleA would be bad names. BottleMilk and BottleAcid would be good names.

- Don't name things in a way that is impossible to remember or tell the nature. GHE30004 and GHE30005 would be bad names.

- Don't name things the opossitte of what they are. BottleAcid for the milk bottle and BottleMilk for the acid bottle.

- Whatever name convention you use, follow it. bottleAcid and MilkB are bad names. Where bottleAcid / bottleMilk and MilkB/ AcidB are good names.

- Variables are variable Don't call a glass bottle that can contain milk, water or acid "BottleOfMilk". Call it MiscLiquidsBottle.

- Constant are constant. PI is not going to change anytime soon, yup can call your PI variable PI, and you can call your "machine that generate glass bottles" GlassBottlesFactory. The rules of constant and variables are kind of different, so is important if you are working with constants or variables

- Don't be ugly. If your rule name convention generate ugly names, specially very long ugly names, consider dropping it and using some other name convention. Uglyness is distracting, confusing and get in the way to make correct software.

- Everything need a name. Except things whose value is doing a thing while ever needing a name.

# ? Feb 28, 2019 17:07

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Write it in such a way that when your client calls and wants you to look at a code base you haven't touched in two years, it will not create a strong urge to invent a time machine to go back and strike your past self upside the head :v:

# ? Feb 28, 2019 19:38

The Fool: Oct 16, 2003

PT6A posted:

Write it in such a way that when your client calls and wants you to look at a code base you haven't touched in two years, it will not create a strong urge to invent a time machine to go back and strike your past self upside the head

If I was capable of writing code that way I wouldn't need the time machine.

# ? Feb 28, 2019 19:44

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

The Fool posted:

If I was capable of writing code that way I wouldn't need the time machine.

It depends. I often look back on code I've written and bemoan the fact that I didn't do something that I learned I should do between then and now, but there's no use getting mad about that. It is worth getting mad about having written borderline-unreadable, uncommented bullshit because you wanted to shave a few minutes off a few years ago and figured it would be obvious enough/"self-documenting".

# ? Feb 28, 2019 19:55

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I'm sure this is a solved problem, I just don't ever do the type of work I'm doing right now...

I'm building a static site with maybe 10 different pages, and it sure seems like it would be nice to not have to edit my (for example) title tag on every page when I want to change it.

In (for example) Django, I'd just use template inheritance, but, like I said, I'm building a static site.

What kind of template-based build tools will let me build a static site?

# ? Feb 28, 2019 22:14

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Thermopyle posted:

I'm sure this is a solved problem, I just don't ever do the type of work I'm doing right now...

I'm building a static site with maybe 10 different pages, and it sure seems like it would be nice to not have to edit my (for example) title tag on every page when I want to change it.

In (for example) Django, I'd just use template inheritance, but, like I said, I'm building a static site.

What kind of template-based build tools will let me build a static site?

Since you are a python guy, maybe Pelican? http://docs.getpelican.com/en/stable/

# ? Feb 28, 2019 22:17

EL BROMANCE: Jun 10, 2006; COWABUNGA DUDES!
🥷🐢😬

Thermopyle posted:

I'm building a static site with maybe 10 different pages, and it sure seems like it would be nice to not have to edit my (for example) title tag on every page when I want to change it.

Is there a reason they've never added an equivalent of 'include' into HTML? Half the time I use it for just bringing in a menu or something, so like Thermo I'm not stuck updating the same thing on multiple pages when a detail changes.

# ? Feb 28, 2019 22:41

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Lumpy posted:

Since you are a python guy, maybe Pelican? http://docs.getpelican.com/en/stable/

Yeah, I was hoping something more like a build step for regular HTML. Pelican (and other related stuff) are nice tools, but in this instance I'd rather write HTML and use includes or templates.

# ? Mar 1, 2019 00:17

The Fool: Oct 16, 2003

Use Handlebars and webpack to build/render the html?

https://handlebarsjs.com/
https://github.com/sagold/handlebars-webpack-plugin

# ? Mar 1, 2019 00:30

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Depending on how simple the template is (one template, changing content in the main section of every page), you can probably write a Python script to accomplish that build process. I think the reason that there's no one great solution to that problem is that it's simple enough for any one case, but it'd be very difficult to write something general-purpose that would cover the peculiarities of all projects it might be used for.

# ? Mar 1, 2019 05:00

Roadie: Jun 30, 2013

Thermopyle posted:

I'm sure this is a solved problem, I just don't ever do the type of work I'm doing right now...

I'm building a static site with maybe 10 different pages, and it sure seems like it would be nice to not have to edit my (for example) title tag on every page when I want to change it.

In (for example) Django, I'd just use template inheritance, but, like I said, I'm building a static site.

What kind of template-based build tools will let me build a static site?

Jekyll exists for exactly this kind of use case.

# ? Mar 1, 2019 05:20

Nude: Nov 16, 2014; I have no idea what I'm doing.

The Fool posted:

Use Handlebars and webpack to build/render the html?

https://handlebarsjs.com/
https://github.com/sagold/handlebars-webpack-plugin

Just +1ing this I used mustache but I'm pretty sure they are the same just that mustache has no logic and is just a template.

I had the same frustrations where I just wanted to have include in html. This is the closest it seems like.

# ? Mar 1, 2019 06:33

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

You need some kind of html renderer. I liked haml for a while but I've been diverting more and more to whatever is closest to the metal. I choose mustache where possible when I'm not using a client side framework lately, and I use the rendering engine it comes with so to skip webpack.

# ? Mar 1, 2019 11:00

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 18:51

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

I'm having an OK time using Gatsby for a static site. Finding some of their documentation lacking, though, mostly around the GraphQL schemas their components support. I like the way JSX works, so it's a decent fit for me because I can bang out some JSON and a couple of minimal template elements to turn it into a whole page.

# ? Mar 1, 2019 15:58

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

«‹›362 »