The Web Design & Development Megathread

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

«‹›361 »

Capri Sun Tzu: Oct 24, 2017; by Reene

Boris Galerkin posted:

e2: One last thing. I thought that with html5 (and my knowledge of this is like, 7 years old) you weren't suppose to use elements like <div> anymore but instead prefer more semantic elements. But every single css grid tutorial (from the past year even) all use <div>s everywhere, like

In the wild it's div's all the way down and what you're 'supposed' to do depends on who you ask. My opinion is that div's are just fine as long as you are concise and consistent with your class naming. There is some minor SEO benefit from using named elements.

# ? Feb 5, 2018 16:42

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 12:01

Lonely Wolf: Jan 20, 2003; Will hawk false idols for heaps and heaps of dough.

div's are fine.

Stuff like header, footer, etc. are essentially just div's but they can make it easier to read the HTML and they set ARIA roles which make it easier for screen readers and such to navigate documents by exposing the structure in a machine readable way but only if you pay attention to what the various roles actually mean: https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/landmarks/HTML5.html

# ? Feb 5, 2018 17:24

huhu: Feb 24, 2006

Boris Galerkin posted:

I'm trying to make a splash page for my personal site and I'm trying to just learn the greatest and latest modern features, so right now I'm using just css grid. Is there a setting in firefox/chrome/safari that I can enable to to draw all the lines for me? I'm getting really confused keeping track of which blank spaces are margins, which blank spaces are empty grid columns, and so on.

(I don't really know what I'm doing by the way. I downloaded WebStorm and normalize.css and grabbed some fonts from Google Fonts and that's it.)

e: I want to use variables in my css (i.e, let blue1 = #whatever and then using $blue1 in the rest of the css) so I guess I need a pre-processor? Which one is "better"? I'm vaguely aware of something called less and sass.

e2: One last thing. I thought that with html5 (and my knowledge of this is like, 7 years old) you weren't suppose to use elements like <div> anymore but instead prefer more semantic elements. But every single css grid tutorial (from the past year even) all use <div>s everywhere, like

https://mozilladevelopers.github.io/playground/css-grid/07-basic-layout
code:
<div class="container">
  <div class="header">header</div>
  <div class="sidebar">sidebar</div>
  <div class="content-1">Content-1</div>
  <div class="content-2">Content-2</div>
  <div class="content-3">Content-3</div>
  <div class="footer">footer</div>
</div>
Why doesn't this example use <header>, <footer>, <section>, and <nav> tags? Did they fall out of favor?

e3: Huh, variables are built into css now? Also, math (via “calc()”)? I didn’t know that. That’s cool.

Just a heads up, splash pages do not place well with Google SEO these days.

# ? Feb 5, 2018 19:31

Capri Sun Tzu: Oct 24, 2017; by Reene

huhu posted:

Just a heads up, splash pages do not place well with Google SEO these days.

Oh yeah I missed that part of the post. Definitely don't do a splash page if you care about the public interacting with your website.

# ? Feb 5, 2018 20:29

Boris Galerkin: Dec 17, 2011; I don't understand why I can't harass people online. Seriously, somebody please explain why I shouldn't be allowed to stalk others on social media!

It�s for the domain I use for my email address. In fact, not having google index/rank my page highly would be a great feature.

I found the grid display thing in Firefox. That helps a lot, thanks.

Now I just need to figure out whether I should use margins or padding. Yeah I�ve seen that schematic drawing of what is what and I get that. But practically speaking I don�t get what the difference between an offset outside vs offset inside my border is, if I�m not going to show any borders.

# ? Feb 6, 2018 10:36

Sergeant Rock: Apr 28, 2002; "... call the expert at kissing and stuff..."

I'm gonna go with 'lazy fuckers can't be bothered to use the proper semantics'.

Using section, article, header etc is good for accessibility and makes scanning a page of markup by eye *much* easier. Nothing worse than twenty nested <div>s spunked over the screen.

# ? Feb 6, 2018 11:09

Tei: Feb 19, 2011

1) good thing is invented
2) smart people use it, they know what they are doing
3) spazs start using it without understanding the meaning
4) good thing is now part of the tag soup and is ruined

The tag soup is like the borg, always asimilating more systems, growing. Resistence is futile.

# ? Feb 6, 2018 11:18

Capri Sun Tzu: Oct 24, 2017; by Reene

Sergeant Rock posted:

I'm gonna go with 'lazy fuckers can't be bothered to use the proper semantics'.

Using section, article, header etc is good for accessibility and makes scanning a page of markup by eye *much* easier. Nothing worse than twenty nested <div>s spunked over the screen.

Section/article/header etc don't make any semantic sense in a lot of web apps. Also, you can have multiple classes but only one element. Additionally sometimes I want an element that is in fact a button, say, but without the default button styling and functionality. Ultimately it does not matter and well structured code will be readable regardless of your approach but divs are the simpler option which is why everyone is still using them.

# ? Feb 6, 2018 17:48

spiritual bypass: Feb 19, 2008; Grimey Drawer

We should have an HTML CRAP score by the number of classes needed to make the CSS work

spiritual bypass fucked around with this message at 18:45 on Feb 6, 2018

# ? Feb 6, 2018 18:40

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

Capri Sun Tzu posted:

Section/article/header etc don't make any semantic sense in a lot of web apps. Also, you can have multiple classes but only one element. Additionally sometimes I want an element that is in fact a button, say, but without the default button styling and functionality. Ultimately it does not matter and well structured code will be readable regardless of your approach but divs are the simpler option which is why everyone is still using them.

Or...you can use section/article/header when they make sense and use divs when they make sense.

# ? Feb 6, 2018 18:43

Capri Sun Tzu: Oct 24, 2017; by Reene

Thermopyle posted:

Or...you can use section/article/header when they make sense and use divs when they make sense.

Sure! The takeaway for new devs is that it's really a nonissue. If you're making a conventional website with articles, headers etc then you should probably be using a CMS anyway.

Sergeant Rock posted:

I'm gonna go with 'lazy fuckers can't be bothered to use the proper semantics'.

Using section, article, header etc is good for accessibility and makes scanning a page of markup by eye *much* easier. Nothing worse than twenty nested <div>s spunked over the screen.

Do you consider the teams behind Gmail/Facebook/Trello/Any popular web app to be lazy fuckers or do you think there is a reason why classed divs is the standard instead of named elements?

# ? Feb 6, 2018 19:02

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Unlike you guys I am old as hell so I started this stuff out with SGML/LaTeX which means I would prefer named elements.

# ? Feb 6, 2018 19:37

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

Using HAML and then PUG all my elements look like `.header` `.article.is-unread` `#content` it's nice. The new named elements aren't as versatile as a div, I can't put them where I want. I can't see much difference between `section` and `.section` it feels like a bot would ignore all that stuff. I think Google mostly cares about linkbacks and adwords.

When I am on a large project with a bunch of devs it's element soup, too. With what seems like hundreds of nested divs, would putting a `section` or `nav` element in make a difference?

Nolgthorn fucked around with this message at 09:48 on Feb 7, 2018

# ? Feb 7, 2018 08:13

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

The semantics make a difference to screen readers and anything else that parses the document structure.

Divs and spans without a aria-role are essentially no-ops semantically. They�re fine to use, as many as you like for presentational needs, as long as you also substitute divs for semantic tags where applicable.

Div soup is NOT inevitable, it�s largely because of laziness, an unwillingness to do a minimum of document structuring. HTML5 tags are sufficient for document style sites, with ARIA roles filling in the gaps for web applications.

Doing aria roles well are a bit harder, but structuring document HTML well is like basic competency at this point. You should be targeting classes and not tags for styling anyway, so just change the tags to what makes semantic sense. Even a half assed effort is still more navigable for screen readers than just ignoring the issue.

# ? Feb 7, 2018 10:26

Tei: Feb 19, 2011

Scaramouche posted:

Unlike you guys I am old as hell so I started this stuff out with SGML/LaTeX which means I would prefer named elements.

I bought into the XHTML crazy and then HTML5 happened. Sometimes it feel like I have stepped into a alternate universe where browsers never implemented XML files to <include> other XML files. (so main.xml where allowed to import menu.xml).

In this mirror universe where we live, darker and more dangerous than the normal universe, things get ruined by people using them without understanding how they work. Engine developers are forced to deal with broken code and give correct answer to wrong questions.

Maybe div is a blessing, so people don't pollute the meaning of other things.

Tei fucked around with this message at 13:39 on Feb 7, 2018

# ? Feb 7, 2018 13:25

Capri Sun Tzu: Oct 24, 2017; by Reene

Maluco Marinero posted:

The semantics make a difference to screen readers and anything else that parses the document structure.

You aren't technically wrong, but I think you're reflecting an older mindset about what the web is used for. In the era of web applications, parsing the document structure often just doesn't make sense.

# ? Feb 7, 2018 16:40

Main Paineframe: Oct 27, 2010

Boris Galerkin posted:

e2: One last thing. I thought that with html5 (and my knowledge of this is like, 7 years old) you weren't suppose to use elements like <div> anymore but instead prefer more semantic elements. But every single css grid tutorial (from the past year even) all use <div>s everywhere, like

https://mozilladevelopers.github.io/playground/css-grid/07-basic-layout
code:
<div class="container">
  <div class="header">header</div>
  <div class="sidebar">sidebar</div>
  <div class="content-1">Content-1</div>
  <div class="content-2">Content-2</div>
  <div class="content-3">Content-3</div>
  <div class="footer">footer</div>
</div>
Why doesn't this example use <header>, <footer>, <section>, and <nav> tags? Did they fall out of favor?

It's just a code sample, not a deployed application. And rather than "falling out of favor", it's more that a lot of people didn't transition to the HTML5 semantic elements in the first place since they offer relatively little direct benefit to developers. People have been slinging divs for so long that they're more accustomed to that, especially when they're just tossing together a quick CSS or Javascript sample and don't really expect anything to be parsing the structure.

# ? Feb 7, 2018 16:49

kedo: Nov 27, 2007

https://github.com/kelseyhightower/nocode

# ? Feb 7, 2018 18:49

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

kedo posted:

https://github.com/kelseyhightower/nocode

Somehow it will still have bugs.

# ? Feb 7, 2018 18:59

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

Alright guys, form validation.

When do you do it? onChange, onBlur, on submit?

Comedy option: onFocus?

I am going crazy at work. I believe you should validate each field on blur, and as a double safety also validate the whole form on submit. But some people are suggesting that onBlur validation is bad for ~reasons~.

# ? Feb 7, 2018 19:19

spiritual bypass: Feb 19, 2008; Grimey Drawer

Native HTML validation only on the frontend imo

# ? Feb 7, 2018 19:26

The Fool: Oct 16, 2003

rt4 posted:

Native HTML validation only on the frontend imo

I prefer server side only validation with obscure errors so the user has no idea why/if the form didn't submit properly

e: just send error 500 if validation fails

# ? Feb 7, 2018 19:30

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

https://twitter.com/infinite_scream/status/961303620489793538

# ? Feb 7, 2018 19:35

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

If the user really wants to send bad data, they are just going to turn off JavaScript anyway, so why bother. :smith:

# ? Feb 7, 2018 19:42

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Capri Sun Tzu posted:

You aren't technically wrong, but I think you're reflecting an older mindset about what the web is used for. In the era of web applications, parsing the document structure often just doesn't make sense.

Which is why I brought up aria roles. Look, so much of the web is still documents, that�s not an old mindset, that�s literally what the web is primarily composed of.

Our desktop and iOS applications are screen reader accessible, yet many many many of our web applications continue to abdicate this responsibility, passing it off as unnecessary or whatever, determining that structure of your tags is irrelevant. That�s the backwards thinking in my mind.

It ignores the amount of progress we have made in microformats, HTML5, aria roles, in a way that feels way more old fashioned, because it essentially says �gently caress accessibility�.

# ? Feb 7, 2018 21:26

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

Yeah, I'm fairly confident the majority of websites going up are still document-based non-web-app-ish stuff.

(as it should be)

I'm not even sure it's an accurate argument to say that javascript-generated sites shouldn't be or are not machine readable. Or at least I'm not sure that the portion of such sites that should be machine readable is insignificant.

# ? Feb 7, 2018 21:32

Capri Sun Tzu: Oct 24, 2017; by Reene

Maluco Marinero posted:

It ignores the amount of progress we have made in microformats, HTML5, aria roles, in a way that feels way more old fashioned, because it essentially says �gently caress accessibility�.

I agree accessibility is definitely not a priority and sadly that isn't likely to change. I'm not defending this point of view, that is just the state of the industry.

Thermopyle posted:

Yeah, I'm fairly confident the majority of websites going up are still document-based non-web-app-ish stuff.

I might challenge this assertion, I think the last study I read said something like the average user spends 20% of their time reading and the rest on social media, shopping, banking, etc. So the majority use case for the web might really be shifted to web applications and I think this trend will continue to grow.

HTML grew out of SGML which was itself an outgrowth from print design, intended solely for arranging content. The web has really transcended it's original intended design and named elements don't make as much sense as they used to. Semantic-less divs are the de facto standard and I don't know that this will ever fall out of favor the way, for example, using tables for layout has.

# ? Feb 7, 2018 22:23

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

Capri Sun Tzu posted:

I might challenge this assertion, I think the last study I read said something like the average user spends 20% of their time reading and the rest on social media, shopping, banking, etc. So the majority use case for the web might really be shifted to web applications and I think this trend will continue to grow.

I'm not sure that's the same thing as the majority of web sites being developed which is the thing that is relevant here.

IOW, it's consistent for the majority of users time to be spent in social media or whatever and for the majority of sites currently being put on the internet to be non-web-app-ish stuff.

# ? Feb 7, 2018 22:36

kedo: Nov 27, 2007

Knifegrab posted:

Alright guys, form validation.

When do you do it? onChange, onBlur, on submit?

Comedy option: onFocus?

I am going crazy at work. I believe you should validate each field on blur, and as a double safety also validate the whole form on submit. But some people are suggesting that onBlur validation is bad for ~reasons~.

JavaScript code:

setInterval(function() {
	if (!fieldsAreValid()) {
		alert('Validation error!!!!');
	}
}, 1);

e: For real though, I like on blur because I don't want to get done filling out an entire form before the thing tells me that I missed a field several thousand pixels away from my current location on the page. As long as it's fairly unobtrusive (ie. you're not capturing focus until they fix the validation error) and your validation isn't throwing false positives, I don't see why doing it on blur would be bad.

e2:

The Fool posted:

I prefer server side only validation with obscure errors so the user has no idea why/if the form didn't submit properly

e: just send error 500 if validation fails

kedo fucked around with this message at 23:27 on Feb 7, 2018

# ? Feb 7, 2018 23:23

bigmandan: Sep 11, 2001; lol internet; College Slice

Knifegrab posted:

Alright guys, form validation.

When do you do it? onChange, onBlur, on submit?

Comedy option: onFocus?

I am going crazy at work. I believe you should validate each field on blur, and as a double safety also validate the whole form on submit. But some people are suggesting that onBlur validation is bad for ~reasons~.

I personally like to only validate server side and if there is an error, return a 422 response with a JSON body containing the errors. Based on the returned errors I highlight the form fields in some fashion with the error message next to or underneath it. I mostly do this as I dislike having duplicated logic for validating input as changes to the code base require edits in two places rather than one. Basically :effort:

e: This assumes JS and ajax...

bigmandan fucked around with this message at 23:43 on Feb 7, 2018

# ? Feb 7, 2018 23:36

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Capri Sun Tzu posted:

I might challenge this assertion, I think the last study I read said something like the average user spends 20% of their time reading and the rest on social media, shopping, banking, etc. So the majority use case for the web might really be shifted to web applications and I think this trend will continue to grow.

The only problem I have with this take is that most of these applications are delivering documents. Products can be microformatted (and it�s beneficial to do so). Tweets are small articles. Medium is articles. Just because we�re in Web 2.0 or whatever where every social function has been carved up into application fiefdoms, hasn�t changed the document nature of the web, merely altered the containers they�re in.

# ? Feb 8, 2018 02:34

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

No client side validation at all, there are enough pointless queries made to servers that one out of ten failing isn't a big deal. Just do validation on the server and return a bad request response.

# ? Feb 8, 2018 03:16

kedo: Nov 27, 2007

Best practice question ��say I'm creating a React app that will query an API about sandwiches and return results. The app will live on numerous pages as part of a greater site, and it needs to know what page it's on in order to do the right query (eg. if it's on the "Subs" page, it should do sub queries, while on the "Open Faced" page it should do open faced queries).

I know I can figure out what page I'm on by getting IDs or classes from the DOM (eg. if body ID == "sub" do sub stuff, else if body ID == "open-faced" do open faced stuff), but I know touching the DOM is generally a no-no. Is there a better or smarter way to do this? I suppose I could theoretically have two versions of the app and put one on one page and one on the other, but that sounds like a maintenance nightmare if I ever need to make changes to all the apps at once.

# ? Feb 8, 2018 16:32

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

kedo posted:

Best practice question ��say I'm creating a React app that will query an API about sandwiches and return results. The app will live on numerous pages as part of a greater site, and it needs to know what page it's on in order to do the right query (eg. if it's on the "Subs" page, it should do sub queries, while on the "Open Faced" page it should do open faced queries).

I know I can figure out what page I'm on by getting IDs or classes from the DOM (eg. if body ID == "sub" do sub stuff, else if body ID == "open-faced" do open faced stuff), but I know touching the DOM is generally a no-no. Is there a better or smarter way to do this? I suppose I could theoretically have two versions of the app and put one on one page and one on the other, but that sounds like a maintenance nightmare if I ever need to make changes to all the apps at once.

Why not look at the document location and figure out where you are? And there's nothing wrong with touching the DOM. Manipulating part of the DOM React is in charge of rending can get you into trouble, but const wtf = document.querySelector('body').classList is not an issue at all.

Lumpy fucked around with this message at 16:47 on Feb 8, 2018

# ? Feb 8, 2018 16:45

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

I think the page should provide that information as part of initial state, assuming the rest of the page is also rendered with React, that is. Otherwise, yeah, sure, poke around and try to figure out what the context is.

# ? Feb 8, 2018 17:24

kedo: Nov 27, 2007

Cool, thanks!

# ? Feb 8, 2018 17:30

Pollyanna: Mar 5, 2005; Milk's on them.

Google Maps API question: I've got a set of data that has some polygons overlapping or one inside another. This results in "holes" inside my polygons. Is there a way to overlay those polygons without them creating holes, effectively disabling the "make a hole" behavior?

# ? Feb 9, 2018 01:49

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Pollyanna posted:

Google Maps API question: I've got a set of data that has some polygons overlapping or one inside another. This results in "holes" inside my polygons. Is there a way to overlay those polygons without them creating holes, effectively disabling the "make a hole" behavior?

Got a screenshot?

Maybe do a UNION on the shapes to combine them into one? I've used https://postgis.net/docs/ST_Union.html for this

# ? Feb 9, 2018 02:41

Pollyanna: Mar 5, 2005; Milk's on them.

fletcher posted:

Got a screenshot?

Maybe do a UNION on the shapes to combine them into one? I've used https://postgis.net/docs/ST_Union.html for this

The red polygon here is a larger polygon, while the hole in the middle is a different polygon specified afterwards:

What I'm asking is if there's a way to tell Google Maps not to make overlapping polygons into holes.

# ? Feb 9, 2018 02:54

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 12:01

-JS-: Jun 1, 2004

Not sure what's going on without seeing code - but it seems to be possible after a bit of hacking on the example given by Google - https://jsfiddle.net/5psoshgn/1/

# ? Feb 9, 2018 10:57

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

«‹›361 »