[HN Gopher] Those HTML attributes you never use
___________________________________________________________________
Those HTML attributes you never use
Author : makaimc
Score : 427 points
Date : 2022-04-02 11:38 UTC (2 days ago)
(HTM) web link (www.smashingmagazine.com)
(TXT) w3m dump (www.smashingmagazine.com)
| andrewingram wrote:
| 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.
| jer0me wrote:
| 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.
| NKosmatos wrote:
| <blink>Came here for deprecated attributes, but found an
| informative article.</blink>
| ravenstine wrote:
| <marquee>Never forget the fun of the early web!</marquee>
|
| Yeah, I had the same cynical assumption before reading.
|
| All in all, I can't remember coming across a deprecated HTML
| feature that I needed and didn't already have a better
| alternative.
| 0des wrote:
| Pouring one out for server side includes and my homie cgi-bin
| as we speak
| matt_kantor wrote:
| 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.
| extra88 wrote:
| I still have some web pages I update on a shared host that
| use server side includes to display the HTML file's last
| modified date.
| extra88 wrote:
| <blink> and <marquee> are HTML _elements_ , the article is
| about HTML _attributes_.
|
| None of the attributes in the article are deprecated, some
| are underimplemented (alternative stylesheets).
| mxuribe wrote:
| 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. :-)
| extra88 wrote:
| 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:
| blink { animation: 2s linear infinite
| condemned_blink_effect; } blink[data-
| speed: fast] { animation-duration: 1s } blink[data-
| speed: slow] { animation-duration: 4s }
| bryanrasmussen wrote:
| The xmp element worked better for its purpose than any of the
| replacing elements, in my experience, http://www.the-
| pope.com/listin.html
| chrisfinazzo wrote:
| 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...)
| extra88 wrote:
| `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.
| nkozyra wrote:
| 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.
|
| I did at least find some blink discussion on it:
| https://groups.google.com/a/chromium.org/g/blink-dev/c/Hfe5x...
| hackyhacky wrote:
| Although your complaint about unsupported features is generally
| well-observed, in the case of this particular you feature, I
| believe you're wrong.
|
| This site suggests that enterkeyhint is supported on Chrome:
| https://caniuse.com/mdn-html_global_attributes_enterkeyhint
|
| My own testing also shows that it works. Using the "search"
| value of the attribute, I was able to change the enter button
| into a magnifying glass.
| nkozyra wrote:
| Wonder why their codepen example does nothing for me then?
| Latest chrome, pixel 6.
| easrng wrote:
| 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.
| nkozyra wrote:
| Stock Android keyboard. Doesn't work if I dismiss either,
| as sibling comment states.
| easrng wrote:
| Ok, it works for me but only if I dismiss the keyboard in
| between fields.
|
| https://owo.whats-th.is/D4Vf7g6.mp4
| amelius wrote:
| Why aren't all attributes CSS properties?
| tannhaeuser wrote:
| More like, why aren't all CSS properties attributes.
| TAKEMYMONEY wrote:
| ...and that's how Tailwind was born
| amelius wrote:
| Because you can't cascade attributes, whereas you can cascade
| CSS properties.
| detaro wrote:
| Because attributes are not for styling.
| ravenstine wrote:
| 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.
| tannhaeuser wrote:
| Don't know if you're kidding ;) but how's <p style="margin-
| top: 2em;"> any better than <p margin-top="2em">?
| ravenstine wrote:
| 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.
| salmo wrote:
| 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.
|
| But I've never hear of a roff or LaTeX UI, so...
| mushyhammer wrote:
| 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.
| <meta name="description" content="Cool stuff">
|
| and .css::before { content:
| url(image.bmp) }
| tannhaeuser wrote:
| 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 ;)
| mushyhammer wrote:
| 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.
|
| Signed, <a
| onclick="this.style.background='url(<svg
| title=\"🖕\"><rect fill=\"blue\"/></svg>)'">
| have_faith wrote:
| 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.
| tannhaeuser wrote:
| 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.
| have_faith wrote:
| > 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.
|
| Good luck in your quest.
| dgb23 wrote:
| 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.
| bennyp101 wrote:
| Yep, super handy for having fields in a form in table.
|
| Each row can be its own form and you still end up with valid
| html.
| andrewingram wrote:
| 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.
| extra88 wrote:
| 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.
| andrewingram wrote:
| That's useful stuff, thanks!
| efortis wrote:
| My favorite: <abbr title="Abbreviation">abbr</abbr>
| hombre_fatal wrote:
| 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.
| acatton wrote:
| > The `download` Attribute For The <a> Element
|
| This can also be done by the webserver with Content-Disposition.
| [1]
|
| But it's cool, I didn't know this could be done with HTML, it
| offers a lot of possibilities.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Co...
| strogonoff wrote:
| 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.
| jdmichal wrote:
| 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.
| chrisfinazzo wrote:
| Huh. Whenever I've used it, things have all been on the same
| domain so this doesn't come up - good to know.
| strogonoff wrote:
| 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.)
| chrisfinazzo wrote:
| 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.
|
| Something to watch out for.
| dspillett wrote:
| _> 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.
| strogonoff wrote:
| Yes, it's probably the same behavior: https://html.spec.wha
| twg.org/multipage/links.html#downloadin.... Step 7 is
| mostly where any improvements would go, I imagine.
|
| 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.
| alduin32 wrote:
| 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.
| smoe wrote:
| 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.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#...
| chrisfinazzo wrote:
| I actually hadn't heard of CD before. Looking at it, using an
| attribute seems more straightforward and simple.
|
| Maybe just me.
| jdmichal wrote:
| `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.
| coryk135 wrote:
| This is a very useful attribute if you generate base64 encoded
| images and need to create download links that give the files
| unique names.
| sebazzz wrote:
| > The title Attribute On Stylesheets
|
| w3.org used to feature this, you could view the website in any of
| the stylesheets they offered, which were a bunch (about 5-10 if I
| recall correctly).
| chrisfinazzo wrote:
| <cite> is a bit of a surprise to me. The Standard Ebooks[1]
| project uses almost religiously it when styling blockquotes.
|
| [1]: https://standardebooks.org/manual/1.6.3/single-page#5.8
|
| 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 :)
| extra88 wrote:
| 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.
| chrisfinazzo wrote:
| 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.
| extra88 wrote:
| <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.
| acabal wrote:
| 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>.)
| extra88 wrote:
| 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."
|
| [0] https://en.wikipedia.org/wiki/HTML5#W3C_and_WHATWG_co
| nflict
| WorldMaker wrote:
| > 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.
| extra88 wrote:
| Yes, you could do something like this: <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.
| WorldMaker wrote:
| 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.
| extra88 wrote:
| 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.
|
| [0] https://html.spec.whatwg.org/multipage/indices.html#a
| ttribut...
| easrng wrote:
| blockquote::after, q::after { content: " - "
| attr(cite); display: block; font-style:
| italic; }
|
| Should do the trick nicely.
| thomasfl wrote:
| 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.
| hk__2 wrote:
| Note that instead of using an input type=text and
| enterkeyhint=search, you can use input type=search.
| fleddr wrote:
| 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.
| hk__2 wrote:
| 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.
| nkozyra wrote:
| Sure, but this tip is explicitly to change the text (or icon,
| depending) of the onscreen virtual keyboard, so these are
| different functionalities.
| lloydatkinson wrote:
| The search input sucks on iOS - it randomly has square corners
| or round corners depending on arbitrary information.
| cxr wrote:
| enterkeyhint is embarrassingly concrete. Should've accomplished
| this by specifying semantics for the alt and rel attributes.
| TAKEMYMONEY wrote:
| My first thought as well, should we expect `prntscrnkeyhint`
| soon?
| [deleted]
| charcircuit wrote:
| Page Style is useless because there is no persistence. Even
| navigating to another page on that same website will reset it
| back to default.
| hiccuphippo wrote:
| 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?
| xnorswap wrote:
| 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.
| dspillett wrote:
| 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".
| chrisfinazzo wrote:
| 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...
| marcosdumay wrote:
| It's only a matter of enforcing the GDPR.
| leephillips wrote:
| I don't see most of these cookie warnings as I use this
| bookmarklet: https://lee-phillips.org/nomorecookiewarnings/
|
| It's not perfect, but it helps.
| hoosieree wrote:
| This could be a browser extension, such as a toggle button to
| "never store cookies for this site".
| jimmaswell wrote:
| I'd personally rather support the sites I use and always
| accept cookies.
| dotancohen wrote:
| Not storing cookies is already a feature of every major web
| browser, at least the desktop ones.
| agumonkey wrote:
| 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
| tenebrisalietum wrote:
| 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.
| agumonkey wrote:
| > 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.."
| aendruk wrote:
| At one point you could get a whole keyboard like that:
|
| https://en.wikipedia.org/wiki/Optimus_Maximus_keyboard
|
| Apple has a patent on the concept; maybe there's still one in
| our future:
|
| https://patents.google.com/patent/US20080001787A1
| agumonkey wrote:
| Maybe today it's cheap enough to have a fully redrawable key.
| Maybe it's still over-engineering for this purpose.
| KeytarHero wrote:
| 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.
| SSLy wrote:
| >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)
| agumonkey wrote:
| but I assume material and software cost of these are too high
| for the people i was describing.
| Melatonic wrote:
| Would be nice to be able to rely on HTML attributes for filtering
| but sadly they are just too easy to spoof
| ravenstine wrote:
| 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
| johannes1234321 wrote:
| 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.
| 9dev wrote:
| 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...
| johannes1234321 wrote:
| Yeah, aside from <optgroup> there hasn't been much
| improvement in that area (well maybe fieldset and related)
| in that space.
| inopinatus wrote:
| 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 AEleen 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.
| TAKEMYMONEY wrote:
| 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.
| ok123456 wrote:
| 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.
| clairity wrote:
| 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.
|
| not sure about <dfn> without a title though.
| vikingerik wrote:
| 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.
| [deleted]
| mdavidn wrote:
| I used the download attribute recently to force downloads for
| attachments from another service, one whose Content-Disposition
| headers are outside my control.
| efortis wrote:
| 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.
| jw1224 wrote:
| 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.
| ktpsns wrote:
| 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).
| gjvnq wrote:
| 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.
| gmfawcett wrote:
| 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.
| ars wrote:
| > Opera was the only browser which had a toolbar with these
| relational links.
|
| Frefox had it to, it's this famous bugzilla:
| https://bugzilla.mozilla.org/show_bug.cgi?id=2800 opened 24
| years ago.
|
| 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.
| WorldMaker wrote:
| 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.
| ademarre wrote:
| Google search used to use rel=prev/next to identify paginated
| sequences for indexing, but not anymore.
| https://twitter.com/JohnMu/status/1108717486424363009
|
| As of 2019, Bing was looking at those links for URL discovery.
| https://twitter.com/CoperniX/status/1108790528773021696
| edeion wrote:
| 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.
| dheera wrote:
| Why do we have shit like `enterkeyhint` but not some really
| simple things like <input type="slider"
| min="0" max="100" step="10" name="foo"> <input
| type="toggle" value="true" name="bar">
| detaro wrote:
| We have the first, it's just not called "slider".
| throwanem wrote:
| It's called "range", and I didn't know about it either:
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/in...
|
| And a "toggle" input is just a checkbox.
| mahathu wrote:
| you mean range and checkbox inputs? (they both exist)
| dfox wrote:
| Mozilla Suite also had toolbar for this kind of links. And
| early versions of Firefox either had it too or there was
| extension for it.
| oneeyedpigeon wrote:
| 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.
| clairity wrote:
| 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.
| novocantico wrote:
| 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?)
| toastal wrote:
| 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.
| giancarlostoro wrote:
| 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.
| iggldiggl wrote:
| 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.
| toastal wrote:
| This works pretty nicely if they only refer to which CSS
| variables to load and the _main_ CSS file is waiting to be
| overridden by these variables.
|
| I just wish it got a higher priority by browsers to have
| good built-ins.
| clairity wrote:
| 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).
| nl wrote:
| 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.
| cxr wrote:
| 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.
| HenryMulligan wrote:
| 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!
| cxr wrote:
| Prepare to be disappointed. There are probably fewer pages
| using this now than there were 15-20 years ago, despite the
| rise of "Dark Mode".
|
| (The menu item was actually mentioned in the article linked
| here.)
| nl wrote:
| Glad I'm not misremembering!
|
| I found some posts from from 2004 which does refer to the
| icon:
|
| https://fantasai.inkedblade.net/weblog/2004/firefox-altss/
|
| https://web.archive.org/web/20041103090311/http://weblogs.mo.
| ..
|
| I wish I could find some screenshots!
| zhte415 wrote:
| The article didn't use the blockquote cite attribute in the
| blockquote that explains why it's not used much.
|
| This is perhaps internally consistent.
| martin_a wrote:
| > The decoding Attribute For The <img> Element
|
| This is an interesting one, although I find native lazy-loading
| with the "loading"-attribute more interesting:
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
| extra88 wrote:
| 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.
| cfj wrote:
| 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.
|
| [0]: https://news.ycombinator.com/item?id=5594791
| bugmen0t wrote:
| Nit: `integrity` also works for stylesheets, not just scripts
| watersb wrote:
| Does anyone remember JavaScript Style Sheets?
| easrng wrote:
| 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.
| mxuribe wrote:
| That sounds vaguely familiar...then again, there are many
| things from the late 90s/early 2000s web development that i
| wish to forget. ;-)
___________________________________________________________________
(page generated 2022-04-04 23:01 UTC)