Open GoodbyeNJN opened 9 months ago
Thanks, though honestly, I feel like this is too complicated. I think the less surprising (for users) and easier to maintain (for devs) path is keeping things very simple and flat, with no complicated heuristics and no overriding behavior by default. And for overridability, introduce an opt-in key
prop. This, basically: https://github.com/solidjs/solid-meta/pull/39
- renders only last meta with same property
<Meta name="property1" property="property1" content="content1" /> <Meta name="property2" property="property2" content="content2" /> <Meta name="property3" property="property3" content="content3" /> <Meta property="property1" content="content1" /> <Meta property="property2" content="content2" /> <Meta property="property3" content="content3" />
This is not (always) correct. Open Graph declares arrays using multiple <meta>
s with same property
:
Arrays
If a tag can have multiple values, just put multiple versions of the same tag on your page. The first tag (from top to bottom) is given preference during conflicts.
<meta property="og:image" content="https://example.com/rock.jpg" /> <meta property="og:image" content="https://example.com/rock2.jpg" />
@yume-chan Yes, you are right, I forgot to consider the Open Graph case.
Now that Open Graph has a certain format for <meta property="og:xxx" content="xxx"/>
, perhaps we could consider checking if the property
starts with og:
and applying additional rules to it.
What do you think? Your ideas are welcome.
By the way, it looks like this project is no longer active and I'm not quite sure when this proposal will be adopted by the maintainers...
checking if the property starts with og: and applying additional rules to it.
Maybe Open Graph is too complex that it worths its own package.
Open Graph arrays make it impossible for the heuristics to decide whether multiple <meta property="og:image">
tags should co-exist or override each other. I think it's reasonable to support the scenario that a default image is provided in the root component, then overridden by multiple images in each route.
Some user input, like #39, might be required. Then the dedicated Open Graph package can choose to override <OpenGraphTitle>
and <OpenGraphDescription>
by default, and let the user to choose what to do with <OpenGraphImage>
s. (maybe with a <OpenGraphImages>
component that accepts one or more <OpenGraphImage>
s, only <OpenGraphImages>
will override each other).
By the way, it looks like this project is no longer active
I hope it's not 😞. However npm overrides is always an option.
Open Graph arrays make it impossible for the heuristics to decide whether multiple
<meta property="og:image">
tags should co-exist or override each other. I think it's reasonable to support the scenario that a default image is provided in the root component, then overridden by multiple images in each route.
I agree with this. There is really no need to re-implement the parsing logic of Open Graph tags in this project.
As I said in this issue, I've rearranged the attributes that may appear on the
meta
element, as well as new test cases for themeta
element.In the following, I have bolded some of the content to be discussed.
Please review it when you are free. @DaniGuardiola is also welcome to review it together. Any suggestions are very welcome.
Attributes (spec)
name
: Metadata namehttp-equiv
: Pragma directivecontent
: Value of the elementcharset
: Character encoding declarationmedia
: Applicable mediaitemprop
: Microdata, may appear on any HTML elementAdditional attributes (spec)
property
: Extended attribute by RDFa, commonly used in the Open Graph protocolRules
name
,http-equiv
,charset
, anditemprop
attributes must be specified.name
,http-equiv
, oritemprop
is specified, then thecontent
attribute must also be specified. Otherwise, it must be omitted.charset
attribute is present, its value must be an ASCII case-insensitive match for the string"utf-8"
.meta
element with acharset
attribute per document.media
attribute says which media the metadata applies to.Additional rules
property
is specified, then thecontent
attribute must also be specified. (not for sure, but it seems to be true)name
is not specified butproperty
is specified, then theproperty
attribute should be treated asname
attribute. (Do users need to be warned about this compatibility process?)name
andproperty
are specified, then theproperty
attribute should be the same asname
attribute. (Does this rule should be added to simplify processing?)Test cases