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

[Ian Hickson]

On Tue, Jul 25, 2017 at 2:21 PM Michael A. Peters 
wrote:

> On 07/25/2017 10:45 AM, Jonathan Zuckerman wrote:
> > This suggestion might have more success with the W3C? I'm not completely
> > clear on the politics and history of the two orgs, but it seems like the
> > W3C has supported JSON-LD in the past, so they might have some interest
> in
> > expanding it.
> >
> > On a personal note, I think you've got really far down the path of a
> hammer
> > looking for a nail. Spend more time working with the web you've got
> before
> > trying to change it.
>
> Fuck you. Seriously. I've been working with the web since the late 90s.
>
> I don't need condensing crap like that.
>
> [...]
>
> I'm sorry you are too biased against it to open your mind and see it.
>
> Learn some fucking manners.
>

Disrespect of fellow members of the list is unacceptable.

Michael has been banned from the list for two weeks.

Please peruse our code of conduct if the reasoning behind this action is
unclear to you: https://whatwg.org/code-of-conduct

Thanks.

-- 

-- 
Ian Hickson



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

[Michael A. Peters]

On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:

On 25 July 2017 at 17:32, Michael A. Peters  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.

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

[Jonathan Zuckerman]

Michael, I was truly dismayed to see your reaction to my email. Qebui's
interpretation is close to my intent, but upon re-reading it I agree that
it seems condescending so, right on for calling that out. I want to point
out that I am nobody at the WHATWG - I just lurk on this list and pipe up
when the conversation heads towards topics I enjoy or have experience with
- so please don't think of my personal comments as something that
represents the organization.

I also have been developing since the 90s, I suspect we have a lot in
common. Please email me off the main list if you're interested in
continuing the discussion.

On Tue, Jul 25, 2017 at 5:43 PM Qebui Nehebkau <
qebui.nehebkau+wha...@gmail.com> wrote:

> On 25 July 2017 at 17:32, Michael A. Peters 
> 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.
>

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

[Michael A. Peters]

On 07/25/2017 02:29 PM, Qebui Nehebkau wrote:

Wow, that was unnecessary. "Working with the web since the late 90s"
doesn't intrinsically make you any more right or any better a web designer
than some 12-year-old from Geocities. If maintaining your worldview depends
on assuming that anyone who disagrees is "too biased", your worldview is
wrong. And, btw, your worldview is wrong. Content that only some users want
is separate content that should be in a separate resource.



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.

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

[Qebui Nehebkau]

Wow, that was unnecessary. "Working with the web since the late 90s"
doesn't intrinsically make you any more right or any better a web designer
than some 12-year-old from Geocities. If maintaining your worldview depends
on assuming that anyone who disagrees is "too biased", your worldview is
wrong. And, btw, your worldview is wrong. Content that only some users want
is separate content that should be in a separate resource.

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

[Michael A. Peters]

On 07/25/2017 10:45 AM, Jonathan Zuckerman wrote:

This suggestion might have more success with the W3C? I'm not completely
clear on the politics and history of the two orgs, but it seems like the
W3C has supported JSON-LD in the past, so they might have some interest in
expanding it.

On a personal note, I think you've got really far down the path of a hammer
looking for a nail. Spend more time working with the web you've got before
trying to change it.


Fuck you. Seriously. I've been working with the web since the late 90s.

I don't need condensing crap like that.

No, I don't have a hammer looking for nail.

JSON-LD is a beautiful implementation of structured data, that 
potentially includes the ability to only include it when the client 
wants it included.


I'm sorry you are too biased against it to open your mind and see it.

Learn some fucking manners.

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

[Jonathan Zuckerman]

This suggestion might have more success with the W3C? I'm not completely
clear on the politics and history of the two orgs, but it seems like the
W3C has supported JSON-LD in the past, so they might have some interest in
expanding it.

On a personal note, I think you've got really far down the path of a hammer
looking for a nail. Spend more time working with the web you've got before
trying to change it. I've responded inline with a few suggestions for your
audio website case.

On Mon, Jul 24, 2017 at 7:21 PM Michael A. Peters 
wrote:

> When too much is displayed, the website is too busy.
>
I disagree that displaying related content to the user is "too busy". If
you can't figure out how to organize the content of your website in a way
that users will understand, I don't think it's fair to expect that search
engine bots will be able to do it for you. This is a design problem, or a
UX problem, or a business problem. The technology we currently have is
perfectly capable of resolving your issues.

>
> If there are 12 audios in a group, the person can only listen to one at
> a time so it is pointless to have 12 audio nodes present.
>
Use URLs e.g. example.com/group/7/audio/3 and the history API to build a
decent interface which loads a single audio at a time while also indicating
its role in the group (and includes controls to navigate around the group)

>
> But you can display one and have the other 11 accessible via a select
> menu, so that if and when the user wants them, they select the audio
> they want and JS swaps out the audio node.
>
Hiding the other audios behind a select input seems like a bad experience
for the user, I'm confident you'll find poor discovery of those other
audios by actual users. I'd follow the lead of successful audio
applications like Spotify or Soundcloud until you can do your own research,
but if you insist on keeping the UI very minimal then a single link back to
the "group" or playlist of audios might be worth trying.

>
> But if you define your structured data as attributes then information
> about the other 11 is not available to machines that fetch the page and
> want to know what the page offers.

Not true, if you have a single URL for each audio node and another one for
the group.

>
> That's why JSON-LD is superior to the other methods of structured data.
> You can have the structured data for all 12 audios since all 12 audios
> are part of the page but only one has an (x)html audio node in the html
> as sent by the initial GET request.


> Web pages aren't static, even after the client received the page the DOM
> can be altered without reloading the page.
>
> Structured data separate from the content is the only logical way to
> account for that.
>
Respectfully disagree ;)

>
> On 07/24/2017 08:00 AM, Jonathan Zuckerman wrote:
> > I think one of the best aspects of the web platform is that there can be
> a
> > single node in the network that is accessible to *all*. The linked data
> > approach hides the information from humans. The structured data
> alternative
> > you suggest (div display none) still hides the information from humans.
> > Here's a better alternative that is accessible to both humans and robots:
> > simply *display the div*. What's your objection to displaying this
> > information to humans? How can you justify displaying different content
> to
> > different classes of user?
> >
> > On Sun, Jul 23, 2017 at 8:13 PM Michael A. Peters <
> mpet...@domblogger.net>
> > wrote:
> >
> >> On 07/23/2017 03:33 PM, Michael A. Peters wrote:
> >>> On 07/23/2017 02:42 PM, Qebui Nehebkau wrote:
>  *snip*
> >
> 
>  I can't speak for anyone else - I can barely speak for myself - but I
>  think
>  I'd argue that, intuitively, if your structured data isn't logically
> >> part
>  of your content, there's a good chance that it doesn't belong there at
>  all.
> 
> >>>
> >>> It logically describes the content, and because it is separate from the
> >>> content it describes, is much easier to manage and inspect and bugfix.
> >>>
> >>> Just for example, with an audio, I can describe the creator as a person
> >>> including the company the person works for etc. in JSON-LD without
> >>> needing to have tags in the content for those things to add attributes
> >>> to. That's information that is useful to machines especially when
> >>> linking different objects from domains together but it isn't
> necessarily
> >>> useful to the person reading the web page.
> >>>
> >>> So keeping the structured data separate from the content allows richer
> >>> details to be added to the structured data for machines to read without
> >>> needing to alter the design intended for the human readers of the page.
> >>>
> >>> Two audiences are thus served without needing to compromise the design
> >>> for either, both machine and human.
> >>>
> >>> But the content for machines doesn't need to be sent to humans where
> >>> they don't care about it,