Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HN's HTML Is Invalid

validator.w3.org

Post reply on HN
Print view View original

41–50 of 62 posts

Re: HN's HTML Is Invalid

#41

Post by zagrebian »

PaulHoule wrote: post #31

I think a lot of those are bogus, but there are some real ones such as cases where there is no space between attributes, like there are a lot of old elements being used where css could be used instead, probably if the HTML was updated like that and they were smart about selectors it would get the page size down a bit. Then there is the thing which may seem like a lot of bullshit, I don’t know how it now but years ago…

> Then there is the thing which may seem like a lot of bullshit, I don’t know how it now but years ago it did make a difference because if you didn’t have it browsers would go into a compatibility mode with old web pages.

This is still true. Browsers run HN in quirks mode. Just open the devtools console in Firefox, and it will tell you.

Re: HN's HTML Is Invalid

#43

Post by PennRobotics »

trinsic2 wrote: post #19

Speaking of the HTML it would be great to have a way to increase the text size for mobile devices. The Hacker News layout doesn't look to great in reader view.

If your mobile browser is Chrome-based, there should be an Accessibility setting called "Show zoom option in main menu", which I believe then shows up between Recent Tabs and Share. I'm able to zoom HN this way.

Re: HN's HTML Is Invalid

#44

Post by zagrebian »

petee wrote: post #22

In defense, half of these look like what I'd call "normal" HTML, granted I'm not up on the latest fads. But " " is depreciated now? Come on. "Width" and "height" attributes too? To what purpose? They are clear, easy to use, and apparently still widely supported with no issue. And yet to see a browser that actually cares about DOCTYPE...usually its pretty obvious when the next line is Edit: I seem to be mistaken about…

> And yet to see a browser that actually cares about DOCTYPE

If a web page does not have the correct doctype, browsers run it in quirks mode instead of standards mode. If a web developer is fine with their websites running in quirks mode, they are not a good web developer, and you should probably stay away from them.

Re: HN's HTML Is Invalid

#45

Post by jejeyyy77 »

pavlov wrote: post #25
foobarian wrote: post #10

Earlier quoted context omitted.

Wait, there is something newer now?

This year every credible CSS expert is using grid-item-gutter-closed-start specified in qem units. Last year it was flex-interval-bound-distance: 1, auto, 100% but the spacing wasn’t artisanal enough. Many people are also discovering the Tailwind organic vintage where you just add sx-dff-7 gb-y it-9-em on all your elements.

what a waste of time lol

Re: HN's HTML Is Invalid

#46

Post by PennRobotics »

petee wrote: post #22

In defense, half of these look like what I'd call "normal" HTML, granted I'm not up on the latest fads. But " " is depreciated now? Come on. "Width" and "height" attributes too? To what purpose? They are clear, easy to use, and apparently still widely supported with no issue. And yet to see a browser that actually cares about DOCTYPE...usually its pretty obvious when the next line is Edit: I seem to be mistaken about…

I'm a bit glad to see the HTML specification evolve rather than stay backwards compatible forever. The committee drew a line between logic, layout, and content. is purely layout. I'm sad to see it go for nostalgic reasons and am often confused when I need to center a non-text, non-flexbox element, but centering does belong in "layout".

I just wish the Tailwind community (and those from other big-ass CSS frameworks) would internalize this concept. It feels so unintuitive to have your compiled HTML just element after element of class="lg:block fixed inset-0 top-[3.8125rem] drop-shadow-md justify-center hunter2-blue overflow-hidden pointer-events-none"

...especially when elements like

have the exact same giant class definition throughout an entire page.

Re: HN's HTML Is Invalid

#47

Post by ElectricalUnion »

petee wrote: post #38
ElectricalUnion wrote: post #33

Earlier quoted context omitted.

> And yet to see a browser that actually cares about DOCTYPE...usually its pretty obvious when the next line is How do browsers determine which mode to use? For HTML documents, browsers use a DOCTYPE in the beginning of the document to decide whether to handle it in quirks mode or standards mode. The DOCTYPE shown in the example, , is the simplest possible, and the one recommended by current HTML standards. Earlier v…

So no real use, got it. Luckily IE 9 has been gone for awhile My point was its silly because the html self-defines being html the second you open the tag, because what else could it even be?

> So no real use, got it.

If you don't care your site potentially becomes unusable broken shit outside of the specific browser you develop it on, there's no real use.

https://quirks.spec.whatwg.org/

Re: HN's HTML Is Invalid

#48

Post by WorldMaker »

throwanem wrote: post #14
foobarian wrote: post #10

Earlier quoted context omitted.

Wait, there is something newer now?

Tables first came to be used as a tool for general page layout because IE 5's box model sucked so bad nothing else really worked. It has been a minute since that constraint applied, yeah.

IE5's box model was the good one (* { box-sizing: border-box; } is the vestigial "please use the IE box model" in almost every CSS file today). It was Netscape/early Mozilla's box model that was hard to reason with.

But also, using Tables for page layout had less to do with box layout problems and more to do with the lack of something like CSS Grid (finally, decades later). Tables let you define regular grids in a way that was closer to designing a grid (thinking in terms of spans across cells instead of widths/margins). Tables for layout didn't truly go away until around the Bootstrap era with its column grid helpers (and their complex CSS math to make that work before both flexbox and native CSS Grid).

Re: HN's HTML Is Invalid

#49

Post by timeon »

throwanem wrote: post #32
mypetocean wrote: post #30

Earlier quoted context omitted.

Tables first came to be used for displaying tabular (spreadsheet-like) data – which was what it was designed for. And for that purpose, it's still the best option.

Yes, that's why they're in the spec and is the case where their use is still valid, but that's why I qualified my prior comment. HN dates from the period I described and still uses tables for general page layout, hence the original commenter's query to which I replied.

> HN dates from the period I described and still uses tables for general page layout

According to Wiki HN dates from 2007. I think Yahoo moved from table to CSS layout earlier. CSS Zen Garden is from around 2003.

Re: HN's HTML Is Invalid

#50

Post by petee »

ElectricalUnion wrote: post #47
petee wrote: post #38

Earlier quoted context omitted.

So no real use, got it. Luckily IE 9 has been gone for awhile My point was its silly because the html self-defines being html the second you open the tag, because what else could it even be?

> So no real use, got it. If you don't care your site potentially becomes unusable broken shit outside of the specific browser you develop it on, there's no real use. https://quirks.spec.whatwg.org/

I'm mistaken then; from the block you copy and pasted I misread it to suggest only IE 9 cares about quirks. In my personal use I'd never seen it matter cross-browser before

That said, HN works fine.

Post reply on HN