The whole document is good, but in particular, my favorite part (that I reference not infrequently in conversations) is the priority of constituencies:
> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
But when designing a standard, if you ignore the needs of implementers you can accidentally write yourself into a place where it becomes impossible for new implementers to completely implement the spec, so we're locked to our existing implementations.
I don't think that HTML has this problem so much, but it's absolutely an issue with both CSS and JavaScript.
It's probably right in this context, but I'd be careful with the last part in general contexts: assuming utility is linear makes for easy reasoning but also would say that a mild stomach ache for every single human (i.e. 7*10⁹ stomach aches) is worth more than the life of someone.
This sounds tricky: since users depend on authors, both depend on implementors, and so on, issues and unhappiness may easily propagate from authors to users, from implementors to both those, etc; similarly to building a project with increasing tech debt, but at multiple layers. And then there is the question of application of this approach: whether one should consider picky and advanced users, or clueless ones, diverse users or an approximated average user, and likewise further along the chain, which is likely to lead to different results.
> Some sites rely on the <u> element giving the presentational effect of an underline.
> The b and i elements are widely used — it is better to give them good default rendering for various media including aural than to try to ban them.
“Some sites”… “widely used”… yeah, because that’s the purpose of those tags. To underline, bold, italic, respectively. This isn’t some concession we should be giving to legacy user agents, it’s the whole original stated purpose of the tags. Any attempt to retcon them to mean other stuff in the name of (something something) “media independence” or some such academic nonsense, is totally backwards.
I know that large parts of this article agree with me, but I still get angry that HTML took this purist direction to make huge swaths of markup useless in the name of semantic/display split that no user actually asked for. When I first read about the em tag and how it is the new way to do what the i tag used to do, I knew the whole thing had already been driven off a cliff.
The puzzling aspect is that, contrary to what most people would assume, the B, I, EM and STRONG elements all came out under the same version (2.0) of HTML: https://meiert.com/en/indices/html-elements/
No, there is a clear distinction between typographic and idiomatic markup. The i and b elements are considered typographic elements, not idiomatic ones (as em). So newer standards actually made them idiomatic.
When posting old pages/articles it may help if the OP explained why they are sharing on HN. Is there a particular question it answers? Is there some development that has made the article more or less useful/accurate? A comment would help guide additional comments.
I wholeheartedly agree, but I do appreciate it when submitters leave a top-level comment alongside the submission. There's no need for it to be special in any way, but it can help seed discussion IMO.
I see most internet forums as discussion groups where posts start out as invitations to conversation. However, I see HN more like a physical bulletin board in a workplace break room where people post whatever, whenever, and others passively view, interact with, or discuss it as they see fit.
> The audience here is sympathetic to this topic, of course—but lists don't make great HN submissions. It would be better to pick the most interesting / least known thing on the list and submit that instead.
I'm picking some URLs from that list, this is one of them.
I actually like this, also in cases where users sometimes post a submission that relates to some previous discussion, but does not require the context of said discussion but are interesting on their own
I actually like this, also in cases where users sometimes post a submission that relates to some previous discussion, but does not require the context of said discussion to be interesting.
I'm so bored of the "Do not Reinvent the Wheel" line.
Why? I want it to be my wheel, what is wrong with reinventing the wheel?
Inventing creates innovation and innovation sparks creativity and that's what programming is all about; creating. So if you don't your stuck with someone's else invention, that's no fun. Why should I use their invention and not mine?
> If you are in the business of carts, buy wheels.
I just don't agree with that logic. If you make your own carts, innovating your own wheels will yield cheaper costs in the long run. You have a new design and it could be something better. In conjunction you can than produce your own cart to that better design.
Sure your not a wheel business, so you don't sell your wheels as that's not your specialty but you can now provide your own wheels for your own carts.
Otherwise your vendor-locked to that manufacturer. And what then if they decide to stop selling the wheels or carts that you rely on, or increase the prices?
You don't have Amazon (Cart) selling Google's Infrastructure (Wheels).
Innovating your own wheels to sell carts requires capital investment, time, effort, and risk. The saying is a rehash of common advice to focus on core competencies and not overextend.
If I sold, or even manufactured carts, I would not be eager to enter the enormous, competitive, highly commoditized, and mature wheel market. It sounds like a real battle to get production costs even on par with wholesale, lacking all the economies of scale, experience, and supply chain agreements the major manufacturers have.
Who says? Its flawed logic that for example makes the internet or any product cheap and stale.
This era of mobile phones is a good example, when providers created their own device before selling out to Android, it was a fantastical place. Now when choosing a phone all you have is a different same rectangle with the same OS.
If you hire the expertise, you add that in to cost factor of your company. Or you set a budget and in creating your own variant while you sell your first.
I open a cookie shop. I sell pre-made cookies that taste amazing and make customers happy.
You hire the kitchen staff to make your own cookies, not as good and they don't sell as well.
You keep going and keep growing the quality as you slow down selling the amazing cookies.
Because as an scenario, say the company who's providing you with amazing cookie changes their recipe for budget cuts and now they're now not selling as good as before, bland and sickly. You lose sales and by not reinventing the cookie you lose quality, rep and profits.
I'm just amazed no one can give me a good case to why not. Innovation is what's missing from this world.
If you’re selling cookies, are you going to be milling your own flour from self-grown wheat? The original post was just saying at some point you are drawing a line between what you consider to be your competency versus what is not.
Regardless to how stubborn it makes to the comment, Yes. I don't see why not. There is no versus to be had. We are always competing, it doesn't have too. As in the end all that really matters is making the consumer,customer, end result happy.
By milling the raw grain, you can then make your own machine. With that machine reduces the production costs. It's not a task that can happen overnight.
But to own a piece of land and to make raw produce from that isn't trivial.
I agree that you can always own more of the vertical to potentially make the customer happier, but you will always reach the point of diminishing returns. How much happier will your customer be with your homegrown flour versus King Arthur flour you picked up at the store? Is the cost (money and time) worth the possible marginal increase in happiness? If you manufacture your own machine, does the capital expenditure of doing so even offset operational expenditure over how long you even plan to be making cookies?
Running a business is not about innovating at all costs at all times, it's about using what time and money you have on hand to optimize customer satisfaction. Whether it's off-the-shelf wheels for carts or grinding your own flour, you have to draw the line somewhere otherwise you are just optimizing for some theoretical optimum. Maybe when you have some more slack in the budget it's time to think about reinventing the wheel, but doing so at the get-go is already losing sight of the customer.
And I would agree to a degree. Your product are cookies which uses King Artur's flour. You invest at the same time and create your own flour Queen Guinevere.
You sell Queen Guinevere cookies within the same line, sure it's not selling as much. The means isn't making the worth but you still invest. Suddenly King Arthur flour quality drops, they implement a cheaper method of milling which produces a less superior product. This then causes an decrease in customer happiness too. What then?
You've already made optimization on the cost of that King Arthur is always going to produce the same quality. The cost to optimize another product is going to be a far wide expenditure and nor do you know if it's quality is viable.
If you've already planned as a disaster scenario that if this was to occur; you'll use another product. However, during the period to disaster some new cookie store has come in to the light and is now using your backup: King Louie flour.
So now, not only are you flogging your product, you have someone else using your backup brand where by using it could cause some sort of turmoil. Meanwhile, if you had continued to invest in your own flour you still have your own product and can now instead, decide to use it to produce something else like crumpets.
Sure, as a cookie grain, may not be as best-seller, nor best the same quality, nor make the same sales but you still have a product that you can sell and improve. Your own product, a new product, crumpets.
I'd agree that this comes to moot, but does demonstrate the scenario of both degrees. Overall, agree to disagree that it comes down to: You started a business for a reason.
Dependent on that reason, and is it because:
A: Yourself, wanting to be a business, wanting to innovate, construct, produce for yourself, to provide to others maybe, Spare time on hands, self-Happiness? Your not trying to compete.
Or B: To compete, make money, to become the next top dog. Capitalize.
If it's B, then yeah. Your not interested in quality and will always rash-produce and regurgitate the same as every one else. Construct and push as fast as you can because you've got to compete; while it makes you the next top dog, it doesn't create anything new.
And this is the point I'm making. If the business still invested in their own product, their own wheel they could still become the next-top-dog as such and not only that; have a product that's shiny and shines above the rest. That's what's lost in this world. Reinventing the wheel does exactly that.
I guess this comes as the consumer, a script kddie, seasoned SysAdmin, rookie programmer, who stands in the world and looks at all the next-top dogs but all holding the same rehashed shite, where once I've seen, experienced and witnessed different companies, developers, things where made different products with their own different wheels.
I'm just tired and depressed of the dystopian A or B because of.
For the user, the problem is if you reinvent the wheel poorly. Remember all those terrible ‘scroll jacking’ website?
The bar to reinvent the wheel has to be high. You should have significant value to add, and you’ve got to re-implement all the other behavior users expect.
Select inputs are a decent example of why people reinvent things. There's no native combobox type input; html5 gave us list input + datalist, but no multiple selection. If anything, the select element has been a perfect example of a bad interface design: it is extremely difficult to use with large lists, but the lack of native combobox has had people reinventing the select input for years.
Number inputs have always been a vile thing to work with, as is the "required" attribute.
The funniest part about the phrase "don't reinvent the wheel" is just how often, like, actual wheels get reinvented. And for good reason - imagine sticking bicycle tyres on the landing gear of a 787 just to avoid "reinventing the wheel"!
> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.