Html: Consider modifying the definition of the address element

[stevefaulkner]

An issue was opened on thw w3c HTML spec https://github.com/w3c/html/issues/606 to broaden the definition of the address element, after discussion it was:
https://w3c.github.io/html/grouping-content.html#the-address-element

While this has no effect on implementations it would be better if there was not differences between w3c/whatwg

[zcorpan]

The change is:

• Remove the scoping to article element.
• Allow physical address or digital location or contact information for anything.

The reasoning is something like:

• People use it for contact information for site owner, contact information for article, copyright information, and physical addresses (may or may not be contact information for the site/article).
• No known software exists that uses the semantic of address.
• No software is expected to exist to use the broader semantic of address, either, but may exist for schema.org-annotated things.

Did I understand correctly?

[stevefaulkner]

@zcorpan

Did I understand correctly?

yes

[zcorpan]

OK. I'm not yet convinced it is a good approach to apply that line of reasoning. If we applied the same reasoning for other elements in HTML, I think there would be some interesting effects:

• blockquote does not need to be a quote, it could just be something that needs an indentation.
• em could be used for italics.
• etc.

In short, I do not see how this approach will not lead to codifying usage of HTML for presentational purposes as conforming. Maybe that's OK in some cases? I don't know. I recall @hsivonen arguing that i and em should be synonyms and mean "italics" around 10 years ago, but it hasn't happened yet.

[stevefaulkner]

In short, I do not see how this approach will not lead to codifying usage of HTML for presentational purposes as conforming.

I don't consider it to be codifying for presentational purposes, it is codifying it for a broader meaning of what constitutes an 'address', which reflects usage and what devs conceptualise the meaning to be. Will leave it in the hands of the whatwg to decide.

[zcorpan]

Right, I mean for other elements if we set the precedent here to align allowed usage with actual usage.

[tabatkins]

Difference between this and your blockquote/etc example is that this is aligning with actual semantics in the wild, rather than just removing semantics as your other examples do. Everything with default styling can and will be misused solely for that styling purpose; we're resigned to that.

Here, tho, we have an element where basically nobody uses the element with the defined semantics (or even know wtf the semantics are, because they're weird and old), but instead are giving it a different reasonably consistent and obvious semantics (roughly, address/contact information for the containing thing).

This seems reasonable to me.

[zcorpan]

Last week I started analyzing how address is used in the httparchive data set, looking at the full pages to see it in context. I've checked the first 30 pages so far.

https://gist.github.com/zcorpan/8634f5835583ae59839e2c2e602f986d

Most of them are contact information in the site footer. Some think that phone number/email should not be inside address. 3 have copyright info in address (should we allow that? if not, why not?). Only 1 has a physical location that is not contact information, but for that page the address applies to the ancestor article (all other pages analyzed did not have the address inside an article).

[nickcolley]

Some user context:

We were looking into using the address element for our Help users to
Contact a department or service team pattern, which would have been appropriate with the W3C definition however the WHATWG definition prevents us from making this future friendly.

You can see more here: https://github.com/alphagov/govuk-design-system/issues/1104

[domenic]

Can you expand more on "future friendly"? It seems like having the spec prevent you from using address incorrectly is a good thing.

[nickcolley]

Indeed, right now we've decided not to use address. We're not too sure on how W3C and WHATWG intend to consolidate changes, but thought it was worth sharing what we ran into incase it helps you make a decision.