Open stevefaulkner opened 7 years ago
The change is:
article
element.The reasoning is something like:
address
.address
, either, but may exist for schema.org-annotated things.Did I understand correctly?
@zcorpan
Did I understand correctly?
yes
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.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.
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.
Right, I mean for other elements if we set the precedent here to align allowed usage with actual usage.
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.
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
).
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
Can you expand more on "future friendly"? It seems like having the spec prevent you from using address incorrectly is a good thing.
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.
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