The graveyard of HTML attributes which never gained public attention/usage is large and full of useful ideas.
My favourite was relational links such as
<link rel='first' href='/de' title='Homepage' />
<link rel='prev' href='/some/bunnies.php' title='Previous Page about bunnies' />
<link rel='next' href='/some/cats.php' title='Next page about cats' />
<link rel="copyright" href="/de/impressum.php" title="Impressum">
<link rel="alternate" href="/gr/samepage.php" hreflang="gr" title="Page name in greek">
Opera was the only browser which had a toolbar with these relational links. This was around mid-2000. Unfortunately, this toolbar never survived or got taken over by other browsers.
Some relations survived (such as rel="search" for custom search pages), some got killed-by-ecosystem (such as RSS).
I've made use of those even recently. Even if they're not used much now, it's potential future-proofing. And I've written tools that manage content and read these values to organise pages in a series.
yah, rel links are still usuable at least for machine-read purposes, if not the old 'back', 'forward', 'up', type site navigation links that browsers used to display if those were present in the document.
Who knows, maybe someone who works on Chrome or Edge or Safari is reading this thread and will talk to their higher-ups about using it somehow. (Wishful thinking?)
They had a toolbar for it for a while, and I used it for forums and search results. And then they got rid of the toolbar, and the rel link because used only for search engines.
I recall IE (even up through "Spartan" Edge, I think) had a hard to discover/not quite as useful in practice as it was in theory support for prev/next links: if you pressed the browser's forward keyboard shortcut or gesture (but not the toolbar button since that was usually disabled) when there was no forward history it would sometimes follow next links. Even harder to pull off in practice (given how most people navigate to websites from searches and stuff) if you somehow managed to land on a page with no back history and pulled off a back keyboard shortcut or gesture it would try the page's prev link. I think that feature probably confused way more people than anyone ever came to rely on it.
Your post was something of a blast from the past for me: toolbars! I had forgotten about those. I used to spend a lot of time customizing those. Then Chrome was released which really was the end for browser toolbars.
I seem to remember this was used by emacs' mode embedding the w3m browser. It was great to read long structured documentation sites by just pressing space-bar to "scroll" through pages.
In opera back in the days, if you pressed the space bar, it would scroll down like all browsers but if you got to the end of the page it would load the rel="next" or any link with <a>next..</a> in it.
You can show these things via CSS. By default they have `display: none` but you can change it something like `display: inline` so <link> appears just like <a>. You may need JavaScript to make the clicking work.
These <link/> attributes belonged in the <head>. It was page metadata, not a page element: the browser itself was supposed to give you controls for forward, back, etc.
I remember that as the first time when using default styling of basic elements produced unusable results. I have to ask, when did it become my job to solve things like this?? Hidden check boxes with a check box in a label is not a nice elegant way of styling something at all. It's closer to an ugly hack. I find it an upsetting development given how well everything else was designed.
It seems we are going to get more good ideas in unfinished form?
The definition of a range is: "the area of variation between upper and lower limits on a particular scale." Why would the user only get to configure 1 of the 2?
The definition of a slider is: a knob or lever that is moved horizontally or vertically to control a variable, such as the volume of a radio.
enterkeyhint="next" conceptually a great idea. Sadly it doesn't do anything? I wanted an attribute that makes the button go to the "next field".
Easily fixed by every developer individually a million+ times deep into the future.
The up and down navigation controls provided by the browser work exactly the way we expect them to.
We had a good thing going there. It does what it says on the tin. Its how I (and everyone else) like things. A stop button makes it stop. Scissors are to cut. The little floppy disk is to save. A play button makes it play. etc
It seems so fundamental? How could anyone get this wrong? The user wants working buttons on their interface. Buttons that behave the way they expect.
I think no one wants an enter key that looks like a "next" button. In case I'm mistaken about that they could simply add a different value domstring.
>'enter' typically indicating inserting a new line.
I have to inserts a new line at the cursor?
>'done' typically meaning there is nothing more to input and the input method editor (IME) will be closed.
I have to close it?
>'go' typically meaning to take the user to the target of the text they typed.
I have to submit the form?
>'next' typically taking the user to the next field that will accept text.
I have to move the cursor to the next field?
>'previous' typically taking the user to the previous field that will accept text.
I have to move the cursor to the previous field?
>'search' typically taking the user to the results of searching for the text they have typed.
I have to submit the form?
>'send' typically delivering the text to its target.
They had to come up with a name for a slider and called it range. This is the wrong name for it. A range slider should have 2 dots: One for the minimum and one for the maximum value. (Most common is searching by price in a web shop)
It means that if they ever want to introduce a real range selector it will have to get a different name.
It also means that if you search google for a range selector you are no longer able to find any of them. If a native one is ever introduced you wont be able to find it searching for range selector.
Also quite silly is that if you need both in your form you cant use this build in one as it will look different from your custom creation.
And it makes it harder to reason about forms. In the previous sentence I wanted to write "...need both a slider and a range selector" but that seems inaccurate/confusing.
Yes, every day since 2012 - I was a little late to the party, but managed to show up right around when it was really getting going. Unless the form is tiny and unzoomable, checkboxes have always seemed to work fine, no worse affected than any other web UI element by the essential imprecision of the interaction style.
I'm pretty bummed the title attribute on stylesheets didn't get the love it needed. We had a native, built-in theme switcher (except Chromium) that would have been prefered to some of the contemporary options of needing to put it behind user preferences. If it could hawe been fixed to persist the selection as well as not load unused, then we'd maybe see a different space.
Is there no JS APIs to use those either? Cause that would make it infinitely cooler imho, then you can surface it as a way to show off web app themes on the front-end too.
Nothing pre-built, but you can cobble something together yourself – query the DOM for stylesheets, evaluate their attributes (i.e. especially the "title" and "alternate" attributes) and then enable and disable them as required.
I wrote something like that for my homepage, although as I only needed to switch between two styles and I'm not a front-end person, I didn't bother with an actual selection drop-down and just wrote a toggle that cycles through all alternate stylesheets one at a time.
i still use this feature in firefox, and it's still one of my favorite little tricks to add to personal projects for a little flair. i'd only wish safari would support it as well (i don't care for chrome or google in general).
I highly recommend re-reading the entire formal standard for technologies you work with routinely, on a roughly annual basis. It's a triple whammy of refresher, update, and niche discovery.
I attribute this advice to Æleen Frisch; albeit without pulling my very dog-eared copy from the stacks, I recall that words to similar effect can be found in the epochal Essential System Administration (2002), possibly in the form of reading every manpage in your local Unix base system.
The form attribute on fields is very useful to decouple the What from the How (it is laid out on the screen). You might for example want an upload widget, which does a separate request, right next to some other fields. Instead of wrapping things in forms (which you cannot nest) you can now freely lay out your document. Similarly you might want several fields or buttons spread across your document and don't want to wrap everything with a big form, or several forms.
I’ve been meaning to use these attributes for the very reasons you mention, but I’d need to check the impact on the accessibility tree. I’m not sure of the impact of having the submit buttons in a completely different part of the DOM to the inputs.
The accessibility tree doesn't represent form elements in relation to their particular <form>, a submit button's position in the accessibility tree will be equivalent to its position in the DOM tree.
The button's name (optionally also its description) and to some degree its position in the DOM order (what heading and/or other form elements precedes it) needs to be sufficient to convey what will happen when it's used.
The <a download> attribute sounds great on paper, but if request fails for whatever reason your user will, very confusingly, download a file named exactly as you specify but with error page HTML as contents.
There is no straightforward way[0] for you to gracefully handle an error, which is quite an oversight once you factor in that network isn’t always reliable.
Having used it at first, I switched to server-side logic where I return data with Content-Disposition header if everything went well or redirect the user to show a proper error message in case of a problem.
[0] I imagine this could be worked around with some JS-based preflight or other trickery—which sounds like a suitable solution only if you have no control over the headers returned for some reason.
> The <a download> attribute sounds great on paper, but if request fails for whatever reason your user will, very confusingly, download a file named exactly as you specify but with error page HTML as contents.
Though that is at least consistent with other download options like right-click/save-link-as, so is probably not incorrect behaviour.
I’m OK with “Save as” (“Download linked file”, etc.) behaving as it does: it is more or less intuitively clear that with it we sort of “cheat” and use browser’s semi-hidden feature to interact with a website in ways not necessarily intended by its engineers. With the download attribute, however, any confusing outcome falls squarely on me, the developer, so I’d rather stick with plain links and response headers as a mechanism I have more control over.
There may be some workarounds to make download behave adequately in case of an error, such as having your server behave in some way that causes browser’s fetch sequence to fail with a low-level error. Unless I’m missing something, it seems like proper network error is the only condition under which download can actually fail, and I don’t think a typical web framework setup is equipped to intentionally cause that to happen. I doubt it’s worth the bother—if you have control over the server then why not drop the attribute and just return the appropriate headers.
I've had to do something like that for an awful application where the frontend did chunked downloads, but didn't check properly for the status code, embedding error pages directly in the downloaded file.
As I had no control over the frontend itself, I configured the reverse proxy so that for requests to download endpoints, all error responses would instantly close the connection to the client.
Your post makes me think that I could generalize this so that any error to an explicit download would close the connection at the network level. It would be quite tricky to be able to distinguish between implicit and explicit downloads, but I think that if the frontend, backend and reverse proxy coordinate well together, it can be done without introducing other problems.
Of course, it's a big hack that's not worth the bother.
This is true of pretty much anything that wants to directly invoke the browser's download mechanism. AFAICT the options are either:
1. Use JS, in which case one can handle errors and otherwise be involved in the request / response process. However, if you wish to offer a "download" funciton, this necessitates downloading all the data into JS memory before offering it to the user.
2. Use form-posting with `Content-Disposition`. One can no longer be involved with the request and response. And any response which does not have `Content-Disposition` will result in the browser redirecting. However, the user will be able to directly stream the download without your page being involved beyond initiating the request.
Since the data downloads are gigabytes in our case, we opted for (2). But I would also love to hear if I'm wrong about this trade-off.
If your user clicks the link with download attribute and your server (or reverse proxy, or CDN, etc.) issues an error page, user agent downloads the HTML of that page and saves it under the filename you provided. Domain does not enter the picture.
(Correction: per spec, the domain does enter the picture in that cross-domain <a download> is not supposed to work at all without Content-Disposition response header; that’s slightly different matter to what’s discussed.)
In my uses, I can be almost certain that I won't get a 404 back as a response, unless I forgot to do something - although the others are a concern. Even though Netlify allows setting headers and redirects, I obviously don't control the image they use or the CDN generally.
I haven't used the download attribute in a while, but the last time I felt it was a bit too finicky. E.g. only works if the file is on the same origin and there are more differences between behavior in different browsers than setting headers from the server. Think it is still a good enough solution in many circumstances.
Since modern browsers are capable of rendering pdfs, it's downright infuriating when a site forces me to download a pdf and take more steps to view it. For being a user agent, this feature certainly removes agency from the user. Afaik there is no way to tell Firefox or Chrome to ignore the Content-Disposition header for files it should already know how to render.
`Content-Disposition` also works for form submission. If a response to a form submission contains the `Content-Disposition` header, the browser will expose that to the user as a download and the page will not navigate.
enterkeyhint doesn't do anything on Chrome on Android.
Which kind of illustrates why a lot of these things are not well-known. Why do something that that works on Firefox but not Chrome/Edge or on Safari/Firefox but not Chrome, etc? Specs are great, but near universal, reliably similar implementation is key.
In a lot of cases it means you have to build edge case UX. I'd rather lean on UX that's mostly under my control and not at the whim of browser adoption.
What keyboard app are you using? I'm using OpenBoard (Pretty close to AOSP) and it changes the icon on the enter key for me. I'll make a screen recording in a sec.
I love the <download> attribute, it's a quick way to use the default file download mechanisms without having to bother the user with opening a link or prompting. I realize there is the potential for abuse, but if you're careful, it's wonderful.
Native lazy loading support is coming to a bunch of things in the near future, if it's not there already, so this one is living on borrowed time.
If you've ever tried to implement CSP on a site, crossorigin and integrity should be famiilar - alas, CSP is hard, but you already knew that didn't you :)
You're mixing up elements and element attributes. There is an <cite> element, which it appears Standard Ebooks uses, and a cite attribute, which is seldom used, probably because it's not exposed to the user in any way.
Writing "<download>", with the word in angle brackets, makes it look like an element but it's not, download is an element attribute.
Ack. Yeah, the first one is my mistake looking at it again - although I would argue this element is relatively underused because it's not something you would need outside of contexts where printing is a concern - SE is a slight exception in that they are starting from print transcriptions in most cases.
I am aware of the distinction, I only used that way b/c HN doesn't really have a good way to indicate code without multiple spaces or just blindly using the ` character which is...not great.
<cite> does have a default browser style (italic), Standard Ebook's use of <i> within it would be redundant on the web, I don't know if the conventions are different in EPUB.
How to use <cite> is often misunderstood. Many think it can be used to identify the author of a quotation but it should only be used to name the work a quotation is from. Standard Ebook placed it inside the <blockquote> but I've also seen it placed after <blockquote>, I don't know whether both are considered correct or if it's a point of disagreement; to me, <blockquote> should contain only the quoted material itself but I understand the appeal of having the quote and its source be neatly contained within one semantic element.
Using the Markdown convention of putting backticks around `code` may not be great but at least it won't be confused for the wrong actual code.
SE Editor-in-Chief here. We include <i> within <cite> because 1) reading systems often have different default CSS which may not even recognize <cite> and 2) <cite> often contains both a title and an author, and in those cases we want only one or the other to be italicized. SE's default CSS for epigraphs (probably the most common place where <cite> is found) is to give <cite> small caps, italicize the title if there is one, but don't italicize the author.
I believe our use of <cite> predates the modern definition of its use, and in any case it's so infrequently found in a web context that I don't think there's much agreement about how it should be used anyway. (For example MDN says the work title must be in <cite>, but at SE we often only include an author name, like <cite>--Shakespeare</cite>.)
Interesting, the permissible content in <cite> is mentioned as an example of conflict between the HTML standard as maintained by the W3C and that maintained by WHATWG [0] (W3C allows title and/or author, WHATWG title only). Since WHATWG has been the sole maintainer for a few years, I guess their definition "won."
> cite attribute, which is seldom used, probably because it's not exposed to the user in any way
I recall in a (lost) blog theme I had at one point in time I'd scrounged a nice bit of CSS to add cite attributes visibly appended to blockquote and q elements. Exposing it to the user is possible in just pure CSS, but it is a bit of a shame that browsers didn't style it by default so many people didn't learn it was a thing.
<q cite="https://www.w3.org/Consortium/">To lead the
World Wide Web to its full potential by developing protocols and
guidelines that ensure long-term growth for the Web</q>
q::after {
content: attr(cite);
}
That will show the source URL for a quote but it's not very useful, the URL isn't clickable (unless you wrap the whole <q> in a link), it's not even selectable text.
While the semantic web mindset (especially the "Xanadu" inspired subsets) thought cite should always be a URL, it didn't technically have to be per the spec. (Without browser behavior backing it as a URL, it certainly didn't have any enforcement to be a URL.) In my case I think I was using it for author annotations in a more "APA or Chicago Style Manual" style at the time I had CSS like that in the style of: —Author Name from "Book/Webpage Title"
Not selectable is still a bit annoying in that case, but Author Names don't need to be clickable links and the point comes across.
The current HTML spec says a cite attribute's value has to be a valid URL [0]. I don't know if that's a point at which the WHATWG and W3C versions differed, like on the <cite> element. I do think it came from a semantic web mindset, that the attribute isn't really for the user, it's for programmatic use by the web host, like a CMS, or other systems.
It used to be the case that the values of `content` properties weren't read by screen readers so this technique would mean the information was solely conveyed visually, that blind screen reader users wouldn't get it, but screen readers have been reading `content` properties for a while.
In any case, if the citation is important information to convey, it should probably exist at a text node in the document, not as metadata that gets pulled out and displayed by the styling.
Seeing the download attribute mentionend felt weirdly nostalgic. I wrote a short blog post about that attribute which shot up to the number one spot here on HN when I submitted it back in 2013[0].
In the nine years since that post, I have not once used it in a real project.
Those aren't part of HTML, rather features of web servers that are evaluated server-side.
Furthermore I think you can still use this stuff. Apache and Lighttpd are still perfectly fine web servers depending on the use case. Also nginx supports server-side includes and fastCGI.
The mischievous imp in me wanted to reply with something like the following: <blink speed="fast">how fast should this blink?</blink> ...But, then that's just not healthy for anyone. :-)
You got me, I actually searched for evidence that the <blink> element supported a `speed` attribute.
The MDN page about <blink> has example CSS to make the element blink again. If you wanted to make speed variants, you could use CSS selectors that set different durations based on a data attribute and its value:
I'm a bit surprised the autoplay attribute - at least how it's been used for <audio> and <video> hasn't been similarly consigned to the dustbin of history.
What is taking so long? /s
(Only a bit of sarcasm there, I actually would like to know...)
`autoplay` is rarely appropriate to use, but not never. If a link named "Play 'Never Gonna Give You Up'" goes to a page with <video autoplay …>, that's fine. If the user is informed that the action they're going to take will lead to audio or video playing, you don't have to make them click an additional thing (a "play" button) to make the content play.
When I worked on themes for a blog engine back in 2005/2006, I used the titled stylesheets to allow me to switch between themes quickly. There was actually an upper limit on how many you could have before browsers started breaking, but it was still a useful capability.
No one uses the <a> `download` attribute for the reason we stopped forcing users to open new browser windows with target="_blank", they know how to download (or open a new tab) if they want to, and it breaks or confuses more often than it works.
Who's using (or even heard of) <abbr> and <dfn> without `title`? I kinda thought that was what made them most useful, providing the full unabbreviated version for example.
target="_blank" wasn't replaced by user behavior, it was replaced by Javascript intercepting and logging and tracking every click.
That said, opening links in a new tab/window is the less-breaky approach these days, since every page that the clicks came from is a mess of infinite scroll and reactive components and all sorts of other state that gets lost by clicking to another page and trying to go back.
The download attribute is useful with images or files which the browser would normally preview. If I give my users a button labelled “Save PDF”, I want to know the Acrobat plug-in isn’t just going to hijack the response.
I used the download attribute recently to force downloads for attachments from another service, one whose Content-Disposition headers are outside my control.
The download attribute is helpful. For instance, my app is offline-first and the "Files" you can create with it are JSON. Therefore, it's better that they get downloaded so the user can open or drop them into the app without having to see the raw data.
That was the older thinking. Turns out users know how to use the back button quite well, and don't expect or know how to return from the pop-ups target=_blank creates, it breaks the back button. In user testing they report they think they've clicked a spam link, and it hurt our conversions.
That's before the accessibility concerns, users don't expect pop-ups anymore and find this confusing and difficult to navigate.
The download attribute is helpful when you don't have control over the mime types the server handles. Downloading is the sensible option as opposed to trying to display a .bin file.
Also, it allows you to ensure that if you have a button that says 'download', it will actually download the file instead of having it replace the application---the principle of least surprise.
an <abbr> can be marked as a abbreviation without providing the long form via a title, if you don't know the long form but want to note it as an abbr, or if the abbr is titled previously and you're reusing the same abbr multiple times in the same context.
I expected to read this article and think "yeah, no wonder I don't use those", but those first 2 in particular are pretty dope. The "Page Style" dropdown in the browser is something I never really thought you could add to. I think I know the next thing I'll play with in my next personal project. :D
There are so many fun things a browser could do in it's user interface. For instance HTML defines <link rel="previois|next|up|contents|glossary|..." href="..."> which could allow to have navigation for manuals and similar documents.
Or imagine web browsers providing upload progress ;)
But well, designers like to give all that their custom design.
It's not the designers fault that browsers provide ridiculously bad default form controls with almost no way of styling them. Really, we have WASM, Bluetooth APIs in JS, and boatloads of other extremely advanced engineering feats in browsers -- but they can't be bothered to provide usable form elements? Just imagine all the developer time wasted on creating progress bars or date pickers...
When I got frustrated with the user needing to be able to re-edit a form with waaay to many fields and the option to add more fields of various exotic types. I wrote a hilarious hack where I just went over the input elements and elm.setAttribute("value", elm.value). Then I rip out the entire form innerHTML, POST it and store it in the database. Want to edit it again? Here you go! When displaying the content wrap the form in: <fieldset disabled="disabled"> and add some border:0;color:black
For such a terrible idea it looked remarkably clean.
it loads the sheet on every page load while only 1 in a million visitors use it. Then when they use it their preference is discarded when they navigate.
The enterkeyhint is brilliant. Yet it's sad it can't affect physical keyboards because it would be an ergonomic boom for all the non tech savvy people (input order and submission is often slowed down and confusing due to that, yet something that was leaner in old as400 terminal UIs).
Maybe keyboards will have a few lcd keys, or for cost cutting a colored led keys to match these kind of hints
Keys on Optimus Maximus keyboards have individual LCD screens. Quite pricey last time I checked.
> non tech savvy people
Tech, in many situations that intersect with non-tech people, is now some form of touchscreen with an onscreen keyboard.
Exceptions are corporate HR departments, whose hardware, software, and flow seem to ignore the fact that phones are the primary Internet device now, not PCs like it was in the 90s.
If your actual job requires you to use a PC, you probably simply just need to learn to use a keyboard because the apps you are using are going to be complex to, e.g. Office suite, etc.
> you probably simply just need to learn to use a keyboard
it's not the keyboard, it's the meaning 'RET' has for a particular form. It can be a per field 'accept then go next' it can be 'validate the local group', 'validate the main form and submit it back', 'accept a partial choice but don't change focus'. That's why the hint is brilliant, it removes confusion.
Also people who need this knowledge are never given good tutors. It's mostly "deal with it, and be fast or else.."
I don't really see the point on a physical keyboard. It makes sense to repurpose the enter key on a phone or tablet where there's limited real estate and the keyboard covers half the screen. On desktop/laptop, that isn't necessary - you can just tab over to the next field (or click it, for the less tech savvy), and click the "submit" button.
Also, it's right in front of your eyes, so it's clear when it says something else. Your computer keyboard isn't, and people don't usually look at the enter key before hitting it (even hunt-and-peck typers should have the enter key committed to muscle memory). Forcing people to look down at their keyboards before hitting enter would make ergonomics worse, not better.
>Maybe keyboards will have a colored led keys to match these kind of hints
There are enormous numbers of keyboards with per-key RGB lighting available. And the host OS can control them (right now my keyboard is lighting up with the music)
I like the title property, especially on <a> elements, but always found that there was too much delay to discover it as a user. Like I wouldn't hover that long on a link/abbr unless I knew something was going to pop up.
I think this is one reason people quickly move on to using popover libraries for simple popovers.
The loading attribute is more interesting and useful but I think it's already fairly familiar to Smashing Magazine readers. I think the decoding attribute could be useful for page rendering on very low-end devices, maybe also on pages with a very large quantity of images.
The web standards are large and complex. I still discover new parts of the standards almost every month, even if I have made websites since the stoneage, in 1995. The title attribute of stylesheets was new to me.
These are not equivalents. Input type=search can have side effects in that it renders the input box differently, for example with a "X" inside to clear the search. Which may be good, but it may also conflict with your design system.
Yes; personally I’d rather have a type=search to have the semantics and then apply CSS on it, rather than a type=text with no semantic meaning at all that’s modified to behave like a type=search.
I have a recollection of early versions of Firefox exposing the stylesheet switcher in the footer chrome. Maybe it was an extension though? I can't find references to it online.
Firefox's style switcher is in the View menu ("Page Style"; try it out on <http://virtualplastic.net>). The statusbar style switcher was from the Mozilla suite. There was a nostalgia-fueled extension for reimplemented the original statusbar widget in Firefox.
Congratulations on finding a menu item that I had no idea even existed. I don't know how it is possible, but I am pretty sure I have never seen that menu item before. I will be trying this out on various web sites now. Thanks!
I was never around when they actually existed, but I have seen mentions in books and things. IIRC Netscape translated CSS to JSSS internally, at least at first.
I also like the `formaction` attribute that can be added to buttons and input-buttons in forms to specify different actions. I used it to let users choose between multiple payment methods.
To clarify, they can specify meaning, data, and behavior. Technically the `style` tag applies any abstract styling, and there are attributes for things like table-related elements that can change the superficial appearance (not sure which one that was); just pretend that the latter isn't a thing.
You do remember the hell that was the font tag, don’t you?
I think a lot of confusion from HTML being used for UIs vs hypertext documents. It’s a natural evolved mess still balancing the two.
But style should apply to the applied representation, while HTML should represent the intent of the content. The line is fuzzy, and HTML/CSS has a bad history of what falls where.
The cool thing with browsers is that we can bake in style to support multiple representations at once: monitor, mobile, printer, etc. Using the style attribute directly is mostly a side effect of only targeting the browser. Although your example of relative units is more ambiguous. Using a proper tag to represent the intent or falling back to a class where HTML lacks one would be preferable.
I think the separation makes more sense if you’ve used other document systems. SGML or XML DocBook, LaTeX, ROFF, etc.
For the last, if I use the man or mandoc module, all the man page norms are there for me and I’m just plugging in the content with the right macros.
W/o, I’m manually flipping registers all over the place.
Neither is necessarily "better", but rather they are different design choices. HTML at first wasn't intended to have very much styling at all, and originally there was some more styling mixed into the HTML itself (like <font>, bgcolor, etc.). Since now we pretty much want to make our webpages look like anything, it seemed to make sense to those drafting the standards to separate the two concerns, since HTML is mostly about page flow structure and data display, and page sources would be even harder to read than they already are if everyone was just putting their styles within HTML tags. If you're looking for a data attribute, it can be hard on the eyes to be constantly sifting through attributes for styling.
You certainly can do things to overload attributes and do what you're suggesting (in a sort of hackish way), and you wouldn't necessarily be wrong in doing so if that's your preference. Many people just don't like that.
One of the great things about separating styles out of HTML is that they can be contained in files and included separately. With poor connectivity, ideally, it's beneficial to keep the main page source to be as slim as possible so that it can still be downloaded and read even if the styling hasn't yet finished downloading. That's not nearly as relevant anymore, but it would not be surprising if keeping pages lean was a motivator in moving away from putting more stuff in HTML.
Contrary to popular belief, HTML and CSS are unrelated.
If any CSS property was also an HTML attribute, any addition to either spec would have to make sure it wouldn’t conflict. One example is the `content` HTML attribute and CSS property. They serve different purposes and have a completely different syntax.
Thanks for lecturing me, I'm aware of all that and know the genesis myth of CSS ;)
Sorry but I think you guys/gals don't get it - the question is why do we need two item-value syntaxes. Like, HTML has 'bgcolor=black' as markup attribute, and owing to SGML, the effective value for that attribute can be defaulted, inherited, and assigned in a context-dependent way. Those mechanisms aren't directly part of HTML because they don't need to be when it's understood that HTML as an SGML application can of course make use of all the authoring mechanism SGML has. But then comes CSS and defines an entirely new syntax that's almost the same (eg. "background: #000"). How is that helpful?
To say it in another way: let's assume we want web pages in 3D space, and yes I know z-index and CSS parallax effect are a thing so bear with me. Following the CSS logic, we should tunnel a background depth/z coordinate via CSS-in-HTML, like
<p style="background-image: url(bla); 3d-props: 'z is -100angstrom, depth-of-field is 123deg'">
where I deliberately have chosen ad-hoc characters for the item/value separator and multiple-properties separator to make the point.
You know, having a common meta syntax for elements/attributes is the entire point of SGML as a text format after all ;)
You don’t like my “lecturing,” but you continue making preposterous statements and asking questions that can’t be answered without “lecturing.” It’s like you’re saying “why is the sky is blue when we have water?” and then correcting yourself with “but I was talking about the stars, dude. ;)”
To answer pragmatically:
- don’t use the style attribute
- you could use XLST, which is style (and more) that uses the same ML
- are you suggesting that CSS and HTML should have the same style? <a style=“color=\”red\””>? I don’t know how that’s better.
Maybe you’re still missing some lecturing: HTML is content and CSS is style. What you’re saying about 3D context would be specified in CSS, in a separate file, so your CSS-in-HTML readability argument (I guess that’s your argument? Who knows) falls pretty flat.
It’s almost the same as complaining that JS doesn’t have the same format as HTML while it totally could, but instead we have JS-in-HTML. Oh how unfair life is.
As far as I can see, you’re just trolling, so thanks for the laughs.
What you’re saying was not clear from the start, you keep moving the goalpost.
Ironically XML allowed namespaces so css:color="red" could have totally been a thing. However CSS came out to separate content from style, so doing that wouldn’t have made much sense. I wouldn’t be surprised if the style attribute was added later.
Edit: wow I was right:
> HTML 3.0 supports style sheets via the use of the LINK element [1]
> HTML 4.0 adds new hooks for style sheets, which suggest how a document is presented. The new ID, CLASS, and STYLE attributes [2]
It keeps style instructions together instead of mingling them with data and behaviour attributes. There's some exceptions with some elements having attributes like width and border but it's mostly historical.
Do you really believe that "style" requires entire new syntax, as opposed to "data" and "behavior", vague as these categories are? In a markup language based on SGML already chock full of syntactical constructs for managing/inheriting item-value pairs? In SGML, attributes are exactly there for things that aren't to be displayed to the user; the idea that attributes are for "behaviour" or whatever is entirely made-up after the fact to justify CSS' existence.
> Do you really believe that "style" requires entire new syntax
Well it depends what you mean by entirely new, the syntax is that of a stylesheet. If we didn't have external stylesheets then maybe it wouldn't make sense to have a style attribute? but we do, so there seems to be some some logic for why we have an attribute that mimics it.
Not really sure if this is a worthwhile conversation to be honest as you seem to want this to be much more antognistic than it needs to be.
Their cookie consent window is one of the most confusing ones I've seen:
"We use cookies for login, checkout and stats. Learn more in our privacy settings."
Followed by two buttons: "No, thanks" and "It's okay".
No thanks... I don't want to learn about your privacy settings? It's okay... store everything?
Cookie warnings have got worse and worse. There are sites now that list 200+ checkboxes with a handy "reject all", but if you don't click through to the list of "legitimate interest" sites you miss out on rejecting 200+ more advertising partners (who somehow have "legitimate interest") with no reject all option.
This is very common, and why I avoid add-on or user-script based solutions that click “reject all” – the authors of those awful dialogues will find yet another way of turning “reject all” into “go right ahead”.
“Legitimate interest” is proof that “your privacy is valuable to us” just means “we are happy to shatter your privacy in exchange for some value”. Every “legitimate interest” box basically says “we see your preference, but fuck you and your preferences”.
While GDPR and related laws (mostly) do the correct thing with respect to privacy, their emergence into the real world has only accelerated this trend.
Really needs a course correct to find a better balance...
My favourite was relational links such as
Opera was the only browser which had a toolbar with these relational links. This was around mid-2000. Unfortunately, this toolbar never survived or got taken over by other browsers.Some relations survived (such as rel="search" for custom search pages), some got killed-by-ecosystem (such as RSS).