afaik there are no coins. Each account is merely associated with a set of transactions to it. The fees you pay to send money scale with a number of transactions that got you that money in first place, e.g. if you got $1000 from 1 transaction and send $1000 to someone, you pay less fees than if you got $1000 from 1000 transactions, because making the transaction actually work means joining all these old transactions into a new transaction. Also if you got $1000 from a transaction and need to pay $999 to someone, it will send the whole $1000 you had received to them and create a transaction to send you the change ($1) back.
Honestly I don't get why so much software gets access to the entire filesystem just by running it. They should have made it so an .exe can only modify its own directory, a temp directory, and any file or directory passed to it by the user through the system's file picker or command line. That would solve 99% of the use cases.
Every time I program something that deletes files I get worried about accidentally deleting the entire filesystem by mistyping something. I shouldn't have to worry about that.
One of the reasons that webapps get as much trust as they do is simply because they don't have unrestricted file access. I wish there was an application format that promised the same on the desktop.
I've read similar thoughts before about AI art. When the process was still developing, you would see AI "artwork" that was the most inhumanly uncanny pictures. Things that twisted the physical forms that human artists perceive with the fundamental pixel format/denoising algorithms that the AI works with. It was just uniquely AI and not something a human being would be able to replicate. "There are no errors just happy accidents." In there you say there was a real art medium/genre with its own intrinsic worth.
After a few months AI developers refined the process to just replicate images so they looked like a human being made them, in effect killing what was the real AI art.
>Why would you use <span class="small"> instead of <small>?
Because I can't be sure I'm using <small> correctly. The spec says "The small element represents side comments such as small print." and then says "Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements."
You know what this makes me think of? Those captions under images that says the source of the image. Like "photo by John Smith licensed under creative commons." I bet it's the wrong use for this. If it's the right use, then it's worthless either way because there will be a caption for an image in your website that doesn't have this sort of text in it, so you shouldn't use <small> for it, but you'll still want it to look like every other caption in your website, so you'll end up using a class for it anyway.
It's ironic people are relying on semantic tags for styling over classes while it's been repeated so often that semantics is not for styling.
>That's a specific example of indicating keys to press in a menu
Yes, that's what I meant. The fact that the spec implies you're supposed to write code like that God knows whom for doesn't change.
I think you're overthinking this. Use <figcaption> for captions and <small> for the small print:
<figure>
<img src="johnsmith.jpg" alt="John Smith">
<figcaption>
photo by John Smith.
<small>Licensed under a Creative Commons Attribution-ShareAlike...</small>
</figcaption>
</figure>
Some of them have default ARIA settings which I can understand, but others (like <mark>) don't seem to come with any.
I wish someone made a list of the practical effects of using this markup. The spec is ridiculously vague about all of it to the point of being unreliable. For example, iirc <aside> gets a landmark that should only be a top landmark (like a sidebar), but the spec seems to hint you could use <aside> in the middle of a paragraph. Why would I do that when if it broke accessibility?
I also think it sucks that semantic HTML has become de facto a poorly documented accessibility API...
I'm sorry for what I'm going to tell you, but this is exactly the sort of wrong use of the <figure> tag I mentioned about. In fact, your blog contains the PERFECT example of WRONG use of the <figure> tag, which illustrates why <figure> semantics are a lost game at this point.
The spec explicitly notes:[1]
>When a figure is referred to from the main content of the document by identifying it by its caption (e.g., by figure number), it enables such content to be easily moved away from that primary content, e.g., to the side of the page, to dedicated pages, or to an appendix, without affecting the flow of the document.
>
>If a figure element is referenced by its relative position, e.g., "in the photograph above" or "as the next figure shows", then moving the figure would disrupt the page's meaning. Authors are encouraged to consider using labels to refer to figures, rather than using such relative references, so that the page can easily be restyled without affecting the page's meaning.
The point of <figure> is that the element can be REMOVED from the document and moved elsewhere without changing the meaning of the document. I assume the intention is that you say "see figure 3" like a textbook. If you write something like:
>I was familiar with it’s interface from few screenshots like the one shown below
There's no way to move the <figure> containing the screenshot to a sidebar for example, because then what you wrote wouldn't make any sense.
If <figure> was being used the way it was meant to be used, it would be trivial to write a browser plugin that hid all figures and listed them in a sidebar. But nobody is following the spec. Everyone in the planet is using <figure> as if it was just a container for an image with a tag for the image caption (pandadoc, wordpress, etc., are all doing this!), so that's in practice what it is now.
This is what makes it so hard to understand who would even consume these tags for something useful. It seems every time they're widely used, they're widely used with semantics that don't match the spec, so if you wrote a markup-based tool, you would have to go against the spec, which means there is no point in having a common HTML spec in first place, just make your own API like microdata. I'd even say the only reason that browsers work at all is that authors are forced to see their websites through a browser so the markup has to at least work in the browser. For every tool that authors don't all use (such as a browser plugin that hides figures), there's no way to guarantee the author used the markup correctly, so it's not something that can be relied on.
Oh, you are indeed right about the figure element! Sorry for missing your point at first.
I would not blame this on pandoc though, it's my mistake of missing what the intended purpose of figure element is, because I haven't studied the spec and browsers doesn't do anything useful with it (as you pointed out). That said if I used pandoc to generate pdf via latex, I would have noticed that, since the figures are repositioned as expected in such case.
And while I agree that in the current state, it's kind of pointless for browsers to try to take advantage of this element when most of the real code is against the spec, I believe that it didn't help that browsers didn't do that in the beginning when nobody was using it yet. But since the spec is not explicitly asking for anything, browsers did the bare minimum.
While I can imagine 2 use cases already:
i) better layout of printed page (eg. when I try to print my blog post, firefox will happily cut a figure in half if I select print on a5 paper even though it could try to reorganize it bit smarter ...)
ii) similar to what you describe, an ability to show the figures in a separate window so that you can see the text and figures at the same time (this is actually similar to a picture-in-picture like feature for images what I describe in the blog, and to be honest I would still find that kind of useful)
I've always felt the main use case of HTML is for a single page document, like PDF. When it's for that, it excels at what it does. But when you have a website with multiple pages where 90% of the HTML is copy pasted from the rest, it just stops making sense. So for most of HTML's life, we've used the wrong tool for the job, but because it was the only tool we had, we used it anyway.
HTML should have had first-class support for templating, in my opinion. The model should be that a page references a template by a URL, and the browser won't render anything until it has fetched the template. But they were adamant in sticking to the isolated document model that hasn't made sense for pretty much all of HTML's applications.
I wish Google or Microsoft would come up with a replacement for HTML that was website-aware. It really only needs to replace text/html with text/html2 and have the server send this new markup that is parsed in a different way. Most web technologies could remain the same and it would be a huge leap forward. In fact, considering how much the code generation is done by frameworks anyway, most developers wouldn't even notice they aren't sending normal HTML anymore, just like they wouldn't notice when HTTP2 is being used.
> But when you have a website with multiple pages where 90% of the HTML is copy pasted from the rest, it just stops making sense
Yeah, don't do that. Use server-side includes for all the common elements. If your server doesn't support server-side includes then they're pretty easy to replicate with a couple of lines of JS, or via a web component. (But HTML really should have a client-side include tag. The Object and iframe tags sort of work but not properly.)
> So for most of HTML's life, we've used the wrong tool for the job
Hard disagree. HTML is great for large websites, e.g. news sites and wikis, etc., especially if you have a decent server setup. It's not so good for web apps, but we all know that.
> HTML should have had first-class support for templating
Would have been nice, but it's easy enough to just do that on the server with SSI or PHP, or XML+XSLT, or any of the many server frameworks.
the author wasn't saying this can't be managed by tools, I believe they're saying its kinda insane that we have tools to automatically assemble huge stacks of html on the server, very little of which is different each time, then send the whole glob over to the user.
and that ideally it would be supported natively in the language rather than requiring find-and-replace tooling
Yes, I forgot to include it in the original comment, but besides frames and AJAX we also have static site generators, from no-code stuff like Frontpage all the way to Hugo, and server-side templating like PHP, Jinja, etc.
These are all solutions to the same problem: HTML lacks this natively. Web browsers had 20 years to provide a solution for literally copying text code and they were quicker to implement WebGL and web assembly...
And the worst of all is that the only "templating" solution we got with <template> made the same mistake as frames did: the accessed page is the root and the included code is the children. HTML needs dependency inversion. Just like we include a single bundle.js that controls all pages in a website there should have been a way to include single template.html that defines the layout used through a site, the JS and CSS required by this layout, and other reusable template components too (which, imo, HTML should be to render without needing JS. Seriously, I should be able to write a web-component <my-h1> that unpacks to <div class="h1-wrapper"><h1> without needing JS because that cover 50% of the use cases...)
Content is just text, a more expressive form of raw data. It's the organization and description of that data which makes it useful. For example steps in a set of instructions are less valuable than the instructions as a whole when clearly organized as a series of steps. This remains true regardless of the context, format, or means of conveyance.
Whether HTML is provided as a full document or in micro-segments with/without templates is irrelevant. This is actually a form of empathy failure. Templates exist as a convenience to developers as necessary to reduce or eliminate code repetition, but your users are reading the inter-working of your source code.
I understand, but by this logic, no technology matters so long as it gets the pixels on the screen, because that's what the user ultimately sees. In that case, why even use HTML at all? Just upload a huge JPEG that looks like a page and call it a day.
I think HTML vastly outgrew its use case because it kept avoiding breaking backward compatibility. It was obvious from the start, but we patched the lack of built-in templating with frames and then with AJAX.
That depends on how you define a user. In many cases this is too narrowly defined to a specific subset of visual users only and thus may present output that legally qualifies as discriminatory in many jurisdictions. What matters is not what is visually viewed according to a tracking metric but what is cognitively consumed by the intended audience such that it results in dedicated engagement or interaction.
Again, whether or not HTML outgrew its business case is irrelevant to whether it is properly deployed to its consuming audience.
A dynamic document format outgrew it's use case as a document format.
Programming separates out presentation and logic (html and JavaScript). This is a good thing. I'd like to see the separation to go further.
Locking presentation to logic language is a great way to stifle innovation, it's the same reason why we are not browsing the web through a pdf renderer.
Funny you mention that. I'm writing a plugin to replace Wordpress default markup for the ITALIC button, BOLD button and UNDERLINE button to <i>, <b>, and <u>, instead of the nonsensical <em>, <strong>, and <span style="text=decoration: underline"> it has by default.
I feel so disappointed with all the hand-waviness I'm almost considering using the <big> tag for big text. The only thing stopping me is that I don't know if I'll get a penalty somewhere for using a deprecated tag.
"em" and "strong" are locale and medium neutral ways to signal intent. For example, most non-Latin scripts don't have an italic form, but rather use a different mechanism to signal emphasis. As well, screen readers and even high-contrast views may not work well with such things as italic and bold, and need a different mechanism to signal emphasis and strong.
Also, underline doesn't work for vertically oriented scripts, and is usually just another way to emphasize, which is why it was moved to styling instead.
I understand, but honestly this is really not my problem. That's the problem of someone reading and writing non-Latin scripts. In my Latin scripts, I see bold and italic and underline all the time and obviously I need a way to mark these, since they have very well-defined textual semantics in the kind of script I'm working with. If these semantics don't apply to Japanese, for example, then just don't use <b> and <i> in Japanese? Make a <傍点> or <sideline> tag for Japanese that shows up in the Japanese version of Wordpress and other CMS's.
Why would someone writing English have to think about how bold text looks like in Japanese? That makes no sense.
Even for accessibility it makes no sense. As far as I know, screen readers don't even announce bold/italic/em/strong or them differently. And if they announced, I'd expect any italic text I ever write to be read out loud as "in italics..." not "in emphasis..."
I genuinely can not understand the thought process that went into creating these tags. It's like they completely ignored the idea that text as a medium has its own layer of semantics and tried to skip over it. But this is just my personal opinion. In the end the objective facts are that <em> and <strong> don't really do anything in the real world besides wasting more bytes than <i> and <b>, so there's exactly zero benefits in using them.
I really wish someone would prove me wrong, though, hence this thread.
As a (relatively, though age is catching up with my vision, admittedly) able-bodied Westerner who reads no other languages than English, I find this opinion shocking. Would paraphrasing your point as, "I don't think anyone who reads in any way other than the one I'm familiar with deserves knowledge," have a different impact, or does that seem ok to you, too?
No. The correct paraphrase would be "I think you should recognize that text is different from speech and English is different from Japanese and welcome the diversity of media of knowledge instead of trying to make an one-size-fits-all solution for every method to convey information that the human body is capable of."
Imagine if I had a markup language for voice synthesis. If I typed a word, the computer would say out loud that word. But I had tags like <whisper> and <yell> to change the volume of the computer voice, and <pausedly> and <quickly> to change its speed. These tags make no sense in the text medium, and yet their semantics are self-evident in speech.
If authors had a way to mark up how their text should be voiced, perhaps they would mark them so. Who wouldn't love a real <sarcasm> tag for sarcastically voiced text? But HTML went the opposite way. Instead of providing more tools to let authors express themselves, they took every format of expression and dumped it in a single label.
Changing the context to voice markup doesn't in any way change or address the core point, which is that you really seem to be expressing that you only care about the way that you happen to consume text and therefore any other viewpoints are superfluous. Also that you're willing to go out of your way to create and publish a plugin to effectively sabotage anyone trying to do anything else.
Of all the opinions someone could hold strongly, that's certainly one of them.
>you really seem to be expressing that you only care about the way that you happen to consume text
No, I only care about the way I write text. If I'm writing an article and I want to make text bold, I don't want to waste my time having to come up with a deeper explanation about WHY should the text be bold. That's an obstacle in the creative process. I want bold text. Period. I don't want <em> or <strong>, and I don't want a "bring attention to" element". I want bold.
Can you say that EVERY SINGLE TIME I want bold text that will match the semantics of <strong>? If that's true, then it shouldn't be called <strong>, it should be called <bold>. If that's not true, then one day I'll mark something as <strong> because I want bold text and it will be the incorrect tag for that text because of a semantic mismatch. In that case, what should I do? Should I just use <span style="text-weight: bold"> or <span class="bold"> for my bold text? Are you telling me that every time I want bold text I'll have to make the conscious choice of deciding whether I should use a <strong> tag or a <span> tag? Can you imagine the nightmare of making this work in a CMS like Wordpress? It would be much easier to just never use <strong> at all and just use <span> for bold every time.
If the only way to make sure you're using the semantics correctly is to just never use the tag at all, I say we just give up on this <strong> nonsense and use the <b> tag which matches the semantics of what the person writing the text wants to convey.
> I don't want <em> or <strong>, and I don't want a "bring attention to" element". I want bold.
When I read the above, I thought: you want bold, because you want to highlight a word. Because highlighting a word is a widely recognized way to bring attention to it. And so making it bold is just a tool, it's secondary to the actual goal.
I suspect you might not agree with that, but could you point me to the part where I got it wrong from your perspective?
The problem is that you're trying to come up with a reason for the text to be bold. The reason the text is bold is simply because the writer wanted bold text. Bold is the tool and the tool that the writer chose was bold, specifically.
Trying to come up with an universal reason for why bold is bold is like trying to come up with an universal formula to explain why any number 42 is 42. You wouldn't say every 42 came from 40 + 2 just because 40 + 2 equals 42, because some 42's come from 44 - 2 and others come from 6 times 7. Similarly, there is no universal reason for bold to be bold except for the fact that it is bold and that is it.
You say bold is used for highlighting. What would you say italic is used for then? And underline? All caps? Small caps? Title case? Colored text? A yellow background on the text? There are countless ways to highlight text.
Do you have the courage to style <strong> as ANYTHING but bold or <em> as anything but italic? (oblique doesn't count!)
No, you do not.
Because in your heart you know. The writer CHOSE bold. He CHOSE italic.
He had all these "highlight" tools in front of him, like a palette of colors, and he specifically and unambiguously picked bold. You can't ever change the meaning of bold to anything but bold, regardless of whether you use <b> as bold or <strong> as bold, because bold is an inseparable part of the content now.
If you changed <strong> to a non-bold red color text, it would change the typographic semantics of everything ever written with <strong>.
So in my view, it's not something abstract like highlight, it's literally bold, in its pure concrete form, because the author had a healthy vision, he spoke a Latin language, and he wanted his text to have bold letters.
I mean, just look at Wordpress and WYSIWYG editors. Nobody in sane mind would write "emphasis" and "important" text unstyled and put those buttons in the editor, because no author would EVER click on them. No author WANTS to mark emphasis or important text. Authors click the B button and the I button because they want bold and italic.
Can you imagine someone looking up Markdown's or restructured text's to find out how to mark "emphasis"? Nobody is writing text or *text* or _text_ or __text__ because they want emphasis. They're looking up which one of these characters generates BOLD text.
What the author means is BOLD. Means. As in meaning, semantics. It makes no sense to second guess what they really mean and change those semantics to emphasis/importance just because you think those are human-language/medium-agnostic and thus more portable. When you change <b> to <strong> what you're doing has a name: semantic bleaching, which happens when a word that had concrete meaning loses its meaning when it starts functioning in a more abstract (grammatical) way. Feels like the opposite of what anyone would want!
OK, now I can see that there could be e.g. a two-word brand name, where one of the words is simply bolder than the other, as a purely visual effect.
And then IMHO it would be incorrect to use <strong>.
As for the difference between <strong> and <em>, they way I understand it is:
> <strong>Hacker News</strong> is <em>the</em> site.
Basically one highlights a term (say, it could be then looked up somewhere), and the other adds spoken emphasis--in the above sentence, HN is not some site, it's THE site we talked about before.
The standard way of rendering (or priting) words with such semantic meaning is respectively bold and italics. But if you ask me it could also be underline and uppercase (respectively).
And if you render the page not to a visual medium but to sound (screen readers), then you give the screen reader a chance to treat (and read) those words differently.
>if you render the page not to a visual medium but to sound (screen readers), then you give the screen reader a chance to treat (and read) those words differently.
Good argument, ignoring what occurred in practice.
Every person with healthy vision writing a Latin language is using <strong> as bold, and most of them don't even realize it because it's hidden behind GUIs that show a B (bold) button which generates <strong> code. If you make this an issue in their tracker they will just tell you <strong> is more semantic and <b> won't be used.
Regardless of what the semantics of <strong> should have been, in practice you just made <b> with a longer name. In other words, there is no reason to use or have made <strong>, since the end result was just <b> again. Screen readers could have just done what they do with <strong> (i.e. nothing) with <b> and saved us all a lot of trouble.
I can say that almost every single time someone wants bold text now it will be a <strong> tag, even if the semantics are wrong.
> In other words, there is no reason to use or have made <strong>, since the end result was just <b> again
So waitasecond, <strong> was created, airheaded developers of WYSIWYG plugins messed it up, and that retroactively means there is no reason for it to have ever been created? That's a real pretzel you're twisting.
How about: "Programmers of WYSIWYG widgets should just stop messing things up, i.e. sabotaging the efforts of the blind and other people who use/develop screenreaders—so we can finally achieve the accessibility wins that <strong> was created to solve"?
> Screen readers could have just done what they do with <strong>
No, they can't. Not in the sense of, "There's a problem that exists. We want to solve it." Your proposal is to ignore the problem and do nothing. You can apply that approach to anything. (Heck, why even have screenreaders at all? People who are blind or dyslexic are shut out from the Web? Let's just do nothing.)
Imagine writing code that outputs to HTML for your company. They require support for emphasizing some words, so you use the i and b tags.
Your company then decides that Japanese text should be supported. Now your code needs to output italics / underlines for English, or emphasis dots / enlarged text / font change in Japanese. You dutifully add the style sheet shenanigans and special case HTML generator code to do this.
Next, your company wants to support Hindi. So now your code needs to support three different ways to render the text depending on intent and language - with all the maintenance headache this entails.
... and so on.
Soon enough you start to think "This is crazy! I'll just make some style classes for things that need emphasizing, and then put the presentation stuff in the style sheets. That way I can greatly simplify things!"
And now you've invented em and strong.
The whole reason why style sheets were invented was to separate intent from presentation. The i and b tags in HTML are a classic example of engineering failure due to the assumption that they knew enough about a subject outside of their wheelhouse, and as a result failed to consult the experts (in this case, typesetters). Once the experts weighed in, the i and b tags were (rightly) deprecated.
As far as I know screen readers don't seem to differentiate between <em>, <strong>, <b> or <i>[1]. If the checker flags this despite there being no actual effects in the real world, it would really make me doubtful about its accuracy...
>Mainstream screen readers currently treat B/I tags identically to STRONG/EM tags. That is, they are ignored unless a user specifies that they be indicated. Some users report that announcing changes can be distracting.
That page also lists examples of semantic and visual uses of bold and italics, which sound pretty reasonable to me.
As for it not being critical due to inconsistent screen reader support--it sounds like a chicken and egg problem. If developers don't use those tags consistently, then people using screen readers have hard time with them, and so screen readers adjust.
In any case, if it doesn't hurt but can potentially help, I personally prefer to use semantic tags to convey the meaning and visual styles for pure visual effects.
I noticed this same risk-averse "generic" phenomenon about article bodies. I was trying to design a wordpress theme for my blog and I was googling some things and readings articles. I had multiple tabs open and while I was in the middle of an article I realized I couldn't even tell what website that article belonged to!
Every website was white with black text on it. Web "design" seemed limited to picking which color should links be. When you notice this, you start seeing it everywhere. Every article just looks exactly the same. They were all forgettable and devoid of personality. It seemed as if branding didn't reach the content of the article and was just a crown worn on top of the content, literally, at the header.
> It seemed as if branding didn't reach the content of the article
Good.
> They were all forgettable and devoid of personality
Are you similarly upset that books are so "devoid of personality"?
The work of a book designer differs essentially from that of a graphic artist. While the latter is constantly searching for new means of expression, driven at the very least by his desire for a "personal style", a book designer has to be the loyal and tactful servant of the written word. It is his job to create a manner of presentation whose form neither overshadows nor patronizes the content [... whereas] work of the graphic artist must correspond to the needs of the day and, other than in collections, seldom lives on for any length of time[...] The aim of the graphic artist is self-expression, while the responsible book designer, conscious of his obligation, divests himself of this ambition. Book design is no field for those who desire to mint the style of today or to create something. --Tschichold, on the form of the book
We should be so lucky if web designers grew up and subordinated their impulses—of imparting their (eventually unfashionable) "personal styles"—to their duty to serve the page and the content the way that it is done with books.
Not at all. Because there are many books with colorful designs and unique visual language. Any textbook or magazine you pick will have more visually interesting articles than webpages.
