[whatwg] header for JSON-LD ???

[Mark Kaplun]

Well, in practice, since it is an SEO signal what google does in practice
is more important than any theoretical discussion.

Not being in any way affiliated with google, my own impression is that
google do not care which format you use as long as it can be parsed by them.

The main problem with the metadata that I see as a developer is that it
bloats the HTML, while adding very little value to the human browsing the
web page, this means that pages are being served slower which is probably a
bigger concern on mobile and slower networks.
One thing that google support with JSON-LD is asynchronous loading of it.
Basically the HTML is loaded first, and at some point you can have some JS
that will load the JSON by an AJAX request. google is happy to get the
JSON-LD this way, to the human eye the page loads fater, the only thing not
being solved is that there is still communication bloat even if now it is
divided into two requests instead of one.

I assume that what Micheal was trying to say is that instead of hacks as
described above, it might be a better thing to be able to specify in some
way where the JSON-LD is located (link with relevant rel attribute ?).

just my 2 cents. I currently work in a team that develops a meta data
plugin for wordpress that utilizes JSON-LD. I do not claim to fully
understand the historical reasons why things are like they are right now.


On Wed, Jul 26, 2017 at 4:04 PM, Jonathan Zuckerman <j.zuckerman at gmail.com>
wrote:

> After reading just a bit more - it seems like JSON-LD and schema.org have
> slightly different goals - schema.org suggests conventions for data cues
> in HTML, JSON-LD suggests it for JSON (e.g. API responses for dynamic
> websites) - exactly how "best practice" is this pattern of stuffing JSON-LD
> into the script tag of an HTML document? Most of the articles I could find
> on the subject come from Google, not the JSON-LD community...
>
> On Wed, Jul 26, 2017 at 8:30 AM Mark Kaplun <mark at marksw.com> wrote:
>
>> hmmm http://blog.schema.org/2013/06/schemaorg-and-json-ld.html
>>
>> If you use a CMS like wordpress for your content, and you are just a
>> content person, it is a big meh to try to add manually the attributes, and
>> it is also a meh to develop software that will need to parse the content to
>> add it as you might break the structure required for the proper functioning
>> of CSS and JS. You can have all kinds of "macros" for that, but the result
>> is unreadable content on the editing side.
>>
>> Whatever are the cons of disconnecting the data from the content, it is
>> probably more likely that you will have the data, or at least it will be
>> more complete if you can use json-ld as it is easier to manage.
>>
>> On Wed, Jul 26, 2017 at 3:11 PM, Jonathan Zuckerman <
>> j.zuckerman at gmail.com> wrote:
>>
>>> I agree that reducing the bloat of JSON-LD is a noble goal. Sorry to
>>> belabor this point, but can you explain why JSON-LD is needed in the
>>> first
>>> place? I've tried to point out that HTML is capable of doing it without
>>> another spec, which obviates the need for content duplication and bloat
>>> that JSON-LD introduces (and the extra headers you are suggesting). To
>>> your
>>> other example, CSS media queries can be employed by authors to respect
>>> user
>>> preferences for reduced motion or other visual features. This makes a lot
>>> of sense because it colocates those rules in the place where the
>>> problematic feature would be defined in the first place. Why should a
>>> problem introduced by CSS be fixed by some other technology?
>>>
>>> What I'm saying is that there are alternatives to JSON-LD which are
>>> superior and (this is crucial) already supported globally. I'm confident
>>> that we can expand the scenarios endlessly and still not come across one
>>> where JSON-LD accomplishes something HTML couldn't already do better. Can
>>> you explain why you are such a fan of JSON-LD? I'm open minded, I'm ready
>>> to be convinced, but I feel like I've suggested obviously superior
>>> alternatives to each of the use cases you've presented (if I missed any,
>>> please remind me and I'll be happy to circle back) I was honestly quite
>>> ambivalent about JSON-LD when this discussion started but I'm convinced
>>> now
>>> that it's a bad direction for the web.
>>>
>>> In case you haven't seen it, schema.org suggests an approach to
>>> structured
>>> data that works with HTML instead of sidestepping it. Google provides
>>> a Structured
>>>
>> Data Testing Tool <https://search.google.com/structured-data/testing-tool
>>> >
>>
>>
>>> so you can be sure that the search engine is interpreting the cues
>>> correctly.
>>>
>>> Ok so, I think I've made clear my opinion of JSON-LD ;) taking a big step
>>> back, no action can be taken by the WHATWG about the new header because
>>> those are defined (a quick web search reveals) by the IANA and IETF. The
>>> header you suggest can be implemented at any time by website owners, you
>>> just need to bring this up with the search engines so their bots start
>>> sending the appropriate header. If you can get search engines on board
>>> (or
>>> convince enough site owners to only return JSON-LD when the appropriate
>>> request header is present so the search engines are forced to send it)
>>> then
>>> your job will be done.
>>>
>>>
>>> On Tue, Jul 25, 2017 at 18:41 Michael A. Peters <mpeters at domblogger.net>
>>> wrote:
>>>
>>> > On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
>>> > > On 25 July 2017 at 17:32, Michael A. Peters <mpeters at domblogger.net>
>>> > wrote:
>>> > >
>>> > >> Nor does his assumption that I am "new" to the web somehow
>>> disqualify me
>>> > >> from making suggestions with current use cases that could reduce the
>>> > bloat
>>> > >> of traffic.
>>> > >>
>>> > >
>>> > > Oh, then I think you misunderstood his statement. As I read it,
>>> "spend
>>> > more
>>> > > time working with the web you have before trying to change it" was a
>>> > > suggestion to look for a way to do what you want with current
>>> technology,
>>> > > not an argument that you don't have enough web experience. "Spend
>>> more
>>> > > time" on this particular project, not in general.
>>> > >
>>> >
>>> > I have a way to do what I want with current technology.
>>> >
>>> > I can detect bots based upon user agent and only send the JSON-LD when
>>> I
>>> > do so.
>>> >
>>> > However there are some things that may be of use to a browser with
>>> > accessibility functions, such as declarations regarding whether or not
>>> a
>>> > page (or resource on a page) has flashing content or has simulated
>>> > motion. So there are legitimate reasons why an end user client may want
>>> > the JSON-LD data before rendering a page.
>>> >
>>> > Just like the accept header for WebP, an accept header for JSON-LD
>>> could
>>> > solve this problem. Bots and non-bot users agents that want it send it.
>>> > Webmasters who understand people in undeveloped countries benefit from
>>> > non-bloated paged can then choose to only send the JSON-LD in their
>>> > pages when it is wanted.
>>> >
>>> > Much better to implement this now when JSON-LD is still relatively
>>> young.
>>> >
>>> > Whether JSON-LD is the best way to add structured data to a page
>>> > probably depends upon a lot of different factors, that's a different
>>> > discussion. But it is being used. That's the discussion, reducing the
>>> > drawbacks of bloated content for clients that ignore it anyway.
>>> >
>>>
>>