|
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
|
# ? Feb 5, 2018 16:42 |
|
|
# ? Jun 3, 2024 22:10 |
|
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 |
|
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. Just a heads up, splash pages do not place well with Google SEO these days.
|
# ? Feb 5, 2018 19:31 |
|
huhu posted:Just a heads up, splash pages do not place well with Google SEO these days.
|
# ? Feb 5, 2018 20:29 |
|
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 |
|
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 |
|
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 |
|
Sergeant Rock posted:I'm gonna go with 'lazy fuckers can't be bothered to use the proper semantics'.
|
# ? Feb 6, 2018 17:48 |
|
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 |
|
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 |
|
Thermopyle posted:Or...you can use section/article/header when they make sense and use divs when they make sense. Sergeant Rock posted:I'm gonna go with 'lazy fuckers can't be bothered to use the proper semantics'.
|
# ? Feb 6, 2018 19:02 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Maluco Marinero posted:The semantics make a difference to screen readers and anything else that parses the document structure.
|
# ? Feb 7, 2018 16:40 |
|
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 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 |
|
https://github.com/kelseyhightower/nocode
|
# ? Feb 7, 2018 18:49 |
|
Somehow it will still have bugs.
|
# ? Feb 7, 2018 18:59 |
|
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 |
|
Native HTML validation only on the frontend imo
|
# ? Feb 7, 2018 19:26 |
|
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 |
|
https://twitter.com/infinite_scream/status/961303620489793538
|
# ? Feb 7, 2018 19:35 |
|
If the user really wants to send bad data, they are just going to turn off JavaScript anyway, so why bother.
|
# ? Feb 7, 2018 19:42 |
|
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 |
|
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 |
|
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’. Thermopyle posted:Yeah, I'm fairly confident the majority of websites going up are still document-based non-web-app-ish stuff. 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 |
|
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 |
|
Knifegrab posted:Alright guys, form validation. JavaScript code:
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 kedo fucked around with this message at 23:27 on Feb 7, 2018 |
# ? Feb 7, 2018 23:23 |
|
Knifegrab posted:Alright guys, form validation. 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 e: This assumes JS and ajax... bigmandan fucked around with this message at 23:43 on Feb 7, 2018 |
# ? Feb 7, 2018 23:36 |
|
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 |
|
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 |
|
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 |
|
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). 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 |
|
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 |
|
Cool, thanks!
|
# ? Feb 8, 2018 17:30 |
|
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 |
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 |
|
fletcher posted:Got a screenshot? 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 |
|
|
# ? Jun 3, 2024 22:10 |
|
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 |