Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

[Michael A. Peters]

On 12/11/2017 04:30 AM, Jirka Kosek wrote:

On 11.12.2017 11:39, Christoph Päper wrote:

As with  and , HTML could also add  or something similar to 
embed MusicXML. Lyrics are a subset of musical notation and poems are, arguably, a special kind 
of lyrics (or the other way around).


This would require change to HTML parsing rules which ideally shoudn't
ever happen again.

Easier approach is to use XHTML syntax and simply embedded fragment of
specific XML vocabulary. It's pity that extensibility has been largely
thrown away when HTML5 was designed.


I always serve my pages as application/xhtml+xml except when an honest 
bot asks for the page (Twitter, some accessibility testers, Google Page 
Speed, all have trouble with real XML - often either screwing up with 
the self-closing script tags or parsing it correctly as XML but adding 
junk after the closing tag somewhere in their processing)


I've not tried as I don't think browsers would know what to do, but one 
should be able to add other XML namespaces to html5 served as proper 
XML, no?


That's how we had to to MathML circa 2000 before HTML5 (and then if I 
recall only Mozilla knew what to do with the MathML) - the same thing 
should work if browsers knew what to do with MusicXML or whatever.

Re: [whatwg] new tag and possible new aria role

[Michael A. Peters]

Was just informed that using aria-hidden solves the problem of content 
being there that shouldn't be seen in a screen reader until agreed, so 
that issue has a solution too.


I guess none of this really is meaningful to this list - sorry for the 
noise.


On 11/12/2017 04:18 AM, Michael A. Peters wrote:

Yes but since I always have the div first in HTML the user is likely to
always be aware of it, so skipping it in a screen reader is really
little different than just pressing the agree button - they have been
informed of the type of content.

On 11/12/2017 04:09 AM, Johannes Spangenberg wrote:

There is another problem with Modals on webpages. When there is a modal
created through HTML and CSS, the user can still select items in the
background by pressing tab. It seems that there is no good solution to
prevent it.


Am 12.11.2017 um 09:59 schrieb Michael A. Peters:

Thank you! That does seem like it is exactly what I need.

On 11/12/2017 12:11 AM, Yay295 wrote:

I think the alertdialog role fits here.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role



On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters

wrote:


On webites that either are age restricted and/or have content that
may be
offensive to some people, often (but not as often as I'd like) there
is a
warning splashscreen that the server puts in the page if the user
has not
already agreed to see such content.

One way to do this is with a div that has absolute positioning and a
z-index that covers the content until the user clicks enter or
whatever,
then it does an ajax call to lett the server the user has verified
they
want to see the content and removes the div.

I would suggest a tagName "splashscreen" for this purpose. It would
have
the same properties as a div only it would have semantic meaning so
that
people using screen readers would know it is important.

An aria landmark of splashscreen would also properly distinguish it
from
complementary which is what I currently use for it (I would use
banner but
only one banner landmark per page is allowed).

Just a thought, I won't defend the thought but if it seems
reasonable to
the powers that be, I think it is worth it.

These splash screens do serve a different purpose than any other
semantic
tag.

Re: [whatwg] new tag and possible new aria role

[Michael A. Peters]

Yes but since I always have the div first in HTML the user is likely to 
always be aware of it, so skipping it in a screen reader is really 
little different than just pressing the agree button - they have been 
informed of the type of content.


On 11/12/2017 04:09 AM, Johannes Spangenberg wrote:

There is another problem with Modals on webpages. When there is a modal
created through HTML and CSS, the user can still select items in the
background by pressing tab. It seems that there is no good solution to
prevent it.


Am 12.11.2017 um 09:59 schrieb Michael A. Peters:

Thank you! That does seem like it is exactly what I need.

On 11/12/2017 12:11 AM, Yay295 wrote:

I think the alertdialog role fits here.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role


On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters

wrote:


On webites that either are age restricted and/or have content that
may be
offensive to some people, often (but not as often as I'd like) there
is a
warning splashscreen that the server puts in the page if the user
has not
already agreed to see such content.

One way to do this is with a div that has absolute positioning and a
z-index that covers the content until the user clicks enter or
whatever,
then it does an ajax call to lett the server the user has verified they
want to see the content and removes the div.

I would suggest a tagName "splashscreen" for this purpose. It would
have
the same properties as a div only it would have semantic meaning so
that
people using screen readers would know it is important.

An aria landmark of splashscreen would also properly distinguish it
from
complementary which is what I currently use for it (I would use
banner but
only one banner landmark per page is allowed).

Just a thought, I won't defend the thought but if it seems
reasonable to
the powers that be, I think it is worth it.

These splash screens do serve a different purpose than any other
semantic
tag.

Re: [whatwg] new tag and possible new aria role

[Michael A. Peters]

Thank you! That does seem like it is exactly what I need.

On 11/12/2017 12:11 AM, Yay295 wrote:

I think the alertdialog role fits here.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role

On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters 
wrote:


On webites that either are age restricted and/or have content that may be
offensive to some people, often (but not as often as I'd like) there is a
warning splashscreen that the server puts in the page if the user has not
already agreed to see such content.

One way to do this is with a div that has absolute positioning and a
z-index that covers the content until the user clicks enter or whatever,
then it does an ajax call to lett the server the user has verified they
want to see the content and removes the div.

I would suggest a tagName "splashscreen" for this purpose. It would have
the same properties as a div only it would have semantic meaning so that
people using screen readers would know it is important.

An aria landmark of splashscreen would also properly distinguish it from
complementary which is what I currently use for it (I would use banner but
only one banner landmark per page is allowed).

Just a thought, I won't defend the thought but if it seems reasonable to
the powers that be, I think it is worth it.

These splash screens do serve a different purpose than any other semantic
tag.

[whatwg] new tag and possible new aria role

[Michael A. Peters]

On webites that either are age restricted and/or have content that may 
be offensive to some people, often (but not as often as I'd like) there 
is a warning splashscreen that the server puts in the page if the user 
has not already agreed to see such content.


One way to do this is with a div that has absolute positioning and a 
z-index that covers the content until the user clicks enter or whatever, 
then it does an ajax call to lett the server the user has verified they 
want to see the content and removes the div.


I would suggest a tagName "splashscreen" for this purpose. It would have 
the same properties as a div only it would have semantic meaning so that 
people using screen readers would know it is important.


An aria landmark of splashscreen would also properly distinguish it from 
complementary which is what I currently use for it (I would use banner 
but only one banner landmark per page is allowed).


Just a thought, I won't defend the thought but if it seems reasonable to 
the powers that be, I think it is worth it.


These splash screens do serve a different purpose than any other 
semantic tag.

Re: [whatwg] JavaScript function for closing tags

[Michael A. Peters]

On 10/16/2017 10:08 AM, Roger Hågensen wrote:

On 2017-10-14 10:13, Michael A. Peters wrote:

I use TextTrack API but it's documention does not specify that it
closes open tags within a cue, in fact I'm fairly certain it doesn't
because some people use it for json and other related none tag related
content.

Looking at https://www.html5rocks.com/en/tutorials/track/basics/
it seems JSON can be used, no idea if content type is different or not
for that.


Some errors using the tracks in XML were solved by the innerHTML trick
where I create a separate html document, append the cue, and then grab
the innerHTML but that doesn't always work to close tags when html
entities are part of the cue string.


Mixing XML and HTML is not a good idea. Would it not be easier to have
the server send out proper XML instead of hTML? Valid XML is also valid
HTML (the reverse is not always true).


I agree, but what I was using an html document for - when using JS 
innerHTML it has closing tags so the only issue would be tags that html 
itself does not close (e.g. br) but those are not applicable with a 
WebVTT cue - which is only suppose to support a very small number of 
tags, all which have closing tags.


The problem is WebVTT does not require tags be closed in a cue, e.g.

04:05.000 --> 04:07.250
This is a cue.

That's allowed in WebVTT

I convert c.foo into

This is a cue.

and when I add that to the html document and use innerHTML it then has 
the closing  on it.


While it seems to work with some html entities, it breaks with others 
like  


So for now I have to just make sure all my WebVTT are closed and not use 
the hack that adds closing tags - but since WebVTT cues do not have to 
have closing tags, but the cues need to work in XML documents, a 
built-in parser in JS that can add missing closing tags I think would be 
a good thing.




And if XML and HTML is giving you issues then use JSON instead.
I did not see JSON mentioned in the W3C spec though.


I think the JSON in WebVTT cues is not spec but some are using it.

Basically the textrack API seems to allow almost any string, it really 
has to as WebVTT is not static and the spec changes. I wouldn't mind 
JSON being added to WebVTT as it would be a handy way to encode metadata 
about the media but that's another topic.


A built in JS HTML parser may also be of benefit in preventing code 
injection, e.g. stripping out tags from a WebVTT cue that a website does 
not allow.


The TextTrack API doesn't filter out things like script or other tags 
that aren't part of WebVTT which means any site that allows users to 
upload WebVTT files is creating a potential code injection vulnerability.


Server-side code should filter it on upload, but it would be nice to 
*someday* be able to pass a string through a native JS filter much the 
same way we can with htmltidy server-side and remove all but 
white-listed tags and attributes and get back a cleaned string with all 
tags closed.


It looks like Google has a library that does that but it isn't intended 
for client-side JS and may not be fast enough for things like phones to 
process time-sensitive cues (I don't know).


I might be wrong but it looked like the google library I found was 
intended for server-side Node.js use.

Re: [whatwg] JavaScript function for closing tags

[Michael A. Peters]

I use TextTrack API but it's documention does not specify that it closes 
open tags within a cue, in fact I'm fairly certain it doesn't because 
some people use it for json and other related none tag related content.


Some errors using the tracks in XML were solved by the innerHTML trick 
where I create a separate html document, append the cue, and then grab 
the innerHTML but that doesn't always work to close tags when html 
entities are part of the cue string.


I use JS regex to turn  into  and  
into  and just jQuery .append() to place 
the cue in a div for captions/subtitles since browser standard html5 
audio players have zero support for captions by themselves, and the 
jQuery .append() is what needs closing tags in XML or it understandably 
completely fails.


Also using it for chapters which don't appear to be supported in either 
browser standard audio or video players.


On 10/14/2017 12:46 AM, Silvia Pfeiffer wrote:

Hi Michael,

It seems to me that the TextTrack API is made for this use case.
Why does it not work for you?

Cheers,
Silvia.


On Sat, Oct 14, 2017 at 4:36 PM, Michael A. Peters
 wrote:

There does not seem to be a JavaScript API for closing open tags.

This is problematic when dealing with WebVTT which does not require tags be
closed.

Where it is the biggest problem is when the document is being served as
XML+XHTML

I tried the following hack which seemed to be working:

cleandoc = document.implementation.createHTMLDocument("FuBar");
cleanbody = document.createElementNS("http://www.w3.org/1999/xhtml";,
"body");
cleandoc.documentElement.appendChild(cleanbody);


Then I could do the following when with a WebVTT cue:

cleanbody.innerHTML = string;
return (cleanbody.innerHTML);

That *mostly* works but seems to sometimes fail when string contains
entities, such as  

What happens is it returns an empty string.

Given that WebVTT is part of HTML5 and browser native html5 audio players
don't support caption tracks forcing us to write our own implementations if
we want captions with audio, it sure would be nice if there was a pure
JavaScript way to just add closing tags to a string because there is never a
guarantee valid WebVTT cue has closed tags which are required for XHTML sent
as XML.

Seems to me that a JS native function to add missing closing tags would have
more application than just WebVTT cues.

I looked for a jQuery filter that does it, but could not find one.

It also could be of benefit in emulating document.write() as many of
Google's tools *still* require document.write() despite the issues with
document.write() and XML having been known for 15+ years now.

Any chance of getting a parser into JavaScript that at least would be
capable of closing open tags in a string passed to it?

[whatwg] JavaScript function for closing tags

[Michael A. Peters]

There does not seem to be a JavaScript API for closing open tags.

This is problematic when dealing with WebVTT which does not require tags 
be closed.


Where it is the biggest problem is when the document is being served as 
XML+XHTML


I tried the following hack which seemed to be working:

cleandoc = document.implementation.createHTMLDocument("FuBar");
cleanbody = document.createElementNS("http://www.w3.org/1999/xhtml";, 
"body");

cleandoc.documentElement.appendChild(cleanbody);


Then I could do the following when with a WebVTT cue:

cleanbody.innerHTML = string;
return (cleanbody.innerHTML);

That *mostly* works but seems to sometimes fail when string contains 
entities, such as  


What happens is it returns an empty string.

Given that WebVTT is part of HTML5 and browser native html5 audio 
players don't support caption tracks forcing us to write our own 
implementations if we want captions with audio, it sure would be nice if 
there was a pure JavaScript way to just add closing tags to a string 
because there is never a guarantee valid WebVTT cue has closed tags 
which are required for XHTML sent as XML.


Seems to me that a JS native function to add missing closing tags would 
have more application than just WebVTT cues.


I looked for a jQuery filter that does it, but could not find one.

It also could be of benefit in emulating document.write() as many of 
Google's tools *still* require document.write() despite the issues with 
document.write() and XML having been known for 15+ years now.


Any chance of getting a parser into JavaScript that at least would be 
capable of closing open tags in a string passed to it?

Re: [whatwg] Allow alt attribute with the span element

[Michael A. Peters]

On 10/06/2017 08:44 AM, Léonie Watson wrote:


On 06/10/2017 11:26, Michael A. Peters wrote:

Nope, no problem at all. That looks like a simple solution I did not
find. Thank you.


Note that you need to provide an explicit role on the span if you use
aria-label to provide its accessible name.


I assume if I instead put the aria-label on the button rather than span 
that contains the pictograph, that would work too without needing a role 
since it is an actual button.

Re: [whatwg] Allow alt attribute with the span element

[Michael A. Peters]

Nope, no problem at all. That looks like a simple solution I did not 
find. Thank you.


On 10/06/2017 08:23 AM, Jonathan Garbee wrote:

Is there a problem with using aria-label
<https://www.w3.org/TR/wai-aria/states_and_properties#aria-label> for
this use case? It seems like this should do exactly what you're asking
for in the given scenario.

On Fri, Oct 6, 2017 at 11:15 AM, Michael A. Peters
mailto:mpet...@domblogger.net>> wrote:

With images, the alt attribute can and should be used to give a
description of an image for users who can not see the image.

With text, some glyphs are pictographs that have a meaning. For
example, U+1F502 is a pictograph indicating single loop, but it is
meaningless if you can not see it.

Even if screen readers can specify the codepoint and/or map the
codepoint to a description (do they?) sometimes fonts define PUA
codepoints for pictograph glyphs that are not official.

A span element with a title attribute does not always solve this
problem, sometimes the glyph is in a button element that has a title
attribute describing what the button will do rather than the what
the current state is.

For example, a button may show a single loop indicating the media is
currently in single loop mode but have a title attribute specifying
that pressing it enables continuous loop mode.

If there was an alt attribute on a span inside the button, screen
readers could treat the span with a pictograph the same way it would
treat an image child of a button attribute and describe the current
pictograph to the end user.

If there is already a solution to this issue, I apologize, I could
not find one.

We (er, WhatWG / W3C) could just add alt to the global attribute
list too, rather than just span. Or come up with a semantic
pictograph element specifically for this (just like we have tt and
code).

Thank you for opinions.

[whatwg] Allow alt attribute with the span element

[Michael A. Peters]

With images, the alt attribute can and should be used to give a 
description of an image for users who can not see the image.


With text, some glyphs are pictographs that have a meaning. For example, 
U+1F502 is a pictograph indicating single loop, but it is meaningless if 
you can not see it.


Even if screen readers can specify the codepoint and/or map the 
codepoint to a description (do they?) sometimes fonts define PUA 
codepoints for pictograph glyphs that are not official.


A span element with a title attribute does not always solve this 
problem, sometimes the glyph is in a button element that has a title 
attribute describing what the button will do rather than the what the 
current state is.


For example, a button may show a single loop indicating the media is 
currently in single loop mode but have a title attribute specifying that 
pressing it enables continuous loop mode.


If there was an alt attribute on a span inside the button, screen 
readers could treat the span with a pictograph the same way it would 
treat an image child of a button attribute and describe the current 
pictograph to the end user.


If there is already a solution to this issue, I apologize, I could not 
find one.


We (er, WhatWG / W3C) could just add alt to the global attribute list 
too, rather than just span. Or come up with a semantic pictograph 
element specifically for this (just like we have tt and code).


Thank you for opinions.

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 ???

[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 ???

[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 ???

[Michael A. Peters]

On 07/24/2017 04:43 PM, Qebui Nehebkau wrote:

On 24 July 2017 at 19:21, Michael A. Peters  wrote:


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.



It sounds like the machines probably want to fetch some kind of index page,
not the page for a particular item. I think that if you find yourself
wanting to send two different sets of content to different users, you
probably need to be directing them to different resources.



No, the structured data should be generated the same time as the content.

It's just if it resides in a single script node in the head that can end 
up being quite large, there's no need to include that node when the 
client has no use for it.


Right now, I only send it if the client is an honest bot. But there may 
be some browser add-ons that make use of it, so they should be able to 
announce they want it and get it.

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

[Michael A. Peters]

When too much is displayed, the website is too busy.

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.


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.


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.


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.


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 
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, hence the desire for a standard header
machines that do want it can send to have it included.


A better example.

I run an audio site (all legal, no piracy, I'm anti-DRM but also pro
intellectual property) where users can select a category.

There could be, say, 12 audios in that category, but the web page only
displays one. If the user wants to listen to a different audio, they use
a select menu. If its the same artist, there's enough info in the data-*
attributes of the select menu items to swap the audio node w/o even an
ajax call, If different artist, I do make an ajax call because more than
just the audio node changes.

With JSON-LD I can put structured data for all audios the person can
play from that page into the JSON-LD. I can't do that with tag based
structured data unless I make a div display display:none to contain all
the other audios.

I use libxml2 to create pages so I can modify any part of the DOM at any
point allowing me to create the JSON-LD from the same data used to
generate the page, so it is always in sync. I then can stuff it in the
head node at the end.

That's not possible with many platforms that send content before it is
finished generating all the page, so JSON-LD for many may not have the
kind of advantage I can from it, but the ability to describe objects
available through user actions (such as select menu) but aren't part of
the DOM when the page is sent is a huge benefit to me over tag based
implementations of structured data.

Hope that sheds some light on why I had an epiphany when I finally
stopped to read about JSON-LD.

Now, back on topic, a header would be nice so I only have to stuff it in
the head when a machine is asking for it ;)

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

[Michael A. Peters]

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, hence the desire for a standard header
machines that do want it can send to have it included.


A better example.

I run an audio site (all legal, no piracy, I'm anti-DRM but also pro 
intellectual property) where users can select a category.


There could be, say, 12 audios in that category, but the web page only 
displays one. If the user wants to listen to a different audio, they use 
a select menu. If its the same artist, there's enough info in the data-* 
attributes of the select menu items to swap the audio node w/o even an 
ajax call, If different artist, I do make an ajax call because more than 
just the audio node changes.


With JSON-LD I can put structured data for all audios the person can 
play from that page into the JSON-LD. I can't do that with tag based 
structured data unless I make a div display display:none to contain all 
the other audios.


I use libxml2 to create pages so I can modify any part of the DOM at any 
point allowing me to create the JSON-LD from the same data used to 
generate the page, so it is always in sync. I then can stuff it in the 
head node at the end.


That's not possible with many platforms that send content before it is 
finished generating all the page, so JSON-LD for many may not have the 
kind of advantage I can from it, but the ability to describe objects 
available through user actions (such as select menu) but aren't part of 
the DOM when the page is sent is a huge benefit to me over tag based 
implementations of structured data.


Hope that sheds some light on why I had an epiphany when I finally 
stopped to read about JSON-LD.


Now, back on topic, a header would be nice so I only have to stuff it in 
the head when a machine is asking for it ;)

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

[Michael A. Peters]

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

On 23 July 2017 at 14:12, Michael A. Peters  wrote:


It's a beautiful way to create structured data separate from the content,
just like layout (CSS) is best kept separate from the content. [...] I
wonder why people on this list don't like it. Reading about it was an
epiphany for me, it's (in my opinion) the right way to do structured data,
and far superior to sticking a bunch of attributes in tags - just like CSS
selectors are far superior to sticking style attributes in tags.



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, hence the desire for a standard header 
machines that do want it can send to have it included.

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

[Michael A. Peters]

Interesting. It's a beautiful way to create structured data separate 
from the content, just like layout (CSS) is best kept separate from the 
content.


I wonder why people on this list don't like it. Reading about it was an 
epiphany for me, it's (in my opinion) the right way to do structured 
data, and far superior to sticking a bunch of attributes in tags - just 
like CSS selectors are far superior to sticking style attributes in tags.


Not meaning to start a holy war, it's just I didn't come across anything 
negative about it during my initial research on JSON-LD. Other than my 
own observation that it bloats the content sent to every client, hence 
the desire for a header specifying it is actually wanted before it is 
stuffed in the document head node.



On 07/22/2017 10:12 PM, Jeffrey Yasskin wrote:

2¢: This list tends to disapprove of JSON-LD, so you should probably first
run your proposal by a group that likes JSON-LD. Maybe
public-rdf-comme...@w3.org referenced from https://www.w3.org/TR/json-ld/?
Or an issue against https://github.com/json-ld/json-ld.org?

Jeffrey

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


I am (finally) starting to implement JSON-LD on a site, it generates a lot
of data that is useless to the non-bot typical user.

I'd prefer to only stick it in the head when the client is a crawler that
wants it.

Wouldn't it be prudent if agents that want JSON-LD can send a standardized
header as part of their request so web apps can optionally choose to only
send the JSON-LD data to clients that want it? Seems it would be kinder to
mobile users on limited bandwidth if they didn't have to download a bunch
of JSON that is meaningless to them.

Is this the right group to suggest that?

[whatwg] header for JSON-LD ???

[Michael A. Peters]

I am (finally) starting to implement JSON-LD on a site, it generates a 
lot of data that is useless to the non-bot typical user.


I'd prefer to only stick it in the head when the client is a crawler 
that wants it.


Wouldn't it be prudent if agents that want JSON-LD can send a 
standardized header as part of their request so web apps can optionally 
choose to only send the JSON-LD data to clients that want it? Seems it 
would be kinder to mobile users on limited bandwidth if they didn't have 
to download a bunch of JSON that is meaningless to them.


Is this the right group to suggest that?

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

On 12/09/2016 06:14 PM, Florian Rivoal wrote:

On Dec 9, 2016, at 23:07, Michael A. Peters  wrote:

This was inspired by inspection of a style-sheet in the wild that uses 
screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where bandwidth 
doesn't matter and my laptop via a mifi where bandwidth does matter.

I would like a CSS media query for bandwidth so that I can reduce how many 
webfonts are used in low bandwidth scenarios. It seems browsers are already 
smart enough to only download a font defined by @font-face if they need it, so 
it only needs to be done where the font is used, e.g.


It's been considered before, and that approach will not work. Media queries are 
the wrong tool for this. Neutrality / bias warning: I'm co-editor of the Media 
Queries spec.

Media queries, by design, will switch instantly when the environment changes, 
stop applying the old styles, and start applying the new ones. So if you finish 
loading a page on your phone in your home wifi with the high-res and heavy 
assets, start reading, then walk outside into 3G, you'll discard the high res 
assets and start loading the low res ones. And if you're driving / riding a 
train in and out of tunnels, you'll toggle between high and low (or low and 
terrible) constantly, and never manage to finish loading anything, all while 
using copious amounts of bandwidth. This isn't a bug, this is how Media Queries 
work, and is the right thing to do for things where media queries are the right 
tool. If that's not what you want, what you want isn't a media query.

The right approach is something like srcset[1], the source element[2], or 
image-set()[3]: instead of switching between one variant or another based on a 
hard criteria, you provide the UA with all the variants you have, and let it 
switch intelligently.

Of course, these are UA based heurisitics, it is certainly possible that the UA 
will make poor decisions sometimes, but that's a lot better than the guaranteed 
bad behavior you'd get with Media queries.

For fonts, there isn't currently an equivalent mechanism, but we could think of 
adding qualifiers either the @font-face that declares the font, or font-family 
that tries to use it, to indicate that certain fonts are must-have, while 
others are optional things that are fine to skip in case of bad bandwidth or 
latency.

There's already one proposal in that direction, although it hasn't received 
much attention lately: https://tabatkins.github.io/specs/css-font-display/

Finally, while you're free to talk about this anywhere you like, traditionally 
the best forum for CSS related topics is the CSSWG, either through its 
github[4] or its mailing list[5].

—Florian

[1] https://html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset
[2] 
https://html.spec.whatwg.org/multipage/embedded-content.html#the-source-element
[3] https://drafts.csswg.org/css-images-3/#image-set-notation
[4] https://github.com/w3c/csswg-drafts/issues
[5] https://lists.w3.org/Archives/Public/www-style/



I've thought about this for several hours now and I have to concede, a 
media query is not the right place for this.


I don't think @font-face is either as it would cause backwards 
compatibility problems, and there are other issues with @font-face.


For example, when I use @font-face to define a bold font face, then when 
I declare that font for strong I have to explicitly tell the CSS to use 
the normal weight or the browser applies a fake bold to the already bold 
font.


Perhaps what is needed is an @font-family declaration that can be used 
to specify the various variants of a font.


Then when the font-family is called and something like a strong tag is 
encountered, the browser will use the defined bold variant if it exists 
and apply fake bold to the roman font if it does not.


If variants within @font-family are declared optional, then the browser 
does not have to include it.


That would solve another problem with my media query solution. If the 
page was ever loaded when bandwidth isn't an issue, it may have the 
optional woff2 files in cache.


It would then be able to use them even in low bandwidth, since it 
already had them, and only apply fake variant instead if it doesn't have 
it in cache and it is flagged as optional.


I'll think about this some more, then join the right list for it and put 
the revised idea there.


But for now I have to concede media query is the wrong approach.

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

I have pondered that, and those cases will not be typical. The page may 
start to load the high bandwidth content (just like it does right now) 
and that may cause slow page loading as they walk outside (just like it 
does right now) but the next page at the site they load will use the 
low-bandwidth CSS and load a lot faster - unlike it does right now.


On 12/09/2016 11:58 AM, Jonathan Garbee wrote:

Also, Ponder this case:

User is on their cell phone and at home on wifi. So your "This user as
50MBs, send them 4k images!" query is hit on initial load. Well, 25%
through page resources being called, they walk 20 feet outside of their
home and now they are on their ~3G cell tower connection. If it is stuck on
initial test metrics, that user is stuck downloading 75% of your 4k images
and fonts over their cell connection. Now consider it as a pay-per-usage
connection and you have easily blown a hole in their wallet.

These things can't be locked into a single point in time. It just doesn't
work from the perspective of the user. So whatever is done here, would need
to be adaptable which in the case of CSS is even more complex since it is
declarative and developers give up so much control. Bandwidth Media Queries
simply aren't feasible.

On Fri, Dec 9, 2016 at 2:51 PM Jonathan Garbee  wrote:


FTR there was a working group to provide a Network Information API [1] to
let JS handle this more easily. In trying to do that, they had a difficult
time actually getting accurate information for the API to provide. So it
was canned in order to further assess the cases specifically and other
approaches. I highly doubt if there was trouble building a JS API for this
type of thing that CSS alone can handle it in some way.

If something like this is to happen, it *needs* to happen in JS first.
That way developers have control, from a working and proven implementation
there we could find a syntax for CSS to work on top of. So for now, you're
probably best off polyfilling some JS API and using that to experiment with
to present as a solution. That way it can be more easily vetted and tested.

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters 
wrote:

On 12/09/2016 09:03 AM, Boris Zbarsky wrote:

On 12/9/16 5:57 AM, Michael A. Peters wrote:

max-height and max-width and orientation change, but device-width does
not change.


Just as a point of fact, device-width can absolutely change.  The
simplest case is a two-monitor setup with the window getting dragged
from one monitor to another, but similar things can happen when things
are docked/undocked, monitors are plugged in or removed, etc.

-Boris


Ah yes, point taken.

With a bandwidth query I would recommend it only change on a page reload
but it wouldn't have to be done that way.

This wouldn't only be beneficial to fonts, a lot of images etc. are
defined in CSS too.

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

I don't think it needs to happen in JS first. A CSS media query is 
completely opt-in. Developers don't need to use the media query if they 
do not want to, it is just a way that developers can make their websites 
more friendly to users with bandwidth constraints without sacrificing 
for users who do not have bandwidth constraints.


On 12/09/2016 11:51 AM, Jonathan Garbee wrote:

FTR there was a working group to provide a Network Information API [1] to
let JS handle this more easily. In trying to do that, they had a difficult
time actually getting accurate information for the API to provide. So it
was canned in order to further assess the cases specifically and other
approaches. I highly doubt if there was trouble building a JS API for this
type of thing that CSS alone can handle it in some way.

If something like this is to happen, it *needs* to happen in JS first. That
way developers have control, from a working and proven implementation there
we could find a syntax for CSS to work on top of. So for now, you're
probably best off polyfilling some JS API and using that to experiment with
to present as a solution. That way it can be more easily vetted and tested.

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters 
wrote:


On 12/09/2016 09:03 AM, Boris Zbarsky wrote:

On 12/9/16 5:57 AM, Michael A. Peters wrote:

max-height and max-width and orientation change, but device-width does
not change.


Just as a point of fact, device-width can absolutely change.  The
simplest case is a two-monitor setup with the window getting dragged
from one monitor to another, but similar things can happen when things
are docked/undocked, monitors are plugged in or removed, etc.

-Boris


Ah yes, point taken.

With a bandwidth query I would recommend it only change on a page reload
but it wouldn't have to be done that way.

This wouldn't only be beneficial to fonts, a lot of images etc. are
defined in CSS too.

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

On 12/09/2016 09:03 AM, Boris Zbarsky wrote:

On 12/9/16 5:57 AM, Michael A. Peters wrote:

max-height and max-width and orientation change, but device-width does
not change.


Just as a point of fact, device-width can absolutely change.  The
simplest case is a two-monitor setup with the window getting dragged
from one monitor to another, but similar things can happen when things
are docked/undocked, monitors are plugged in or removed, etc.

-Boris


Ah yes, point taken.

With a bandwidth query I would recommend it only change on a page reload 
but it wouldn't have to be done that way.


This wouldn't only be beneficial to fonts, a lot of images etc. are 
defined in CSS too.

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

How the browsers determine bandwidth would be up to the browser.

I assume they would have a reasonable default that the user can choose 
to override - like many other browser options.


On 12/09/2016 08:19 AM, Jonathan Garbee wrote:

So, if this were to get in it is magically up to users to know to go change
the settings (most don't) to get different modes. That is bad design. We
need to handle things for users in this situation. Not do something and
hope they pay attention.

If you're suggesting a feature that requires browser settings explicit for
it, rethink it.

JavaScript handling let's you do exactly what you want. Let the most
performance oriented solution be your default and enhance on top of that
after load. There are other things coming for fonts, like the font loading
API, to help make funny transitioning seamless.

Browsers are handling things like data saver modes to let users opt in to
certain things on their end. Overall, introducing media queries based on
the network is a bad design.

On Fri, Dec 9, 2016, 11:09 AM Yay295  wrote:


On another note, are you sure it's *font files* that are slowing down your
page load? Maybe I've just been lucky, but of the 24 font files I happen to
have in a folder on my computer, 19 of them are only about 50KB. That's
one-fifth the size of jQuery. Perhaps you should be looking at shrinking
your font files first if they're such a problem?

On Fri, Dec 9, 2016 at 8:32 AM, Jonathan Zuckerman 
wrote:


Michael - I think "high" and "low" are very relative terms, defining

those

terms for all users for all time doesn't seem possible. Also,
connectivity/bandwidth are subject to change at any moment during the
lifetime of a page. Current media queries like `max-height` or
`min-resolution` would respond to changes, have you thought about how

your

proposed addition would behave?

Currently you can use javascript to figure out if the network will

support

your enhanced experience (and you're free to define what that means) and
add a classname to the document to trigger the css rules for that
experience, so you can build the feature you're asking for using existing
parts. It's not baked into the platform, but because of the nature of the
web and vagueness of the requirements, I'm not sure it's possible to do

any

better.

On Fri, Dec 9, 2016 at 9:07 AM Michael A. Peters 
This was inspired by inspection of a style-sheet in the wild that uses
screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where
bandwidth doesn't matter and my laptop via a mifi where bandwidth does
matter.

I would like a CSS media query for bandwidth so that I can reduce how
many webfonts are used in low bandwidth scenarios. It seems browsers

are

already smart enough to only download a font defined by @font-face if
they need it, so it only needs to be done where the font is used, e.g.

pre {
   font-family: 'monoFont-Roman', monospace;
}
pre em {
   font-family: 'monoFont-Italic', monospace;
   font-style: normal;
}
pre strong {
   font-family: 'monoFont-Bold', monospace;
   font-weight: normal;
}
pre em strong {
   font-family: 'monoFont-BoldItalic', monospace;
   font-style: normal;
   font-weight: normal;
}
pre strong em {
   font-family: 'monoFont-BoldItalic', monospace;
   font-style: normal;
   font-weight: normal;
}
@media screen and (device-bandwidth: low) {
   pre strong {
 font-family: 'monoFont-Roman', monospace;
 font-weight: 700;
   }
   pre em strong {
 font-family: 'monoFont-Italic', monospace;
 font-weight: 700;
   }
   pre strong em {
 font-family: 'monoFont-Italic', monospace;
 font-weight: 700;
   }
}

That right there cuts the number of fonts the low-bandwidth device

needs

in half, and could have even gone further and used fake italic if the
fake italic for the font looks good enough.

The small increase in CSS file size doesn't matter with high bandwidth
clients and is justified for low-bandwidth as it reduces the content
that needs to be fetched.

It would be up to the client to define the device-bandwidth, web
developers should create the CSS for high bandwidth and only have the
alternate CSS kick in when a media query says it is low.

Honestly I think low or high are the only definitions needed with low
being the only one that a site should have conditional styles set for.

-=-

The same concept could be applied to html5 media too. e.g. I could

serve

the 64 kbps opus to clients that don't define themselves as low, and

the

32 kbps opus to clients that do define themselves as low.

How to handle media in situations where a service worker pre-fetches
content I haven't thought about, because a client may pre-fetch content
before the bandwidth constraint changes, but I suspect there'

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

My pages are not slow and tend to be much smaller than the typical web 
page out there.


The size of a woff2 file can vary greatly depending upon what characters 
it covers and the complexity of those characters.


jQuery is only needed once as it should then be cached for a very long 
time, and quite often is served from a CDN where the user does not need 
to load it for each and every site they visit.


With fonts, many sites use at least three different families and often 
several faces within those families, which is appropriate because many 
characters are far more readable when a genuine font face is used rather 
than fake italic or bold. The w character for example is often drawn 
different and more readable in the italic variant of the family.


There are free fonts that also exist on CDNs but there are many to 
choose from so it is less likely the user already has them cached even 
if they are on a common CDN (e.g. Google Fonts), and many webmasters 
license fonts that can't be on a common CDN due to the license.


There is a push for privacy reasons to limit a browsers ability to use 
fonts from the system, access to system fonts can be used for browser 
fingerprinting. If that push is successful (and I hope it is) then web 
font usage may increase due to the limited fonts that a particular 
browser may ship with.


Allowing for genuine font faces (and fatter font faces) where bandwidth 
isn't an issue but limiting the font faces (and using slimmer fonts) 
where bandwidth is an issue can provide for a better user experience 
when there are bandwidth constraints on the client.


A better experience for the end user under those fairly common 
conditions (especially common in developing countries) I believe is a 
worthwhile goal.


Web developers that don't want to or feel they don't need to accommodate 
those users won't have to, but those who do want to take bandwidth 
concerns into consideration will be able to.


I don't know how common it is, but it was a style sheet I saw in the 
wild where the web developer was trying to use device-width to 
accomplish that goal that made me think about a better way, because I do 
believe taking bandwidth into consideration is a noble thing for a web 
developer to do, and they shouldn't have to use device-width to try and 
accomplish that.


In my opinion.

On 12/09/2016 08:09 AM, Yay295 wrote:

On another note, are you sure it's *font files* that are slowing down your
page load? Maybe I've just been lucky, but of the 24 font files I happen to
have in a folder on my computer, 19 of them are only about 50KB. That's
one-fifth the size of jQuery. Perhaps you should be looking at shrinking
your font files first if they're such a problem?

On Fri, Dec 9, 2016 at 8:32 AM, Jonathan Zuckerman 
wrote:


Michael - I think "high" and "low" are very relative terms, defining those
terms for all users for all time doesn't seem possible. Also,
connectivity/bandwidth are subject to change at any moment during the
lifetime of a page. Current media queries like `max-height` or
`min-resolution` would respond to changes, have you thought about how your
proposed addition would behave?

Currently you can use javascript to figure out if the network will support
your enhanced experience (and you're free to define what that means) and
add a classname to the document to trigger the css rules for that
experience, so you can build the feature you're asking for using existing
parts. It's not baked into the platform, but because of the nature of the
web and vagueness of the requirements, I'm not sure it's possible to do any
better.

On Fri, Dec 9, 2016 at 9:07 AM Michael A. Peters 
wrote:


This was inspired by inspection of a style-sheet in the wild that uses
screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where
bandwidth doesn't matter and my laptop via a mifi where bandwidth does
matter.

I would like a CSS media query for bandwidth so that I can reduce how
many webfonts are used in low bandwidth scenarios. It seems browsers are
already smart enough to only download a font defined by @font-face if
they need it, so it only needs to be done where the font is used, e.g.

pre {
   font-family: 'monoFont-Roman', monospace;
}
pre em {
   font-family: 'monoFont-Italic', monospace;
   font-style: normal;
}
pre strong {
   font-family: 'monoFont-Bold', monospace;
   font-weight: normal;
}
pre em strong {
   font-family: 'monoFont-BoldItalic', monospace;
   font-style: normal;
   font-weight: normal;
}
pre strong em {
   font-family: 'monoFont-BoldItalic', monospace;
   font-style: normal;
   font-weight: normal;
}
@media screen and (device-bandwidth: low) {
   pre strong {
 font-family: 'monoFont-Roman', monospace;
 font-weight: 700;
   }
 

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

max-height and max-width and orientation change, but device-width does 
not change.


It should behave like device-width because it should be applied when the 
resources are fetched and the page is rendered.


Yes low and high are relative, which is why it should be determined by 
the browser potentially with user preference settings to what means high 
and low to the user.


Someone using a service where they pay for all their bandwidth may want 
it always defined as low except when on wifi, someone who doesn't pay 
for bandwidth may want it only set to low when their phone only has two 
bars.


Leaving it up to the client allows it to remain relative. It doesn't 
need to be more fine-grained than high or low because web designers 
aren't likely to make use of more than two options anyway.


On 12/09/2016 07:32 AM, Jonathan Zuckerman wrote:

Michael - I think "high" and "low" are very relative terms, defining those
terms for all users for all time doesn't seem possible. Also,
connectivity/bandwidth are subject to change at any moment during the
lifetime of a page. Current media queries like `max-height` or
`min-resolution` would respond to changes, have you thought about how your
proposed addition would behave?

Currently you can use javascript to figure out if the network will support
your enhanced experience (and you're free to define what that means) and
add a classname to the document to trigger the css rules for that
experience, so you can build the feature you're asking for using existing
parts. It's not baked into the platform, but because of the nature of the
web and vagueness of the requirements, I'm not sure it's possible to do any
better.

On Fri, Dec 9, 2016 at 9:07 AM Michael A. Peters 
wrote:


This was inspired by inspection of a style-sheet in the wild that uses
screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where
bandwidth doesn't matter and my laptop via a mifi where bandwidth does
matter.

I would like a CSS media query for bandwidth so that I can reduce how
many webfonts are used in low bandwidth scenarios. It seems browsers are
already smart enough to only download a font defined by @font-face if
they need it, so it only needs to be done where the font is used, e.g.

pre {
   font-family: 'monoFont-Roman', monospace;
}
pre em {
   font-family: 'monoFont-Italic', monospace;
   font-style: normal;
}
pre strong {
   font-family: 'monoFont-Bold', monospace;
   font-weight: normal;
}
pre em strong {
   font-family: 'monoFont-BoldItalic', monospace;
   font-style: normal;
   font-weight: normal;
}
pre strong em {
   font-family: 'monoFont-BoldItalic', monospace;
   font-style: normal;
   font-weight: normal;
}
@media screen and (device-bandwidth: low) {
   pre strong {
 font-family: 'monoFont-Roman', monospace;
 font-weight: 700;
   }
   pre em strong {
 font-family: 'monoFont-Italic', monospace;
 font-weight: 700;
   }
   pre strong em {
 font-family: 'monoFont-Italic', monospace;
 font-weight: 700;
   }
}

That right there cuts the number of fonts the low-bandwidth device needs
in half, and could have even gone further and used fake italic if the
fake italic for the font looks good enough.

The small increase in CSS file size doesn't matter with high bandwidth
clients and is justified for low-bandwidth as it reduces the content
that needs to be fetched.

It would be up to the client to define the device-bandwidth, web
developers should create the CSS for high bandwidth and only have the
alternate CSS kick in when a media query says it is low.

Honestly I think low or high are the only definitions needed with low
being the only one that a site should have conditional styles set for.

-=-

The same concept could be applied to html5 media too. e.g. I could serve
the 64 kbps opus to clients that don't define themselves as low, and the
32 kbps opus to clients that do define themselves as low.

How to handle media in situations where a service worker pre-fetches
content I haven't thought about, because a client may pre-fetch content
before the bandwidth constraint changes, but I suspect there's a clever
solution to that (e.g. always fetch high bandwidth when async pre-fetch
and then use high bandwidth when cached even if in low bandwidth mode)

But html5 media can be figured out later, CSS is what I really would
like to see a bandwidth media query for.

Thoughts?

[whatwg] Media query for bandwidth ??

[Michael A. Peters]

This was inspired by inspection of a style-sheet in the wild that uses 
screen-width to try and reduce bandwidth needs of mobile devices.


I like the concept, but very often I use my mobile devices where 
bandwidth doesn't matter and my laptop via a mifi where bandwidth does 
matter.


I would like a CSS media query for bandwidth so that I can reduce how 
many webfonts are used in low bandwidth scenarios. It seems browsers are 
already smart enough to only download a font defined by @font-face if 
they need it, so it only needs to be done where the font is used, e.g.


pre {
  font-family: 'monoFont-Roman', monospace;
}
pre em {
  font-family: 'monoFont-Italic', monospace;
  font-style: normal;
}
pre strong {
  font-family: 'monoFont-Bold', monospace;
  font-weight: normal;
}
pre em strong {
  font-family: 'monoFont-BoldItalic', monospace;
  font-style: normal;
  font-weight: normal;
}
pre strong em {
  font-family: 'monoFont-BoldItalic', monospace;
  font-style: normal;
  font-weight: normal;
}
@media screen and (device-bandwidth: low) {
  pre strong {
font-family: 'monoFont-Roman', monospace;
font-weight: 700;
  }
  pre em strong {
font-family: 'monoFont-Italic', monospace;
font-weight: 700;
  }
  pre strong em {
font-family: 'monoFont-Italic', monospace;
font-weight: 700;
  }
}

That right there cuts the number of fonts the low-bandwidth device needs 
in half, and could have even gone further and used fake italic if the 
fake italic for the font looks good enough.


The small increase in CSS file size doesn't matter with high bandwidth 
clients and is justified for low-bandwidth as it reduces the content 
that needs to be fetched.


It would be up to the client to define the device-bandwidth, web 
developers should create the CSS for high bandwidth and only have the 
alternate CSS kick in when a media query says it is low.


Honestly I think low or high are the only definitions needed with low 
being the only one that a site should have conditional styles set for.


-=-

The same concept could be applied to html5 media too. e.g. I could serve 
the 64 kbps opus to clients that don't define themselves as low, and the 
32 kbps opus to clients that do define themselves as low.


How to handle media in situations where a service worker pre-fetches 
content I haven't thought about, because a client may pre-fetch content 
before the bandwidth constraint changes, but I suspect there's a clever 
solution to that (e.g. always fetch high bandwidth when async pre-fetch 
and then use high bandwidth when cached even if in low bandwidth mode)


But html5 media can be figured out later, CSS is what I really would 
like to see a bandwidth media query for.


Thoughts?

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 12/02/2016 08:47 AM, Boris Zbarsky wrote:

On 12/2/16 11:34 AM, Michael A. Peters wrote:

It seems that CSP behavior has radically changed since the last time I
looked at it


I can't speak to when you last looked at it, but the current state
shipping in browsers is, as far as I know, no different from what
browsers shipped initially for purposes of this discussion.


At least historically, the on* attributes were not allowed, the style
attributes were not allowed, and any script nodes in the body were not
allowed.


If you specify script-src and style-src and don't include
'unsafe-inline', sure.


If CSP now allows them by default then I am not very happy about that


CSP allows the things you don't issue directives for.  If you don't
issue any script-src directives (or default-src directives), then there
won't be any limitations on scripts.

-Boris


Last time I read the specification, unsafe-inline didn't exist. Last 
time I glanced at the site, unsafe-inline existed but was not supported 
by all browsers and required a declared hash to work.

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 12/02/2016 08:23 AM, Boris Zbarsky wrote:

On 12/2/16 11:01 AM, Michael A. Peters wrote:

Personally I love CSP but it does not allow inline scripts or inline CSS


Only if you say to not allow them.  The default behavior allows them.
For example, this disallows inline scripts, because script-src is
explicitly specified without unsafe-inline, but does nothing about
inline CSS:

  
  
  body { color: green; }
  This is green
  alert("I am not alerted")


I believe there now are CSP parameters that relax those prohibitions but
from I understand they are only relaxed when a hash of the inline
scripts / CSS is declared in the head.


That's ... not correct.  Simple example; compare it to the previous one:


It seems that CSP behavior has radically changed since the last time I 
looked at it, which was to create support for it in my php class that 
generates web pages using DOMDocument, so I can't comment on what the 
current state of it is then.


At least historically, the on* attributes were not allowed, the style 
attributes were not allowed, and any script nodes in the body were not 
allowed.


They were not allowed for very good reasons - there is no way for the 
browser to determine if they are intentional or are the result of a XSS 
injection in the web application.


JS and CSS in external files referenced from the head was the only way 
to safely determine they were intended and not injected.


If CSP now allows them by default then I am not very happy about that, 
as it would greatly reduce the effective security, but it sounds like I 
would have to read through the current documentation to further comment 
on CSP.

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

Personally I love CSP but it does not allow inline scripts or inline CSS 
and over 95% of the web makes heavy use of both.


I believe there now are CSP parameters that relax those prohibitions but 
from I understand they are only relaxed when a hash of the inline 
scripts / CSS is declared in the head.


Google Webmaster Tools including PageSpeed also heavily encourage all 
JavaScript being referenced at the end of the page so that it isn't 
above the fold and because they are Google, most of the masses believe 
that is best and will help with page search ranking and that too isn't 
compatible with CSP where the scripts need to be defined in the head 
(except for maybe with the new unsafe-inline option that requires 
checksum in the head ???)


I don't know what the planned CSP option for window.opener() looks like, 
I just know that most websites break as soon as a CSP header is sent and 
it isn't always trivial to make them work.


On 12/02/2016 05:01 AM, Jonathan Zuckerman wrote:

Could you elaborate on the point made earlier that CSP is too complicated
to implement? What would the fix for this particularly security hole look
like, using CSP?

On Fri, Dec 2, 2016 at 1:11 AM Richard Maher  wrote:

Thanks Michael. So to be safe one should use Edge? Who'd have thunk it?

Anyone tested Michael's example on FireFox or Safari?

It does look like Chrome is the driver of rel=noopener. Does the credential
API https://w3c.github.io/webappsec-credential-management/ rely on this
flaw?

On Fri, Dec 2, 2016 at 11:44 AM, Michael A. Peters 
wrote:


If window.opener() did not work cross-domain then as far as I can tell
that would be secure.


On 12/01/2016 07:23 PM, Richard Maher wrote:


I see what you're saying Michael and also agree it's serious. Would I be
correct in thinking that MS Edge solves the problem by not returning
window.opener cross-domain? Is the UA not a logical and uniform place for
this?

BTW I've also experienced the CitHub topic-closure nazis many times :-(


On Fri, Dec 2, 2016 at 10:42 AM, Michael A. Peters <
mpet...@domblogger.net>
wrote:

Well if it was done as a header, I suppose it could be added as a

http-equiv meta tag for those who want to.

Header is the easiest solution to make sure it is applied everywhere
without question. It could even be added at the front-end proxy to cover
numerous web applications on many domains at once.

And I know this is conspiracy theory, but that's why I think there is
such
resistance to it.

Since the flaw is required for OAuth to work, companies invested in

OAuth

and that profit from OAuth solutions don't want sites behind proxies

that

would break OAuth and don't want webmasters to understand they have to
reduce security in order to implement an OAuth solution.

That's just a suspicion of mine, but I can't think of any other logical
reason as to why a node attribute was chosen as the solution, and why
there
is such resistance to doing it the right way with a header. To me it

just

doesn't make sense.


On 12/01/2016 05:45 PM, Zac Spitzer wrote:

how about rather than requiring this on every  why not support a base

tag directive
for the whole document i.e. , similar to ?

On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola  wrote:

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian


Hickson

I believe that's a bit of an overstatement. There are certainly risks



involved in window.opener (they're briefly discussed in the spec

itself),
but it doesn't remove the origin checks.

This is the crucial point.

Whenever you are discussing a supposed security issue, you need to

make

clear what the threat model is. That is:

- What would be the impact on the victim if the security hole is taken
advantage of?
- Is this something we are trying to prevent on the web platform?

In this case, the impact on the victim (a user of a web browser) is
that
they could click a link from page A to page B, which opens in a new

tab

(tab B). Then, tab A could be navigated to a new URL, instead of
staying
on
page A.

This is not a big impact. Notably, page B is not able to read any of
the
content of page A, which might be sensitive. Page B is not able to
interfere with the operation of any of page B's scripts. And

crucially,

when page B navigates tab A to another page, the URL bar of tab A
changes
to indicate that.

There is no desired security guarantee on the platform that we want to
prevent pages from directing users to "bad" sites. We count on users
inspecting the URL bar to understand what page they are interacting
with
in
a given tab.

So, while it might be a bit surprising that suddenly tab A is
navigating
somewhere else, there is no security issue here, and users are not
endangered in any way---at least, not in any more danger than they
already
are from browsing the web without looking at their URL bar to see

where

they've ended up at.

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

If window.opener() did not work cross-domain then as far as I can tell 
that would be secure.


On 12/01/2016 07:23 PM, Richard Maher wrote:

I see what you're saying Michael and also agree it's serious. Would I be
correct in thinking that MS Edge solves the problem by not returning
window.opener cross-domain? Is the UA not a logical and uniform place for
this?

BTW I've also experienced the CitHub topic-closure nazis many times :-(


On Fri, Dec 2, 2016 at 10:42 AM, Michael A. Peters 
wrote:


Well if it was done as a header, I suppose it could be added as a
http-equiv meta tag for those who want to.

Header is the easiest solution to make sure it is applied everywhere
without question. It could even be added at the front-end proxy to cover
numerous web applications on many domains at once.

And I know this is conspiracy theory, but that's why I think there is such
resistance to it.

Since the flaw is required for OAuth to work, companies invested in OAuth
and that profit from OAuth solutions don't want sites behind proxies that
would break OAuth and don't want webmasters to understand they have to
reduce security in order to implement an OAuth solution.

That's just a suspicion of mine, but I can't think of any other logical
reason as to why a node attribute was chosen as the solution, and why there
is such resistance to doing it the right way with a header. To me it just
doesn't make sense.


On 12/01/2016 05:45 PM, Zac Spitzer wrote:


how about rather than requiring this on every  why not support a base
tag directive
for the whole document i.e. , similar to ?

On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola  wrote:

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian

Hickson

I believe that's a bit of an overstatement. There are certainly risks



involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.

This is the crucial point.

Whenever you are discussing a supposed security issue, you need to make
clear what the threat model is. That is:

- What would be the impact on the victim if the security hole is taken
advantage of?
- Is this something we are trying to prevent on the web platform?

In this case, the impact on the victim (a user of a web browser) is that
they could click a link from page A to page B, which opens in a new tab
(tab B). Then, tab A could be navigated to a new URL, instead of staying
on
page A.

This is not a big impact. Notably, page B is not able to read any of the
content of page A, which might be sensitive. Page B is not able to
interfere with the operation of any of page B's scripts. And crucially,
when page B navigates tab A to another page, the URL bar of tab A changes
to indicate that.

There is no desired security guarantee on the platform that we want to
prevent pages from directing users to "bad" sites. We count on users
inspecting the URL bar to understand what page they are interacting with
in
a given tab.

So, while it might be a bit surprising that suddenly tab A is navigating
somewhere else, there is no security issue here, and users are not
endangered in any way---at least, not in any more danger than they
already
are from browsing the web without looking at their URL bar to see where
they've ended up at.

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 12/01/2016 06:14 PM, Elliott Sprehn wrote:

On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky  wrote:


On 12/1/16 1:41 AM, Chris Holland wrote:


I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward from a logic standpoint  Whichever window was created
from this link can't control the parent.



It's a much stronger guarantee.  The guarantee is that the parent and the
created window have no way to see each other at all.  Neither one can read
any state from the other, or even know the other one exists.

In particular, the idea is that rel="noopener" allows the new window to be
opened in a separate process, or even a separate browser if desired. The
only difference between it and the user copying the link and then pasting
it into some other tab or other program is that a referrer header is sent.

Note that this guarantee makes for fairly simple implementation.

Having a header that opts in all links targeted at anything other than
_parent, _self, and _top have the noopener behavior would be doable. Having
a header that opts in some links based on the origin of the link href or
something would probably be doable.  Having a header that tries to add some
sort of new mode wherein the two windows _can_ see each other but can't do
some things that they can normally do would be a snake pit of complexity
that is best avoided.



I would like us to think about adding a mode where you get a MessageChannel
between the two windows. There's no synchronous access, and no ability to
navigate it, but you can talk back and forth with it.


I haven't tried but I don't see why service workers couldn't be used for 
that.

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

Well if it was done as a header, I suppose it could be added as a 
http-equiv meta tag for those who want to.


Header is the easiest solution to make sure it is applied everywhere 
without question. It could even be added at the front-end proxy to cover 
numerous web applications on many domains at once.


And I know this is conspiracy theory, but that's why I think there is 
such resistance to it.


Since the flaw is required for OAuth to work, companies invested in 
OAuth and that profit from OAuth solutions don't want sites behind 
proxies that would break OAuth and don't want webmasters to understand 
they have to reduce security in order to implement an OAuth solution.


That's just a suspicion of mine, but I can't think of any other logical 
reason as to why a node attribute was chosen as the solution, and why 
there is such resistance to doing it the right way with a header. To me 
it just doesn't make sense.


On 12/01/2016 05:45 PM, Zac Spitzer wrote:

how about rather than requiring this on every  why not support a base
tag directive
for the whole document i.e. , similar to ?

On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola  wrote:


From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian
Hickson


I believe that's a bit of an overstatement. There are certainly risks

involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.

This is the crucial point.

Whenever you are discussing a supposed security issue, you need to make
clear what the threat model is. That is:

- What would be the impact on the victim if the security hole is taken
advantage of?
- Is this something we are trying to prevent on the web platform?

In this case, the impact on the victim (a user of a web browser) is that
they could click a link from page A to page B, which opens in a new tab
(tab B). Then, tab A could be navigated to a new URL, instead of staying on
page A.

This is not a big impact. Notably, page B is not able to read any of the
content of page A, which might be sensitive. Page B is not able to
interfere with the operation of any of page B's scripts. And crucially,
when page B navigates tab A to another page, the URL bar of tab A changes
to indicate that.

There is no desired security guarantee on the platform that we want to
prevent pages from directing users to "bad" sites. We count on users
inspecting the URL bar to understand what page they are interacting with in
a given tab.

So, while it might be a bit surprising that suddenly tab A is navigating
somewhere else, there is no security issue here, and users are not
endangered in any way---at least, not in any more danger than they already
are from browsing the web without looking at their URL bar to see where
they've ended up at.

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 12/01/2016 05:39 PM, Domenic Denicola wrote:

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson


I believe that's a bit of an overstatement. There are certainly risks involved 
in window.opener (they're briefly discussed in the spec itself), but it doesn't 
remove the origin checks.


This is the crucial point.

Whenever you are discussing a supposed security issue, you need to make clear 
what the threat model is. That is:

- What would be the impact on the victim if the security hole is taken 
advantage of?
- Is this something we are trying to prevent on the web platform?

In this case, the impact on the victim (a user of a web browser) is that they 
could click a link from page A to page B, which opens in a new tab (tab B). 
Then, tab A could be navigated to a new URL, instead of staying on page A.

This is not a big impact.


It is a huge impact.

Scenario A) It can be used for protocol downgrade attack.

Site A has both https and http. JavaScript on site B reloads Site A as 
HTTP - so even though the user visited A as HTTPS, now they are at A as 
HTTP.


The user has no reason to suspect that the protocol changed, and on 
mobile devices the URL bar is often hidden.


Scenario B) User clicks on link to Site B. Site B puts up a fake page 
telling the user Google has blocked the site because of malware and asks 
them to close the window.


Meanwhile JavaScript changhed Site A to a phishing page that says 
Facebook (or whatever) detected a malicious cross site scripting, would 
they please login again to verify their identity.


The user was just at Site A and it was genuine, just experienced a 
warning they believed to be from Google that malware was attempted, and 
enters their username and password.


This is an extremely serious bug and I literally do not comprehend why I 
keep having to explain it.


Remember most users don't know the difference between JavaScript and 
Turbo Pascal.


The best encryption in the world doesn't protect users from social 
engineering attacks directly made possible by this kind of flaw.

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 11/30/2016 06:21 PM, Michael A. Peters wrote:

On 11/30/2016 05:23 PM, Ian Hickson wrote:

On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters

wrote:



Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.



I believe that's a bit of an overstatement. There are certainly risks
involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.




Actually it does. Site A can link to Site B on a completely different
domain and JavaScript on Site B has access to the window for Site A and
can change the URL and other things.



Here is easy demo showing the blatant cross-domain scripting vulnerability.



  
Test target link
  
  
https://bar.net/b.html"; target="_blank">link to 
different domain

  




  
Test window.opener

if (window.opener && !window.opener.closed)
  opener.location = '<a  rel="nofollow" href="http://www.example.org/">http://www.example.org/</a>'

  
  
The page on foo.com will have changed to http://www.example.org/ 
because this page had script access to that window. Obvious very serious 
phishing concern, and probably other concerns

  

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 11/30/2016 05:23 PM, Ian Hickson wrote:

On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters 
wrote:



Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.



I believe that's a bit of an overstatement. There are certainly risks
involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.




Actually it does. Site A can link to Site B on a completely different 
domain and JavaScript on Site B has access to the window for Site A and 
can change the URL and other things.





The reason they refuse to properly address the issue is because it would
break OAuth.



I'm not sure who "they" is here, but since this is the first this topic has
come up on this list, would you mind providing us with some background?


Yes, I apologize, this was written in frustration and I should have 
calmed down.


Browsers are implementing rel="noopener" as a fix. A wrong fix, I have 
never heard of an attribute on an element being used to define script 
security for a window but that's how it is being addressed.


It is a fix that is not ideal. Archived web pages won't have the fix, 
and anchors in web applications are created by many different processes 
and plugins - both when the page is served and via ajax after the page 
the served - sometimes by the main web application and sometimes by a 
plugin. It is simply not realistic to ask web applications to make sure 
each use of an anchor with a target attribute is accompanied by a 
rel="noopener" attribute in order to be secure.


People at browsers I spoke with said they can only implement what the 
WhatWG specifies, and the rel="noopener" is the specified solution.


So I went to the WhatWG github page, found an open issue on noopener and 
contributed my thoughts. Was told I was off topic, and not to derail it.


So I started a new issue asking to deprecate rel="noopener" and replace 
it instead with a header that websites who want to allow window.opener 
to modify them including a whitelist of domains that could use it.


The issue was very quickly closed without any discussion based upon the 
issue of backwards compatibility. That was more important that fixing 
the insecure spec.


When digging to try and find out what was so important, a link to 
another topic was given where it turns out OAuth is the application that 
makes heavy use of window.opener


So I then came up with a different suggestion, one that doesn't break 
backwards compatibility, but instead allows a webmaster to send a header 
specifying what domains (if any) to whitelist. No header and the current 
behavior would be retained, but it would allow sites to secure their 
pages from window.opener() without having to add a rel tag to every link 
- a simply .htaccess directive could serve the header.


Again with absolutely no discussion the issue was immediately closed by 
a Google employee (and I know Google is heavily invested in OAuth) 
claiming that CSP is the right place for that.


But as much as I personally love CSP, virtually every webmaster I have 
talked to who has tried it has abandoned it because it was too difficult 
for them to implement without problems that then take hours to figure 
out. It apparently can be particularly difficult to configure on 
WordPress sites or sites that use Google Adsense or Analytics.


So Content Security Policy isn't the right place.

It is very frustrating to have such a bad security flaw that is being 
kept around because OAuth depends upon the flaw and have any attempt to 
have the specification fixed in a sane reasonable way immediately closed 
on the WhatWG github page.


And I confess, I'm not exactly a people person as it is, but it just 
really felt like they didn't care about the issues and had absolutely no 
interest in a solution that makes the web safer for users.


That's the history.

Something needs to be done, relying upon websites adding rel="noopener" 
to every case of not realistic and even many websites that try will fail.


But a header can be adding in one line to a .htaccess file and served 
with every web page. It's the right solution, the secure solution.


Whether the header is required by sites that want to allow window.opener 
or required by sites that want to block it - I don't really care, but a 
header is the right solution and a rel tag is just so conceptually 
broken I don't know how that even was accepted.


Thank you for your time, I apologize for the tone of my earlier post.

[whatwg] WhatWG is broken

[Michael A. Peters]

https://www.w3.org/TR/html-design-principles/#priority-of-constituencies

3.2. Priority of Constituencies

In case of conflict, consider users over authors over implementors over 
specifiers over theoretical purity. In other words costs or difficulties 
to the user should be given more weight than costs to authors; which in 
turn should be given more weight than costs to implementors; which 
should be given more weight than costs to authors of the spec itself, 
which should be given more weight than those proposing changes for 
theoretical reasons alone. Of course, it is preferred to make things 
better for multiple constituencies at once.

3.3. Secure By Design

Ensure that features work with the security model of the web. 
Preferrably address security considerations directly in the specification.


Communicating between documents from different sites is useful, but an 
unrestricted version could put user data at risk. Cross-document 
messaging is designed to allow this without violating security constraints.


-=-=-=-=-=-=-=-

Right now the specification for window.opener() is seriously insecure, 
allowing for cross-domain script access by default.


WhatWG refuses to properly address the issue.

The reason they refuse to properly address the issue is because it would 
break OAuth.


Yup - an alleged security tool requires an insecure Internet. That's the 
most insane logic I have ever heard but that's what the issue is.


The proposed fix - rel="noopener" - is insufficient, it is difficult to 
consistently deploy and there are thousands upon thousands of archived 
web pages that won't have that attribute added.


It is unrealistic to expect the end user to be aware of the issue, the 
end user will be vulnerable to phishing and other attacks made possible 
via window.opener() if the browsers do not protect them, but the 
browsers will not protect them unless the specification calls for it, 
and the specification will not call for it because the same companies 
that are heavily invested in OAuth run the WhatWG.


There is a serious conflict of interest and it is resulting in a web 
that does not put the user first, or the security of the user first, but 
instead is putting first a protocol that has had repeated serious 
security flaws and is broken by design.


If the WhatWG can't put the security of Internet users first, then it 
needs to be disbanded and replaced by a working group that will put the 
security of the users first.

[whatwg] Push API and Endpoints

[Michael A. Peters]

I'm starting to play with Push API and it dawned on me -

The client retrieves the enpoint from the browser and sends it to the 
web application server.


The web application server then sends data to the endpoint, using the 
data provided by the client.


Is there any mechanism by which the application server can actually 
verify the endpoint domain actually is an endpoint domain and not some 
domain submitted by someone playing a prank?


I suppose we can whitelist known valid endpoint domains but it would be 
better if there was some official mechanism by which the client can 
verify that the notifications being sent to that domain are actually 
welcome.


Like maybe a DNS TXT record that can be fetched when the application 
server comes across a domain it hasn't verified before.

Re: [whatwg] possible new parameters to video.play() ?

[Michael A. Peters]

On 09/19/2016 07:41 AM, Simon Pieters wrote:



There is always room for adding convenience APIs, it's a matter of
demonstrating that it's a common enough need to make it worth the cost
of adding it.

https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94

HTH,


* OFF TOPIC *

Going off topic but an excellent example of what can happen when those 
things in the link aren't considered are the ramifications of adopting 
of Google's HPKP (RFC 7469)


* Even though TLS is used over a wide range of protocols, it is specific 
to one protocol - HTTP. The Internet is bigger than the web, a proper 
solution to a problem that exists across protocols isn't limited to just 
one protocol.


* It is blind trust on first use, which means the pins have to be cached 
for a relatively long time (to reduce window when that blind trust can 
be exploited)


* Thus you have to have at least one spare private key before deploying, 
so that its keypin can be cached by browsers as well.


* That spare private key can't be kept as the same place as the main key 
because if the main key is stolen via file access, the spare key will 
likely be compromised too.


* In addition to needing to keep the spare key in a separate place that 
is secure, it ties you in to specific technology because of the long 
cache life. Thus if your private key is compromised because of a zero 
day that only works on RSA keys you can't switch to ECDSA unless your 
spare key is already ECDSA.


* Puts you at the mercy of the browser vendors. What happens if you were 
using secp521r1 when Chrome decided to drop it? I hope people had backup 
keys that weren't secp521r1/


* If an employee leaves a company that potentially had access to private 
keys, it means you can't immediately rotate all the private keys to 
shiny new ones.


All those problems exist because it was implemented (initially in 
Chrome) without careful consideration. Rich companies like Google can do 
that. And it has hampered the adoption of a better technology (DANE) 
that doesn't have any of those issues.


So yes, adding new features really does require very careful thought.

* BACK ON TOPIC *

That being said, I like the attribute idea for audio and suspect it may 
have less accessibility issues than using JavaScript might have, notably 
it being easier for software to notify the user what the start and stop 
times are by reading them directly from the audio tag attributes.


So I like the idea.

Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?

[Michael A. Peters]

On 11/01/2016 03:32 AM, Roger Hågensen wrote:

On 2016-11-01 10:42, Roger Hågensen wrote:

I was wondering how can a server or script identify if a request is from
page, iframe or xhr?



I really hate answering myself (and so soon after making a post) but it
seems I have found the answer at
https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives


and the support is pretty good according to
http://caniuse.com/#feat=contentsecuritypolicy


But on MDN it says "For workers, non-compliant requests are treated as
fatal network errors by the user agent."
But does this apply to non-workers too?

And is there any way to prevent injected hostile scripts?
I guess loading scripts from a specific (whitelisted) url could do the
trick? Or maybe using strict-dynamic.

Darnit it. I may just have answered my own questions here.




Somewhere in the document (body, main, etc.) when a page is generated I 
include a data-csrf attribute that contains a single use token only good 
for the session id that requested the page (session id in the cookie)


Then any post submission, JS reads that token and adds it to the POST data.

In the case of Ajax submissions, the Ajax response includes a fresh 
token that then gets inserted into the data-csrf attribute for the next 
time the page sends a POST response.


My web apps usually put it in whatever element has the id of content so 
reading it via jQuery is as easy as


$("#content").attr("data-csrf");

Then with the json response, updating it to new token is as easy as

$("#content").attr("data-csrf", json.csrf);

It allows single use tokens and makes CSRF attacks virtually impossible 
as long as you have a proper crypto random string generator to create 
the new CSRF tokens so they can't be predicted.

Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?

[Michael A. Peters]

On 11/01/2016 02:42 AM, Roger Hågensen wrote:

I was wondering how can a server or script identify if a request is from
page, iframe or xhr?

Doing this would not prevent any XSS attacks, but it would allow a
server/server-side script to detect a potential XSS attack.

I could not find any mention of any reliable way to do this currently.

Here is an example of this idea, when the browser fetches the page the
server sends this as a response header to the browser...

RRS: *

or

RRS: url

or

RRS: iframe

or

RRS: script

And when the browser do a POST it will send one of these (if the server
sent a RRS header) ...



Any server admin that trusts a header sent by a client for security 
purposes is a fool. They lie, and any browser extension or plugin can 
influence what headers are sent and what they contain.


The only thing you really can do with POST is set a single use CSRF 
token that the browser must include with the POST data.


If the browser does not send the token or sends an incorrect/expired 
token for the session ID then the server rejects the post (I send a 403 
forbidden)

Re: [whatwg] JavaScript Hovers and Back Button

[Michael A. Peters]

Last one I found is already taken down (I always report it to the ISP - 
often Amazon cloud)


What it does is make loud buzzing noises while flashing a message that 
your computer has been infected with a virus and you must call microsoft 
support immediately.


Only thing that works is closing the tab or quitting the browser.



On 04/13/2016 12:54 PM, Jonathan Zuckerman wrote:

I have heard of a lot of abuses but never actually come across this
particular one, can you point us to a site that demonstrates it?

On Wed, Apr 13, 2016 at 3:53 PM, Michael A. Peters 
wrote:


This btw is a security issue. Many of the scam sites that do things like
tell the user their computer is infected and they have to call a number
disable the ability to use the back button via JavaScript hovers.

This puts users who don't understand technology into a mental state where
they feel like they have no control.

It's effing stupid that anyone ever thought it was a good idea to let
JavaScript disable the standard browser controls. As browsers have done
that, it needs to be specified that JavaScript can't do that.


On 04/13/2016 12:44 PM, Michael A. Peters wrote:


It needs to be made very clear as a web standard that no JavaScript
action can disable UI functions such as the back button.

A very common abuse is that when pulling the mouse to hit the back
button because you are not interested in a page, a hover comes up and
when the hover comes up, the back button no longer works.

This is a browser UI issue but it needs to specified that browsers must
not disable the back button in response to JavaScript. The web is enough
of a cesspool as it is.

Re: [whatwg] JavaScript Hovers and Back Button

[Michael A. Peters]

This btw is a security issue. Many of the scam sites that do things like 
tell the user their computer is infected and they have to call a number 
disable the ability to use the back button via JavaScript hovers.


This puts users who don't understand technology into a mental state 
where they feel like they have no control.


It's effing stupid that anyone ever thought it was a good idea to let 
JavaScript disable the standard browser controls. As browsers have done 
that, it needs to be specified that JavaScript can't do that.


On 04/13/2016 12:44 PM, Michael A. Peters wrote:

It needs to be made very clear as a web standard that no JavaScript
action can disable UI functions such as the back button.

A very common abuse is that when pulling the mouse to hit the back
button because you are not interested in a page, a hover comes up and
when the hover comes up, the back button no longer works.

This is a browser UI issue but it needs to specified that browsers must
not disable the back button in response to JavaScript. The web is enough
of a cesspool as it is.

[whatwg] JavaScript Hovers and Back Button

[Michael A. Peters]

It needs to be made very clear as a web standard that no JavaScript 
action can disable UI functions such as the back button.


A very common abuse is that when pulling the mouse to hit the back 
button because you are not interested in a page, a hover comes up and 
when the hover comes up, the back button no longer works.


This is a browser UI issue but it needs to specified that browsers must 
not disable the back button in response to JavaScript. The web is enough 
of a cesspool as it is.

Re: [whatwg] HTML6 proposal for single-page apps without Javascript

[Michael A. Peters]

On 04/02/2015 04:08 AM, Andrea Rendine wrote:


Well, this means that we must also simplify CSS, don't you think
so? all that stuff about media queries, about animation and transitions,
pseudo-elements, pseudo-classes, how can poor Tumblr users learn
that?


Oh god yes, I like CSS selectors but the rest of CSS I personally have a 
hard time wrapping my head around - I'm guessing CSS was designed by 
people who have a completely different thinking style than I do.


I have no problem getting LaTeX to do what I want but CSS - I have 
struggled with it for literally 15 years.


I want to see CSS re-written from the ground up.

But that's going off topic ;)

Re: [whatwg] HTML6 proposal for single-page apps without Javascript

[Michael A. Peters]

On 03/27/2015 06:51 PM, Miles Fidelman wrote:


I've been reading through the discussion thread, all of which seems to
jump immediately into the weeds of specific details of the proposal.

I'm amazed that nobody has yet commented on the implicit premise, which
I read as:
- JavaScript is a processing pig
- with the addition of a few, well-defined constructs to HTML, with
support from browsers, we could do a lot of what we want (or what people
are doing) - without the overhead imposed by JavaScript

To me, this seems like a very good thing.  It seems like:

- It's getting harder and harder to do simple things.  Too many
JavaScript frameworks and libraries.  Too much complexity. Authoring
should not require extensive programming skills. (Whatever happened to
the read/write web?).

- JavaScript seems to encourage poor programming style, or at least
resource-intensive programming.  It seems like 2/3 of the web pages I
visit either freeze up, or just take incredibly long to load. Granted,
that a lot of this is this stems from all the little click monitoring
apps, and widgets, and who knows what else people put on their pages -
and waiting for those various sites to respond - but it's the
proliferation of more and more JavaScript that enables this.


In HTML5 some functionality ordinarily provided by JavaScript that now 
can be done by HTML5, e.g. the details tag and progress tag, is still 
not universally supported by modern browsers requiring JavaScript fallback.


I don't know why it takes the browsers so long to implement, but it does.

The problem with JavaScript is that fewer and fewer web devs care. 
Rather than picking a framework (like jQuery) and sticking with it, they 
copypasta JS they find around the web (often in violation of the 
license) and add whatever framework that snippet depends upon.


Few people care about passing their JS through tools like JSLint, and 
many pages still have dozens of external JS references as well as 
numerous inline scripts.


They just don't care. And that is hard to fix with standards because 
they don't care.

Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github

[Michael A. Peters]

On 03/25/2015 12:39 AM, Janusz Majnert wrote:



OK. This makes no sense for me.

So you propose that the server does simple translation of SQL from url
to actual query, but you don't see any security issue with this?
If on the other hand you're proposing that the server validates the sql
sent by client, then the simplest (and proven) solution is to have an
API entry point that does the query that your client wants without any
sql in the urls.


Yes I have to agree with that, input needs to be validated on the server 
and preferably bound to a prepared statement, and that is something 
easiest to do with post/get variables that server side languages already 
are equipped to do w/o exposing table / column structure - and easily 
allows for different caching engines to be used as needed to reduce load 
on the SQL server.

Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github

[Michael A. Peters]

On 03/24/2015 04:50 PM, Michael A. Peters wrote:

I see JavaScript as a useful tool that is seriously abused by many devs, I'm 
against this. But if you do it, make damn sure it has proper CSP support.


I would like to clarify that when I say I am against this, I am not 
opposed to the function being there for those who would find it useful.


I can be overly critical, I am not opposed to this being part of a 
future HTML for those who do want it, especially if it makes it easier 
for this kind of web design to be done in an accessible way.

Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github

[Michael A. Peters]

I see JavaScript as a useful tool that is seriously abused by many devs, I'm 
against this. But if you do it, make damn sure it has proper CSP support.

On March 24, 2015 2:18:53 AM PDT, Bobby Mozumder  
wrote:
>https://github.com/mozumder/HTML6
>
>I’ll be updating that Github with more ideas and refinement about the
>proposal with occasional feedback into this list.  Since this is
>getting some attention it’s probably better to place the ideas in a
>setting that can be updated/modified than to discuss it informally via
>email over here.  This is still at the concept phase and I’ll be
>looking at feedback from other people as well as other frameworks to
>see the good they offered as well as what caused them to fail.  
>
>In this version, a key change is that I added an MREF property to 
>elements to separate the canonical URL from an API URL, and a RECEIVER
>property to specify where the API data loads:
>
>   http://www.mywebsite.com/article-2.html";
>mref=“http://api.mywebsite.com/article-2"; receiver="MyArticleData">
>
>The MREF will maintain backwards compatibility.  You can use the same
>web page in an older browser and it operates fine, it just won’t load
>API endpoints, but will reload full page from the HREF.  And previously
>I had a MODEL property in place of RECEIVER, but that's the overall
>model’s outlet for all elements, not a receiver model, which can be
>different.  Adding a MODEL property would load the model’s properties
>into the HREF and/or  element.
>
>I also changed the fixtures in the example from XML to JSON.  I always
>thought XML was more readable when mixed with HTML, but it looks like
>people prefer reading JSON?
>
>Meanwhile, it looks like the people most into Javascript are against
>this, and the people that prefer to avoid Javascript like this. 
>
>I get that most people here are in the “Javascript everywhere!” camp
>but there definitely is a large class of people out there that prefer
>to minimize their use of Javascript whenever possible and just want to
>deal with the declarative HTML system.  These are content managers, and
>Javascript components are largely in the UI design domain, not the
>content domain that many web developers are coming from. How many UI
>design experts are out there?  And how many of them like working with
>Javascript, instead of Swift or something else?  You’re competing
>against that.
>
>Also I feel you shouldn’t have to prototype new HTML elements as
>Javascript components to advance HTML.  That’s a huge barrier to its
>development, as now you need to do that first.  Very few people will do
>so for a standards body.  The components they make are going to be very
>specific to their needs.  Plus, browser makers aren’t going to write
>them, so you just forced them to wait for someone else to design these
>components first, when they already know the problems their users are
>experiencing and can fix them already.  And if your site can do it with
>a custom component then why bother putting it into the standard?
>
>Finally, aren’t people already doing this sort of prototyping anyways
>with the Javascript frameworks?  At a high-level, they’re all basically
>prototyping an entire MVC use model, with just implementation
>differences between them.  Isn’t that enough to cause HTML to be
>updated to fit this MVC design pattern?  It’s a basic issue in the
>design of the web.
>
>-bobby
>---
>Bobby Mozumder
>Editor-in-Chief
>FutureClaw Magazine
>mozum...@futureclaw.com 
>+1-240-745-5287
>www.futureclaw.com 
>twitter.com/futureclaw 
>www.linkedin.com/in/mozumder 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [whatwg] HTML6 proposal for single-page apps without Javascript

[Michael A. Peters]

On 03/20/2015 02:10 AM, Bobby Mozumder wrote:

There’s a standard design pattern emerging via all the front-end javascript 
frameworks where content is loaded dynamically via JSON APIs.  This is the 
single-page app web design pattern. Everyone’s into it because the 
responsiveness is so much better than loading a full page - 10-50ms with a 
clean API load vs. 300-1500ms for a full HTML page load.


*snip*

Not everyone is into it. I hate it. For many reasons.

Only place I like it is for feeds, like Tumblr, and even there is can be 
really problematic sometimes.


Web devs can keep using it, free world, but calling it HTML6 would be 
absurd. HTML should not embrace particular design choices.


My two cents.

Re: [whatwg] URI scheme whitelisting and the case of cryptocurrencies

[Michael A. Peters]

On 03/07/2015 03:40 PM, Michael A. Peters wrote:





Especially crypto-currencies where even on Linux systems, the client is
often not under a package management system control and may be out of date.

QR codes pose the same problem but it is more difficult to trick a user
into scanning a QR code, so it is harder to get the user's client to
launch via a trick.


Another thing to consider, most crypto-currencies use the same Qt client 
codebase - so it is easy for a web site to specify a price in one 
crypto-currency but use the URI scheme for a different one, and some 
users may not realize the wrong client launched until it is too late and 
can't be undone.


e.g. `Please donate 3 QRK - that's all I ask'

but 3 bitcoins are sent before the user realize it was bitcoin-qt that 
the link launched.

Re: [whatwg] URI scheme whitelisting and the case of cryptocurrencies

[Michael A. Peters]

On 03/07/2015 11:50 AM, Krzysztof Jurewicz wrote:
*snip*


What are your thoughts about that? Are there any security considerations
preventing the whitelist solution? Or maybe a more general one should be
worked out?



I do not allow bitcoin: on my servers, nor anything except for http, 
https, or ftp.


The reason is because I have no way of knowing what third party 
applications might have vulnerabilities (including social engineering) 
that could be exploited by a specially crafted URI string being fed to them.


I don't even allow mailto:

I'm a big supporter of bitcoin but especially for a financial 
application where it can't be undone once confirmed in the blockchain, I 
just personally think it is too dangerous to even allow bitcoin: URIs on 
a web page.


I prefer the user launch the third party application and enter whatever 
parameters they want to enter into the client than a link that does 
things for them, including possibly some things they don't necessarily 
understand is happening.


Especially crypto-currencies where even on Linux systems, the client is 
often not under a package management system control and may be out of date.


QR codes pose the same problem but it is more difficult to trick a user 
into scanning a QR code, so it is harder to get the user's client to 
launch via a trick.

Re: [whatwg] scrap the srcset attribute

[Michael A. Peters]

On 03/02/2015 09:47 AM, Tab Atkins Jr. wrote:



This is much easier to write and to maintain


Is it really?

With a simple key=value pair, I can:

$src = trim($node->getAttribute('src');

Then I can check it - if it is relative, I can change it to reference 
the cdn. If it is not local, I can check to make the domain is valid, 
check the domain is not in our black list, etc. and then replace the src 
node with the cleaned version.


With srcset - I can still do that but then becomes more complex as there 
is an initial array that then has to be exploded into secondary arrays 
etc. and more complicated code is more prone to bugs.


What happens if one of the sources has a typo involving a space, e.g.

Big Image.jpg 2x

instead of

Big%20Image 2x

With key=value that's easy to fix, but it is more complicated when a 
space is a delimiter in an array that is a sub-array.


key=value is kiss and kiss has a lot of benefits.

[whatwg] scrap the srcset attribute

[Michael A. Peters]

Dear WHATWG,

Scrap the srcset attribute.

Traditionally in HTML, and in every instance of XML I have personally 
worked with, an element's attribute is a key=value pair.
Okay the type attribute for source node in audio and video, sometimes it 
has codecs specified there too - but that's the only example I can think 
of, and even there, it is rarely actually used. Usually it is just 
simply used as a key=value pair with the mime type, even by me and I 
know how to specify the codec.


But srcset is a multi-level array. The first array is a , delimited 
string - and each element between the commas is itself a space delimited 
array.


When has that kind of attribute ever been previously used in HTML ??
I suppose the type attribute with audio and video where you can 
optionally specify codec, but that's all I can think of, and there it 
isn't multi-dimensional.


srcset is a mistake. A mistake that will result in errors on the web 
because it is much more difficult to understand than the traditional 
key=value pair that is traditional in HTML and XML.


key='multi level array of values' is just plain conceptually wrong.

-=-

Secondly, you are doing the source child of the picture element wrong.

Who the hell am I to tell you that you are doing it wrong?

I'm a user that thinks what you currently have is over-complicated and 
ridiculous.


When in the history of HTML has an element's legal attributes been 
dependant upon what the parent element is?


I can't think of a case until the picture element.

The picture element should have the source element as a child, and this 
is how it should be done:


[picture]
  [source src="ImageHD.webp" type="image/webp" media="(min-width: 
1024px)" /]
  [source src="ImageHD.jpg"  type="image/jpeg" media="(min-width: 
1024px)" /]
  [source src="ImageHD.webp" type="image/webp" media="(min-width: 
800px)" res="2x" /]
  [source src="ImageHD.jpg"  type="image/jpeg" media="(min-width: 
800px)" res="2x" /]
  [source src="Image.webp"   type="image/webp" media="(min-width: 
800px)" /]
  [source src="Image.jpg type="image/jpg"  media="(min-width: 
800px)" /]

  [source src="Image.webp"   type="image/webp" res="2x" /]
  [source src="Image.jpg"type="image/jpg"  res="2x" /]
  [source src="ImageMobile.webp" type="image/webp" /]
  [source src="ImageMobile.jpg"  type="image/jpg"  /]
  [img src="Image.jpg" alt="[cow patty in field]" /]
[/picture]

The client selects the first image where it matches all type, media 
query, and resolution attributes that are specified.


Notice that it keeps the simple to understand key=value pair for the 
attributes, and it keeps compatability with source tag as it has already 
been used with audio and video for years now.

Re: [whatwg] "resize" events on elements

[Michael A. Peters]

On 02/23/2015 05:40 PM, Dean Jackson wrote:

At the recent Houdini meeting there was a vague agreement between the browser 
engines on adding a way for elements to be notified when their size changes. 
We've run into a number of scenarios where this is extremely useful, and is 
otherwise difficult or annoying (e.g. checking your size on a timer).

The idea was to allow the resize event on elements. I don't really care what 
the solution is, so maybe someone here can come up with a better idea (size 
observers?). And of course there are a lot of details to be worked out.

If we settle on a solution fairly soon I will implement it in WebKit nightly 
builds so people can play.

Dean



Yes, I desperately need this!

Right now I have to try to trigger off of a bunch of things that can 
change the size of the parent (e.g. a details node opening or closing) - 
it would be much easier to just have a resize event on the parent node 
itself.

Re: [whatwg] Obsolete Feature [hgroup]

[Michael A. Peters]

On 02/17/2015 03:15 PM, Barry Smith wrote:

*snip*

As far as validation, a document with the hgroup element will not pass when 
using the W3C Markup Validation Service.

>
> *snip*


Thank You For Your Time,
Barry Smith



WHATWG is not W3C

W3C dropped the ball (imho) and HTML became stagnant under them, WHATWG 
picked the ball up and rolled with it, creating HTML5.


W3C has since adopted HTML5 which I believe was the right thing for them 
to do, but not *everything* that was in WHATWG's proposal.


I prefer to use the adopted W3C specification for production as I 
consider it to be a relatively stable target to develop for.


Thus I have stopped using hgroup.

That's just my opinion on the matter.

[whatwg] HTML Microdata

[Michael A. Peters]

Hello,

I never personally paid much attention to microdata before.
However I am coding a CMS and so I have to look at it.

I am having trouble understanding why this isn't at least optionally 
applicable via an external file using CSS selectors.


For example, a web page could have

<link type="foo/xml" src="microdata.xml" />

microdata.xml then has rules to apply microdata information based upon 
CSS selectors in the document, similar to how XSL works.


That seems to make a lot more sense to me than creating new HTML 
attributes, and it is obvious enough of a concept that surely I can't be 
the first person to have thought of it.


All the examples I looked at of microdata could easily be done that way, 
and it has a lot of advantages:


A) You can use the same microdata.xml file for many pages, allowing it 
to be cached, reducing bandwidth.


B) Many CMS systems store content separate from the template, and could 
have the microdata link tag added to the head node by the template when 
served, so the pages don't need to all be altered to make use of it.


C) It looks like microdata is mostly useful to bots and crawlers, but 
most traffic to a web site is not bots and crawlers, so why not have it 
as an external resource the few clients that want the info can grab.


D) Conceptually, it looks to me like it really is no different than CSS 
- it applies a style to content. A style for machines to better 
understand the content, not a visual style, but still a style - so why 
not use existing CSS selectors that already work well with XML tools?


E) It would allow the microdata to be applied to any type of XML document.

F) It would allow changing the schema(s) used in the future w/o needing 
to modify the content, making maintenance easier.


Is there a reason it has to be embedded in the HTML itself and is not 
available as an external file that can be referenced?


I tried to think of one and couldn't.

-=-

Thank you for your time, and I really hope that an update to 
microformats will allow them to be defined external via CSS selectors, 
because as far as I can tell, that is the right way to implement this 
type of thing. It should at least be an option.


Michael A. Peters