Donate now!

Yeah!!

Duck lover

You can be worse than a frontender

@retoor fuck, wrote his name wrong!!

​

@Fast-Nop you just came out of the closet as frontender. Don't worry, everyone knew

@retoor I'm not on @kiki's level of CSS, but I certainly get things done. See, you don't need to be a frontender for... frontend. ;)

@retoor "you just came out as frontender" - nah. everybody can do frontend.

@tosensei Except the average frontender at large - as evidenced e.g. by the staggering fact that none of the US top 100 sites manages to even deliver valid HTML.

Source: https://meiert.com/en/blog/...

Oh, and that's just the syntax. Don't get me even started on the semantics.

This is the kind playful savagery I like the most.

@Fast-Nop well to be fair, that's the fault of whoever decided that browser should just "kind of still work" with invalid html.

because - if "It Works"(tm) - why bother in making it work _well_?

@tosensei Because it avoids weird rendering bugs, is usually better for accessibility, and doing a somewhat proper job at least when occupied at a larger company would be standard reasons.

@tosensei EXACTLY. Browsers accepting wrong html is the big issue! For a while (~15 years ago) it was popular to write valid XHTML (and you put some valid xhtml badge on your site) but that religion died.

I actually have read XHTML book but honestly don't care anymore. It was smoll btw

@retoor XHTML was doomed from the beginning. Lack of backwards compatibility, lack of perceived advantages over HTML, and HTML5 cleaned up quite some gripes with HTML4.

Plus the browser support: around 2000, IE was king and didn't support XHTML - only from IE9 onwards, 2011, i.e. after HTML5 had already gotten traction.

So what did XHTML writers do as not to shut out 90% of their website visitors? Well, they just sent their XHTML with "text/html" mime type. Which means they passed it off as HTML, making it arguably even worse than sticking with HTML.

That must have been fun, debugging a browser trying to interpret XHTML as HTML. Was the XHTML wrong to begin with? Was the HTML interpretation just different? Was it a browser bug?

@Fast-Nop AFAIK HTMLX brought nothing new to dem table. There were just some rules like add an alt to your image. Add a title to your link. I can't imagine writing something xhtml could fuck something up on older browsers. It can't hurt

@retoor Hm yeah, thinking about that, you're right - assuming that e.g. self-closing tags such as <br /> didn't expose HTML parser bugs in browsers back then.

OTOH, I write HTML with some XML/XHTML influence on more or less subjective grounds. I close my <li> and <p> because not doing that feels like taking a dump without using the toilet brush afterwards, just nope. I quote most attributes, and I use lowercase because that works better with gzip/brotli, plus that uppercase is an eyesore.

However, I use shortcuts for some attributes, e.g. just hidden instead of hidden="hidden", and I don't use the trailing slash on void elements, so <img ...> and not <img ... />.

I don't add titles to links because that is only visible on hover (i.e. not on smartphones), and useless for assistive technology like screenreaders. Hence, it must not convey important information anyway. I instead pay attention that the link words make sense, i.e. no "click here" garbage.

@Fast-Nop you don't add the /> on img tags? You man, you deserve to... 😥

@retoor Nope, I don't - and not on e.g. meta, link, or input either :) (link referring to the link element, not to the anchor hyperlink)

@Fast-Nop yeah, the godforsaken link tag. Hunts me in my dream. I wrote my own html parser in C and it was perfect but required all the tags to be closed. To write one supporting all these exceptions - my god. Oh my god. No idea how to do that 'clean'

@retoor The void elements are the easy part, you just look at the element, and if it's one of them, the next > closes it automatically, whether there is an XML style / or not.

Where it becomes nasty, that's non-void elements with optional closing tag such as p. They can close with their own tag, but I quote the spec to provide you with the daily dose of WTF:

"A p element's end tag can be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, search, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element."

Source: https://html.spec.whatwg.org/multip...

@Fast-Nop so the few things like <i> and stuff are allowed but types like article are not but ugh.. They really spent time raping it. I would say that p is one really to be closed

@retoor I guess the point here is that the next block element closes it while inline elements such as i, a, or span don't. Which would make kind of sense, so the parser would basically need to decide whether an opening tag within some p is block or inline.

@Fast-Nop I figured that but it's over engineering.

But will think twice now next time I say I understand html