Re: [whatwg] header for JSON-LD ???

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@domblogger.net>
wrote:

> On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
> > On 25 July 2017 at 17:32, Michael A. Peters <mpeters@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.
>

Received on Wednesday, 26 July 2017 12:12:16 UTC