Consider a web page with several thousand <div> elements, each with an opening and closing tag. The HTML file could be considerably smaller if the tag name had a single letter rather than three.
I’d like to propose a new element, <e>, which would be functionally identical to <div> but far better suited as a generic DOM node due to its compactness.
Consider a web page with several thousand
<div>elements, each with an opening and closing tag. The HTML file could be considerably smaller if the tag name had a single letter rather than three.
It turns out that gzip-style string-table compression means there’s really no difference in transmission data.
For browser memory, the DOM is so vast that a two-character difference is insignificant.
For disk storage uncompressed on a server, a single image file would dwarf any savings you could make.
A document with, say, ten thousand div elements, would save four octets (in start and end tags) for each of them, so 40,000 bytes - but a document with only a single paragraph of text per div would be tens of megabytes in size. I have such a document in fact: a 32-volume encyclopedia of biography, and it’s about 50 MBytes in XML; i use XSLT to make a static Web site with one file, one Web resource, for each of the approx. 10,000 entries, however [1]. You shouldn’t normally be serving up HTML files with 10,000 div elements in them.
This would be optimizing for an inappropriate use case.
I’d like to propose a new element,
<e>, which would be functionally identical to<div>but far better suited as a generic DOM node due to its compactness.
Well, dotless i (ı) has fewer pixels, isn’t that even better 
Less flippantly, it’d be a far bigger win to use server-side parsing and parse-event streams [2], and existing Web pages could then benefit simply by updating Web servers.
[1] https://words.fromoldbooks.org/Chalmers-Biography/ [2] https://www.w3.org/TR/2014/REC-exi-20140211/ (don’t be fooled by the “XML” in the name of this compression technique; server-side parsing works for pretty much anything)
Liam
There are certainly benefits to brevity. Otherwise, we’d have a <division> element rather than a <div>. Even if these benefits amount only to fewer keystrokes, shorter line-lengths, and marginally smaller files on disk, I thought it was worth a discussion. A byte saved is a byte saved. There is a reason why we minify our files.
I do think that introducing a brand new element is quite a major change for such a minor optimization. However, if we were starting all over again, would we really prefer a three-character non-semantic name over a one-character non-semantic name?
The HTML spec does some things like this because the single page edition is really really giant and browsers expand the zip before parsing, it can matter, I guess.
That said, what they use are custom elements like where f is a Boolean attribute and these are for marking up code formatting examples which quickly pile up a huge amount to parse, store and even then read if you’re looking at DOM, I guess. Anyways, I’d suggest like this: convince people to do one, we’ll see it in the http archive reports and can reevaluate… It already means approximately span.
In HTML email, files size is generally limited to 100kb (larger files will be clipped by Gmail and likely to raise spam scores across a number of client). So for email devs every character really counts. Although I realise that is niche and may not be so much of a priority for web.
I’d say that’s pretty niche. And most likely, you won’t be saving even 0.1% of that by changing your <div>s to <e>s, even pre-compression.