6 ms·

Having used all of these in the past, here's why this is the case: 1. meter/progress - default style looks dated, styling works different on different browsers

by franga2000 4y ago

Having used all of these in the past, here's why this is the case: 1. meter/progress - default style looks dated, styling works different on different browsers, the color scale options are confusing 2. sup/sub & 7. abbr - these are only useful for page content (as opposed to site design), which is usually WYSIWYG or something like Markdown. Many editors/parsers don't support it, at least by default. 4. map/area - it's absolute positioning, which is unusable for the variety of devices we use today 5. detail/summary - it's also more content than design and has basically no support in content editors, but it has been growing in popularity in things like GitHub READMEs where only basic markup is allowed. 6. object - hard to know what filetypes will be supported and little feedback when they aren't. It usually safer to either include a JS reader with your site or just download the file.

sebazzz 4y ago
The problem with detail/summary is that in some browsers that element is hard to style correctly and always turns out to be so limited that you ask yourself why you don’t fully develop this functionality manually and put some aria attributes on it for good WCAG2.1 measure. Also applies to progress, for which you need to use obscure browser-specific CSS rules.
statico 4y ago
For some reason <object> makes me anxious. Is there some memory of the Flash/ActionScript days, or maybe ActiveX or something, that causes me to frown at seeing a mention of <object>?
- derefr 4y ago
  <object> is supposed to be for exposing modules from hosted runtimes into the host execution-context as, well, objects (in the OOP sense. Or the COM sense, I suppose.) The original use-case would have been something like: imagine you code a game physics engine in Java, and deploy it as a Java applet. You can embed that physics engine into a page as an <object> — and then consume it as a local API using JavaScript embedded on the same page. (And yes, this is almost certainly the real reason JavaScript is called "JavaScript." When it was created, it was precisely positioned as a glue language for consuming/driving Java-applet APIs!) Java-applet-based APIs (and their Windows-proprietary ActiveX cousins) are dead, so there's no real reason to care about <object> any more. As long as the browser knows how to render the media if you navigate directly to its URL, you can just use an <iframe>.
  - statico 4y ago
    Ah ha! It was Java applets that makes me dread seeing <object>/<embed> tags again. Gotta support IE, you know. Netscape will crash anyway.
- cantSpellSober 4y ago
  Probably, <object> to me will always be "the thing SWFObject used for rendering a Flash container"
- perilunar 4y ago
  <object> was often used for video and audio players as well as Flash, Shockwave, VRML and other plugins. It's not needed anymore for audio or video — they have their own tags now — and plugins are dead.
commandlinefan 4y ago
That was my first thought... if people don't use these very old elements any more, there's probably a good Chesterson's fence-type reason. Frames seemed really cool when I first saw them too, until I actually started trying to support them.
- dylan604 4y ago
  Frames died when AJAX became available. People were bastardizing frames so that they could change the content in a window without refershing the entire window.
  - dspillett 4y ago
    That was largely iframes, though they are still in use for some things like certain methods of ad delivery. frames/framesets were often about partial updates, but mostly where script wasn't wanted so AJAX (once available) wasn't an option either.
    - WorldMaker 4y ago
      Having lived through that era, Frames (and Framesets) were mostly killed by the proliferation of PHP on cheap hosts. A lot of Frames were used for building navigation elements without a lot of copy/pasting between HTML files (headers, footers, navigation bars, etc). The alternative to frames was either copy/pasting or ancient early static site generators. When PHP became common and cheap most people moved to server-side inclusions. These days we've come full circle back around to static sites but not returned to frames simply by how much static site generators have either become more common and/or easier/better to use.
      - dylan604 4y ago
        >but not returned to frames also, CSS Flex
      - iostream25 4y ago
        Frames made a side or top nav clearly separated from the content in the middle. Framesets were super useful, in that regard, in the era of dialup.
cantSpellSober 4y ago
Until it's easier to add bloated animations to details/summary the designers will never let us use em
clairity 4y ago
to keep track of all of these in my personal css framework, i made an entry in the base stylesheet for every html element, even including a couple deprecated but widely supported ones (i also keep a list of fully deprecated elements in comments), though not every element gets styled beyond the default. meter/progress can be styled consistently, but it's tricky because of the browser inconsistencies you mention. it took a lot of playing around with weird vendor-prefixed pseudos to get these looking similar across platforms. sub/sub/abbr just need to be normalized first - normalize.css is a good reference for this. abbr can be useful for providing short "aside" info on a word/phrase in a semantic way. styling detail/summary is relatively easy and they're pretty useful for FAQs and the like. i see web designers experimenting with more and more these days. map/area, i don't use, but have seen it used on experimental designs to neat effect. and object is as you said, hard to predict for styling. ps - it looks like chrome (105) will finally support mathML along with firefox and safari, so perhaps that will impact sub/sup usage in the future.
Gormo 4y ago
> default style looks dated Browser defaults for all HTML elements look "dated". The visual appearance of meter, as with all elements, is adjusted via CSS. > . map/area - it's absolute positioning, which is unusable for the variety of devices we use today It's relative to the image dimensions, not the page/viewport.
bawolff 4y ago
> object - hard to know what filetypes will be supported and little feedback when they aren't. Easier now that plugins are dead and <object> is basically equivalent to <iframe>

sebazzz 4y ago

The problem with detail/summary is that in some browsers that element is hard to style correctly and always turns out to be so limited that you ask yourself why you don’t fully develop this functionality manually and put some aria attributes on it for good WCAG2.1 measure. Also applies to progress, for which you need to use obscure browser-specific CSS rules.

statico 4y ago

For some reason <object> makes me anxious. Is there some memory of the Flash/ActionScript days, or maybe ActiveX or something, that causes me to frown at seeing a mention of <object>?

derefr 4y ago
<object> is supposed to be for exposing modules from hosted runtimes into the host execution-context as, well, objects (in the OOP sense. Or the COM sense, I suppose.) The original use-case would have been something like: imagine you code a game physics engine in Java, and deploy it as a Java applet. You can embed that physics engine into a page as an <object> — and then consume it as a local API using JavaScript embedded on the same page. (And yes, this is almost certainly the real reason JavaScript is called "JavaScript." When it was created, it was precisely positioned as a glue language for consuming/driving Java-applet APIs!) Java-applet-based APIs (and their Windows-proprietary ActiveX cousins) are dead, so there's no real reason to care about <object> any more. As long as the browser knows how to render the media if you navigate directly to its URL, you can just use an <iframe>.
- statico 4y ago
  Ah ha! It was Java applets that makes me dread seeing <object>/<embed> tags again. Gotta support IE, you know. Netscape will crash anyway.
cantSpellSober 4y ago
Probably, <object> to me will always be "the thing SWFObject used for rendering a Flash container"
perilunar 4y ago
<object> was often used for video and audio players as well as Flash, Shockwave, VRML and other plugins. It's not needed anymore for audio or video — they have their own tags now — and plugins are dead.

commandlinefan 4y ago

That was my first thought... if people don't use these very old elements any more, there's probably a good Chesterson's fence-type reason. Frames seemed really cool when I first saw them too, until I actually started trying to support them.

dylan604 4y ago
Frames died when AJAX became available. People were bastardizing frames so that they could change the content in a window without refershing the entire window.
- dspillett 4y ago
  That was largely iframes, though they are still in use for some things like certain methods of ad delivery. frames/framesets were often about partial updates, but mostly where script wasn't wanted so AJAX (once available) wasn't an option either.
  - WorldMaker 4y ago
    Having lived through that era, Frames (and Framesets) were mostly killed by the proliferation of PHP on cheap hosts. A lot of Frames were used for building navigation elements without a lot of copy/pasting between HTML files (headers, footers, navigation bars, etc). The alternative to frames was either copy/pasting or ancient early static site generators. When PHP became common and cheap most people moved to server-side inclusions. These days we've come full circle back around to static sites but not returned to frames simply by how much static site generators have either become more common and/or easier/better to use.
    - dylan604 4y ago
      >but not returned to frames also, CSS Flex
    - iostream25 4y ago
      Frames made a side or top nav clearly separated from the content in the middle. Framesets were super useful, in that regard, in the era of dialup.

cantSpellSober 4y ago

Until it's easier to add bloated animations to details/summary the designers will never let us use em

clairity 4y ago

to keep track of all of these in my personal css framework, i made an entry in the base stylesheet for every html element, even including a couple deprecated but widely supported ones (i also keep a list of fully deprecated elements in comments), though not every element gets styled beyond the default. meter/progress can be styled consistently, but it's tricky because of the browser inconsistencies you mention. it took a lot of playing around with weird vendor-prefixed pseudos to get these looking similar across platforms. sub/sub/abbr just need to be normalized first - normalize.css is a good reference for this. abbr can be useful for providing short "aside" info on a word/phrase in a semantic way. styling detail/summary is relatively easy and they're pretty useful for FAQs and the like. i see web designers experimenting with more and more these days. map/area, i don't use, but have seen it used on experimental designs to neat effect. and object is as you said, hard to predict for styling. ps - it looks like chrome (105) will finally support mathML along with firefox and safari, so perhaps that will impact sub/sup usage in the future.

Gormo 4y ago

> default style looks dated Browser defaults for all HTML elements look "dated". The visual appearance of meter, as with all elements, is adjusted via CSS. > . map/area - it's absolute positioning, which is unusable for the variety of devices we use today It's relative to the image dimensions, not the page/viewport.

bawolff 4y ago

> object - hard to know what filetypes will be supported and little feedback when they aren't. Easier now that plugins are dead and <object> is basically equivalent to <iframe>