search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
7.98k stars 2.6k forks source link

Consider modifying the definition of the address element #2107

Open stevefaulkner opened 7 years ago

stevefaulkner commented 7 years ago

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 commented 7 years ago

The change is:

The reasoning is something like:

Did I understand correctly?

stevefaulkner commented 7 years ago

@zcorpan

Did I understand correctly?

yes

zcorpan commented 7 years ago

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:

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 commented 7 years ago

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 commented 7 years ago

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

tabatkins commented 7 years ago

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 commented 7 years ago

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 commented 4 years ago

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 commented 4 years ago

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

NickColley commented 4 years ago

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.