Re: [whatwg] Site-Wide Heading Element

[Jonathan Zuckerman]

 On Jun 23, 2015, at 22:57, Mark Simon m...@manngo.net wrote:
 
 (This is my first post here, so I’m not sure about appropriate protocols).
 
 HTML5 adds more power to the heading elements, which is a good thing. 
 However, there appears to be no recommended element for marking up a 
 site-wide banner title.
 
 Presumably, the correct element is h1 for the banner heading, but this may be 
 at odds with the notion that h1 should describe the specific page. The banner 
 title would be expected to be the same for most, if not all, pages, while the 
 h1 might be expected to be different for each page.
 
 While we should not pay too much heed to the whims of search engines, there 
 is the notion that varying the h1 in pages is good for SEO. For this reason 
 many site owners and developers are reluctant to use the main h1 as a banner 
 title.
 
 As far as I am aware, there is no suitable HTML(5) element for a site-wide 
 heading. I would like to see the introduction of such an element. Here are 
 some suggestions:
 
 * The purpose of the element is to provide a semantically appropriate
   container for a site-wide title.
 *  From a behavioural point of view, it would be similar to an h1
   element. That is, a block element with mostly text.
 * There would be no other special default appearance, much like a
   paragraph. CSS can handle the rest.
 * There should only be one such element on a page, in the body
   element. It may be nested inside another suitable element, such as a
   header.
 
 I have no strong opinion on the name of the element. Some suggestions are: 
 title, banner, name, sitename, site, elementwithoutanyothername.
 
 -- 
 
 
 Mark Simon
 
 Manngo Net Pty Ltd
 
 mobile:0411 246 672
 
 email:m...@manngo.net mailto:m...@comparity.net
 web:http://www.manngo.net
 
 Resume:http://mark.manngo.net
 

What would be the value of such an element? There is an aria-role for banner 
I believe..

Re: [whatwg] Site-Wide Heading Element

[Jonathan Zuckerman]

I agree that the title/banner/logo element doesn't add much value. I don't
feel like a tag to canonically declare the website name would add much
value either - isn't that what the domain is for? Also the tag wouldn't be
very trustworthy - the domain is less easy to lie about.

On Wed, Jul 1, 2015 at 4:24 PM, Pontus Horn af Rantzien 
pontus.h...@gmail.com wrote:

 I don't see too much value in having a special element for the website
 title/logo/branding as shown in-page.

 I *can* see some value in canonically defining the website name inside
 head, e.g. for accessibility purposes. Let's say you navigate to a site
 you're not familiar with via search results, a link, etc. You skip to the
 content as that's what you're interested in, but you like the content and
 want to find out the name of the website. To my knowledge, there's no go-to
 place for that information. It might be part of the title or an h1, but
 both of those elements relate more to the page than the larger site.

 To me it'd make sense to define such an element as a companion to title.
 Many authors currently lump the website name and the page title together in
 an arbitrary format inside title. Having a separate element for the
 website name would serve to discourage that, and would let user agents
 present the two pieces of information in a consistent and predictable way.

 Regards,
 Pontus

 On Tue, 30 Jun 2015 at 12:46 Delfi Ramirez del...@segonquart.net wrote:

 
 
  logo sounds nice to me.
 
  As far as we move onto standarized browsers and mobile devices as the
  way we connect to the web, the proposed logo could be equal to the
  reference or representation shown in _svg=icon _or_ link-rel=ico_
 
  Just thinking.
 
  ---
 
  Delfi Ramirez
 
  My digital signature [1]
 
  +34 633 589231
   del...@segonquart.net [2]
 
  twitter: delfinramirez
 
   IRC: segonquart Skype: segonquart [3]
 
  http://segonquart.net [4]
 
  http://delfiramirez.info
   [5]
 
  On 2015-06-30 11:48, Martin Janecke wrote:
 
   On 30.06.15 03:18, Garrett Smith wrote:
   On 6/29/15, Barry Smith bearzt...@live.com wrote: From: Garrett
  Smith dhtmlkitc...@gmail.com Hey Garrett, My apologizes for not
  replying until now. When I posted my reply to the Site-Wide Heading
  Element thread, you were right and I should have posted a more complete
  example. Here is what I should have given as an example: header
  id=banner script src=scripts/header.js
  type=text/javascript/script noscript div class=styledText div
  class=letterMM/div div class=wordy/div /div div
  class=styledText div class=letterWW/div div
 class=wordeb/div
  /div div class=styledText div class=letterSS/div div
  class=wordite/div /div /noscript /header Using the div
 element
  for purely stylistic purposes. Placing them within the noscript element
  displays the exact same header as is in the embedded script element,
 but
  without the additional animation used in the javascript file. I would use
  an H1 with text-transform
   :
  capitalize and avoid using divs and javascript.
 
  I agree with avoiding JavaScript. I am not sure about text-transform,
  because I don't know which styling the author had in mind. He may want
  to color every word's first letter differently.
 
  div is actually a neutral block element. The neutral inline
  element span would seem like the better choice to wrap letters or
  single words in the example. But you could wrap the whole line into one
  div.
 
  I would not use h1 because My Website is neither a heading for the
  content of the page (unless maybe on the front page or a sitemap) nor
  for a section of the page. It could be intended as a title for the whole
  website, i.e. all its pages together, or as some kind of logo or
  branding. I don't think we have a dedicated element for either of these
  interpretations.
 
  Let's assume we would introduce a new element with the meaning title
  for the entirety of pages of a website. How would this be interpreted,
  if such an element is used with different content on different pages of
  the same website? I think such an element would cause inconsistencies
  all the time. It isn't a good idea.
 
  Let's assume we would introduce a new element with the meaning logo,
  branding. What would its benefits be compared to div? And would
  authors still want to use it if add-blockers get a little more
  aggressive and offer the option to block logos?
 
  Martin
 
 
 
  Links:
  --
  [1] http://delfiramirez.info/public/dr_public_key.asc
  [2] mail:%20del...@segonquart.net
  [3] skype:segonquart
  [4] http://segonquart.net
  [5] http://delfiramirez.info
 



On Wed, Jul 1, 2015 at 4:24 PM, Pontus Horn af Rantzien 
pontus.h...@gmail.com wrote:

 I don't see too much value in having a special element for the website
 title/logo/branding as shown in-page.

 I *can* see some value in canonically defining the website name inside
 head, e.g. for accessibility purposes. Let's say you navigate to a site
 you're not familiar with via 

Re: [whatwg] JavaScript Hovers and Back Button

[Jonathan Zuckerman]

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] [proposal] Gallery element

[Jonathan Zuckerman]

Hi Hans, I'm not an important figure at all in the web world, but my
intuition is this isn't a good candidate for a new feature in HTML. You've
done a good job of abstracting the problem and exploring the edge cases but
the feature is just too specific.

I doubt browser vendors would want to implement it. As you stated, " the
conventions for displaying a list of images are very different for
practically every platform". Any browser that operates on different
platforms (the most popular one operates on practically every platform
there is) would have a difficult job indeed of making it function
intuitively in all situations.

I doubt site owners would want to use it. Most sites have a very distinct
visual style and falling back to the platform's design patterns might not
fit with that.

On Wed, Jul 13, 2016 at 8:12 AM, Hans Schmucker  wrote:

> Note: I've already sent this to the W3C public-html list, and while there
> hasn't
> been any response so far, it is possible that issues will be raised on both
> channels. The original message along with replies is available at
> http://lists.w3.org/Archives/Public/public-html/2016Jul/0011.html .
> Although
> I'll do my best to transport raised issues between both lists.
> Right now this is little more than a description of a problem with a rough
> outline how a solution could work, so there are obviously a lot of issues
> not
> discussed in this proposal. What I'd like to discuss is whether this has
> any
> place in the HTML specification at all. My personal opinion is that it
> would
> lend meaning to something that today is mostly tag-soup, but your opinion
> may
> differ and that's what I'm most interested in hearing about.
>
> IF there is consensus that this IS worth investigating, then I'd gladly
> help
> write up a few proposals and sample implementations.
>
> Maybe I’m overlooking something, but I’m currently writing another JS
> gallery
> (there are some special requirements, but that’s beside the point) and
> there’s
> one thing that bothers me: There really is no way to write a perfect
> gallery for
> all platforms, for the simple reason that the conventions for displaying a
> list
> of images are very different for practically every platform.
>
> Desktop users are used to menu-less thumbnail overviews with lightboxes for
> full-size images, because zooming is not a huge priority. Mobile users
> prefer
> full-screen images without any controls, but with appropriate gestures in
> place.
> The specifics (like how annotations are presented, which options are
> present and
> which animations are expected) even differ between OS versions.
>
> All that combined with the simple fact that there simply is no way to mark
> up a
> gallery correctly at this time, while the web is exploding with graphics,
> makes
> me think that we should consider adding gallery element.
>
> A gallery should be a _a series of related pictures which have a combined
> topic,
> as well as an individual message._
>
> Its content (one figure per item) should be shown to the user in a way
> which is
> _appropriate for the platform_, allowing him to _navigate among the
> figures_
> (giving an overview first and allowing him to drill down) as well as
> showing the
> content in a way which allows him to _inspect all its aspects_ (i.e.
> zooming).
>
> A full-screen gallery would be best from a user’s perspective, but webpages
> would have big reservations about their gallery being displayed outside the
> context of their page. So the gallery element should NOT function as a
> link to a
> full-screen application, but like a normal block element, displaying the
> gallery
> overview in the specified area (along with appropriate controls).
>
> The user agent may choose an appropriate size for the individual pictures,
> without any limitations. A _content attribute_ may be given to allow for
> appropriate presentation. Values may (for example) include photo, icon,
> art..
>
> Each picture may have a title, which the user agent must show along with
> each
> image. The description on the other hand should be shown only when an
> image is
> inspected individually. The user agent may hide the caption after a brief
> period, but it must initially be visible.
>
> Example:
> My photos
> 
> 
> 
> A beautiful night
> 
> 
> 
> OK, so it’s slightly blurry
> 
> 
>
>
> A user agent may also provide appropriate actions for each image, for
> example
> download, share, print and so on. A gallery may indicate that its content
> is
> protected by specifying protected="true", in which case the user agent
> should
> restrict the use to pure viewing (however, actual protection is not
> required,
> the presence of protected="true" merely indicates the intended use).
>
> Galleries may also be nested. If a gallery element contains another
> gallery, the
> first picture element is meant to describe the gallery as a whole. The user
> agent is free to show 

Re: [whatwg] Media query for bandwidth ??

[Jonathan Zuckerman]

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

Re: [whatwg] window.innerScreenX and window.innerScreenY

[Jonathan Zuckerman]

Jan, does window.screenX/screenY not meet your needs?
https://developer.mozilla.org/en-US/docs/Web/API/Window/screenX
https://developer.mozilla.org/en-US/docs/Web/API/Window/screenY


On Tue, Dec 13, 2016 at 8:30 AM Jan Norden  wrote:

> There is currently no good way of translation a position in a browser to a
> position on the screen. Our particular need is translating a gaze-position
> (which we have in screen coordinates from our eyetracking hardware).
>
> It is possible in Firefox, using the proprietary
> mozInnerScreenX/mozInnerScreenY, but not in general.
>
> One of the comments in
> https://bugs.chromium.org/p/chromium/issues/detail?id=151983 seems to
> indicate that the correct course of action is to raise the issue here, so I
> will just post this and see where it leads.
>
> --
> /Jan Norden
>

Re: [whatwg] window.innerScreenX and window.innerScreenY

[Jonathan Zuckerman]

Ah right.. would it be possible to compute the missing dimensions given a
mouse event with screenX/Y and clientX/Y properties?

On Tue, Dec 13, 2016 at 9:03 AM Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 12/13/16 8:46 AM, Jonathan Zuckerman wrote:
> > Jan, does window.screenX/screenY not meet your needs?
> > https://developer.mozilla.org/en-US/docs/Web/API/Window/screenX
> > https://developer.mozilla.org/en-US/docs/Web/API/Window/screenY
>
> That doesn't work because it gives the screen position of the top/left
> edge of the browser window, not of the content are the web page is
> rendered into.  So if you have a screen coordinate and you want to
> translate it into page-relative coordinates, this won't do what you
> want: you'll be off by the size of the window decorations and the
> browser chrome.
>
> -Boris
>

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

[Jonathan Zuckerman]

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 >>> target="_blank">?

 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] Accessing local files with JavaScript portably and securely

[Jonathan Zuckerman]

The solution most developers use is to run a simple web server that hosts
static content, it's a much simpler solution than the API you propose and
requires no changes to the spec. It doesn't address the CD-ROM use case,
though..
On Sun, Apr 9, 2017 at 06:11 Melvin Carvalho 
wrote:

> On 9 April 2017 at 11:51, David Kendal  wrote:
>
> > Moin,
> >
> > Over the last few years there has been a gradual downgrading of support
> > in browsers for running pages from the file: protocol. Most browsers now
> > have restrictions on the ability of JavaScript in such pages to access
> > other files.
> >
> > Both Firefox and Chrome seem to have removed this support from XHR, and
> > there appears to be no support at all for Fetching local files from
> > other local files. This is an understandable security restriction, but
> > there is no viable replacement at present.
> >
> > This is a shame because there are many possible uses for local static
> > files accessing other local static files: the one I have in mind is
> > shipping static files on CD-ROM or USB stick, but there is also the more
> > obvious (and probably more common) use of local files by developers
> > prototyping their apps before deploying them live to an HTTP server.
> >
> > This is an inconvenience to many web developers, and I'm far from the
> > only one to complain about it. For instance, this from a very prolific
> > reporter of Chrome bugs:
> >
> > > I've filed hundreds of Chrome bugs and I would rather would see this
> > > fixed than any of them
> >
> > in . That
> > bug was the number two most starred Blink bug in 2016.
> >
>
> Thanks for the pointer, I just starred this too.  I am currently hitting a
> wall with this issue as well.
>
> I have looked for a way to override this, but cannot find something.  As a
> consequence, I have switched to electron, which seems to have this feature.
>
>
> >
> > I'd like to see APIs that solve this problem securely, in a way that's
> > portable across all browsers. I know this isn't trendy or sexy but
> > 'single-page apps' are still in vogue (I think?) and it would be
> > useful/cool to be able to run them locally, even only for development
> > purposes.
> >
> >
> > A proposed solution, though far from the only one possible:
> >
> > There should be a new API something like this:
> >
> > window.requestFilesystemPermission(requestedOrigin);
> >
> > which does something like
> >
> > - If permission was already granted for the specified requestedOrigin or
> >   some parent directory of it, return true.
> >
> > - If the current page origin is not a URL on the file: protocol, raise a
> >   permissions error.
> >
> > - If requestedOrigin does not share a root path with the current page
> >   origin, raise a permissions error. That is, a file with the name
> >   file:///mnt/html/index.html can request access to file:///mnt or to
> >   file:///mnt/html, but *not* to file:///etc, where it could read the
> >   local password file.
> >
> > - The browser displays an alert to the page user showing the name and
> >   path to the directory which has requested this permission. The user
> >   can then choose to allow or deny access.
> >
> > - If the user chose not to allow access to the files, false is returned
> >   or some other error is raised.
> >
> > - If they chose to allow access, return true.
> >
> > - For the remainder of the session (user agent specific), all files
> >   in the requestedOrigin directory, including the current page, have
> >   total read access (with Fetch, XHR, etc.) to all other files in
> >   the directory.
> >
> > requestedOrigin is allowed to be an absolute or relative URI.
> >
> > Some useful Fetch semantics for file: URLs should also be defined.
> >
> > I like this solution because it maintains portability of scripts between
> > HTTP(S) and local files without too much extra programming work: if
> > scripts only request relative URLs, they can both (a) detect that
> > they're running locally from file: URLs, and request permission if so
> > and (b) detect that they're running on HTTP, and make exactly the same
> > API calls as they would on the local system.
> >
> > This is also a beneficial property for those using file:// URLs for
> > development purposes.
> >
> > Of course, this is just one solution that's possible. I would welcome
> > feedback on this proposal and any progress towards any solution to this
> > very common problem.
> >
>
> +1 looks like a good solution.  Another way would be to set a flag in the
> options.
>
>
> >
> >
> > Thanks,
> >
> > --
> > dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
> ><+grr> for security reasons I've switched to files:// urls instead
> >
> >
>

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

[Jonathan Zuckerman]

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

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

On Mon, Jul 24, 2017 at 7:21 PM Michael A. Peters <mpet...@domblogger.net>
wrote:

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

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

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

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

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

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


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

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

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

[Jonathan Zuckerman]

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

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

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

> On 25 July 2017 at 17:32, Michael A. Peters 
> wrote:
>
> > Nor does his assumption that I am "new" to the web somehow disqualify me
> > from making suggestions with current use cases that could reduce the
> bloat
> > of traffic.
> >
>
> Oh, then I think you misunderstood his statement. As I read it, "spend more
> time working with the web you have before trying to change it" was a
> suggestion to look for a way to do what you want with current technology,
> not an argument that you don't have enough web experience. "Spend more
> time" on this particular project, not in general.
>

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

[Jonathan Zuckerman]

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

[Jonathan Zuckerman]

I agree that reducing the bloat of JSON-LD is a noble goal. Sorry to
belabor this point, but can you explain why JSON-LD is needed in the first
place? I've tried to point out that HTML is capable of doing it without
another spec, which obviates the need for content duplication and bloat
that JSON-LD introduces (and the extra headers you are suggesting). To your
other example, CSS media queries can be employed by authors to respect user
preferences for reduced motion or other visual features. This makes a lot
of sense because it colocates those rules in the place where the
problematic feature would be defined in the first place. Why should a
problem introduced by CSS be fixed by some other technology?

What I'm saying is that there are alternatives to JSON-LD which are
superior and (this is crucial) already supported globally. I'm confident
that we can expand the scenarios endlessly and still not come across one
where JSON-LD accomplishes something HTML couldn't already do better. Can
you explain why you are such a fan of JSON-LD? I'm open minded, I'm ready
to be convinced, but I feel like I've suggested obviously superior
alternatives to each of the use cases you've presented (if I missed any,
please remind me and I'll be happy to circle back) I was honestly quite
ambivalent about JSON-LD when this discussion started but I'm convinced now
that it's a bad direction for the web.

In case you haven't seen it, schema.org suggests an approach to structured
data that works with HTML instead of sidestepping it. Google provides
a Structured
Data Testing Tool 
so you can be sure that the search engine is interpreting the cues
correctly.

Ok so, I think I've made clear my opinion of JSON-LD ;) taking a big step
back, no action can be taken by the WHATWG about the new header because
those are defined (a quick web search reveals) by the IANA and IETF. The
header you suggest can be implemented at any time by website owners, you
just need to bring this up with the search engines so their bots start
sending the appropriate header. If you can get search engines on board (or
convince enough site owners to only return JSON-LD when the appropriate
request header is present so the search engines are forced to send it) then
your job will be done.


On Tue, Jul 25, 2017 at 18:41 Michael A. Peters 
wrote:

> On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
> > On 25 July 2017 at 17:32, Michael A. Peters 
> wrote:
> >
> >> Nor does his assumption that I am "new" to the web somehow disqualify me
> >> from making suggestions with current use cases that could reduce the
> bloat
> >> of traffic.
> >>
> >
> > Oh, then I think you misunderstood his statement. As I read it, "spend
> more
> > time working with the web you have before trying to change it" was a
> > suggestion to look for a way to do what you want with current technology,
> > not an argument that you don't have enough web experience. "Spend more
> > time" on this particular project, not in general.
> >
>
> I have a way to do what I want with current technology.
>
> I can detect bots based upon user agent and only send the JSON-LD when I
> do so.
>
> However there are some things that may be of use to a browser with
> accessibility functions, such as declarations regarding whether or not a
> page (or resource on a page) has flashing content or has simulated
> motion. So there are legitimate reasons why an end user client may want
> the JSON-LD data before rendering a page.
>
> Just like the accept header for WebP, an accept header for JSON-LD could
> solve this problem. Bots and non-bot users agents that want it send it.
> Webmasters who understand people in undeveloped countries benefit from
> non-bloated paged can then choose to only send the JSON-LD in their
> pages when it is wanted.
>
> Much better to implement this now when JSON-LD is still relatively young.
>
> Whether JSON-LD is the best way to add structured data to a page
> probably depends upon a lot of different factors, that's a different
> discussion. But it is being used. That's the discussion, reducing the
> drawbacks of bloated content for clients that ignore it anyway.
>

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

[Jonathan Zuckerman]

After reading just a bit more - it seems like JSON-LD and schema.org have
slightly different goals - schema.org suggests conventions for data cues in
HTML, JSON-LD suggests it for JSON (e.g. API responses for dynamic
websites) - exactly how "best practice" is this pattern of stuffing JSON-LD
into the script tag of an HTML document? Most of the articles I could find
on the subject come from Google, not the JSON-LD community...

On Wed, Jul 26, 2017 at 8:30 AM Mark Kaplun <m...@marksw.com> wrote:

> hmmm http://blog.schema.org/2013/06/schemaorg-and-json-ld.html
>
> If you use a CMS like wordpress for your content, and you are just a
> content person, it is a big meh to try to add manually the attributes, and
> it is also a meh to develop software that will need to parse the content to
> add it as you might break the structure required for the proper functioning
> of CSS and JS. You can have all kinds of "macros" for that, but the result
> is unreadable content on the editing side.
>
> Whatever are the cons of disconnecting the data from the content, it is
> probably more likely that you will have the data, or at least it will be
> more complete if you can use json-ld as it is easier to manage.
>
> On Wed, Jul 26, 2017 at 3:11 PM, Jonathan Zuckerman <j.zucker...@gmail.com
> > wrote:
>
>> I agree that reducing the bloat of JSON-LD is a noble goal. Sorry to
>> belabor this point, but can you explain why JSON-LD is needed in the first
>> place? I've tried to point out that HTML is capable of doing it without
>> another spec, which obviates the need for content duplication and bloat
>> that JSON-LD introduces (and the extra headers you are suggesting). To
>> your
>> other example, CSS media queries can be employed by authors to respect
>> user
>> preferences for reduced motion or other visual features. This makes a lot
>> of sense because it colocates those rules in the place where the
>> problematic feature would be defined in the first place. Why should a
>> problem introduced by CSS be fixed by some other technology?
>>
>> What I'm saying is that there are alternatives to JSON-LD which are
>> superior and (this is crucial) already supported globally. I'm confident
>> that we can expand the scenarios endlessly and still not come across one
>> where JSON-LD accomplishes something HTML couldn't already do better. Can
>> you explain why you are such a fan of JSON-LD? I'm open minded, I'm ready
>> to be convinced, but I feel like I've suggested obviously superior
>> alternatives to each of the use cases you've presented (if I missed any,
>> please remind me and I'll be happy to circle back) I was honestly quite
>> ambivalent about JSON-LD when this discussion started but I'm convinced
>> now
>> that it's a bad direction for the web.
>>
>> In case you haven't seen it, schema.org suggests an approach to
>> structured
>> data that works with HTML instead of sidestepping it. Google provides
>> a Structured
>>
> Data Testing Tool <https://search.google.com/structured-data/testing-tool>
>
>
>> so you can be sure that the search engine is interpreting the cues
>> correctly.
>>
>> Ok so, I think I've made clear my opinion of JSON-LD ;) taking a big step
>> back, no action can be taken by the WHATWG about the new header because
>> those are defined (a quick web search reveals) by the IANA and IETF. The
>> header you suggest can be implemented at any time by website owners, you
>> just need to bring this up with the search engines so their bots start
>> sending the appropriate header. If you can get search engines on board (or
>> convince enough site owners to only return JSON-LD when the appropriate
>> request header is present so the search engines are forced to send it)
>> then
>> your job will be done.
>>
>>
>> On Tue, Jul 25, 2017 at 18:41 Michael A. Peters <mpet...@domblogger.net>
>> wrote:
>>
>> > On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
>> > > On 25 July 2017 at 17:32, Michael A. Peters <mpet...@domblogger.net>
>> > wrote:
>> > >
>> > >> Nor does his assumption that I am "new" to the web somehow
>> disqualify me
>> > >> from making suggestions with current use cases that could reduce the
>> > bloat
>> > >> of traffic.
>> > >>
>> > >
>> > > Oh, then I think you misunderstood his statement. As I read it, "spend
>> > more
>> > > time working with the web you have before trying to change it" was a
>> > > suggestion to look for a way to d

[whatwg] readonly attribute

[Jonathan Zuckerman]

I have a question about this section in the spec:

Only text controls can be made read-only, since for other controls (such as
checkboxes and buttons) there is no useful distinction between being
read-only and being disabled, so the readonly
 attribute does not apply
.

https://html.spec.whatwg.org/#the-readonly-attribute

This doesn't quite jive with my understanding of the distinction between
`readonly` and `disabled` - to me, "readonly" and "disabled" controls can
both not be edited by the user, but "readonly" means that the value will be
included in the payload when the form is submitted, whereas "disabled"
means that the value will not be included. It seems like this distinction
does apply to `button`, `checkbox`, and `select` as well as for `input`.

I discovered this while working on set of forms to POST and PATCH entities,
The designs call for me to pre-set certain attributes in the POST form and
not allow the user to edit them, but they should still be sent in the
request (readonly), and to display them in the PATCH form (helps provide
context) but not to send them in the request (disabled). I could solve this
other ways (using hidden inputs, creating elements that look like inputs
but are not actually, or displaying the context in some other way without
including those fields in the form), but I'm just wondering - is the
documentation unclear/incorrect, or am I misunderstanding something?

One other related question - it seems like select inputs are always matched
by the `:read-only` selector in CSS, but the `readOnly` property in
Javascript is always `undefined` - the inconsistency there makes me think
that something is not right...  https://jsfiddle.net/jrz/yt1c3ee7/

Re: [whatwg] HTML inputs directly toggling CSS classes on elements?

[Jonathan Zuckerman]

class names are meant to be a tiny wormhole which connects the worlds of
content (HTML), presentation (CSS), and behavior (JS)  - I think this
suggestion begins to widen that rip, and it's inadvisable. It's a question
of taste I guess, just which behaviors are primitive enough to not require
javascript.

As you've proven, this idea is easily implemented in Javascript. If you
were to get an incredible rate of adoption for that script, it might
indicate that there is widespread demand for this feature, and you'd be
able to make a case that it's worth implementing in the browser.

On Sun, Sep 10, 2017 at 7:25 AM Roger Hågensen 
wrote:

> On 2017-09-09 18:41, Alex Vincent wrote:
> > A few days ago, I dipped my toes into web design again for the first time
> > in a while.  One of the results is the CSSClassToggleHandler constructor
> > from [1].  Basically, it takes an radio button or checkbox, and turns
> that
> > input into a toggle for a CSS class on another element.
>
> You do have :checked
>
> While I haven't used that with radio or checkboxes much myself it seems
> to at least partially do what you are describing.
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/:checked
>
>
>
>
> --
> Unless specified otherwise, anything I write publicly is considered
> Public Domain (CC0). My opinions are my own unless specified otherwise.
> Roger Hågensen,
> Freelancer, Norway.
>

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Jonathan Zuckerman]

>From my own experience, only about half of the times I’ve required debounce
or throttle has been related to event handling, so if your proposal was
accepted I’d still need to include a library to satisfy the other scenarios.
On Tue, Nov 28, 2017 at 00:01 Sylon Zero <sylonz...@gmail.com> wrote:

> I think libraries having those functions emphasizes the point here, as
> that validates the existence and need for those patterns which then raises
> the requirement: should this be native to the browser?
>
> I believe the answer is yes, given how much work has already been put into
> standardizing the resource/computation model around the browser (web
> workers, local storage, etc) which is architecturally, IMHO, a related
> effort. Those capabilities come to life when there are smarter ways to
> utilize and route work to them through built-in features related to
> processing events/messages. In an effort to not create a science project
> out of some sort of top-down attack on this requirement, a simple
> middle-out approach with immediate results would be to extend the
> eventListener behavior that is prevalent in both browser and node.js
> scenarios.
>
> The case I am making first and foremost is that these recognizable
> patterns will be increasingly requisite (and not an after-thought, to be
> brought in via Underscore) in building web apps in the near term as web app
> complexity & use has increased dramatically with multiple cloud-scale
> offerings running in the SaaS space (think Netflix, LinkedIn, Facebook,
> Slack, etc) and more being built in various startups & emerging
> businesses. If the browser is to gain parity as an Application Platform
> allowing the development of web applications to rival native ones, then the
> ability to deal with volatile/durable messaging and events, storage and
> routing of work should be a core capability.
>
> *Broader implications:*
> If I may, let me add that I also think there is a growing confluence
> between the hybrid desktop app and browser-based SPAs (the Electron
> framework and its numerous successful projects like Atom, Slack, Visual
> Studio Code are great examples) and if the browser is to continue to evolve
> as a platform to encourage this trend (which is fabulous for the web
> community), then investments must be made to extend / normalize the browser
> standards in much the same way that the concept of a standardized
> Application Server helped standardize app architectures. This implies a
> future with registration of libraries/components (managed code), better
> local storage/caching options, improved integration with security contexts
> (per O/S), and likely much more. At least, I think it does :-).
>
>
> On Mon, Nov 27, 2017 at 6:48 PM, Jonathan Zuckerman <j.zucker...@gmail.com
> > wrote:
>
>> You’re probably aware there are libraries that offer functionality of
>> this sort (debounce and throttle in underscore/lodash is the one I’m most
>> familiar with) and the web community seems content to add a small
>> dependency when such functionality is required. How would you convince
>> browser vendors to implement this?
>> On Mon, Nov 27, 2017 at 18:05 Sylon Zero <sylonz...@gmail.com> wrote:
>>
>>> *Core Problem Statement* Processor functions that subscribe to events
>>> via a
>>> topic string may need to be prioritized for processing based on the topic
>>> itself. Conversely, certain events may be more numerous but should not
>>> limit the ability of the JS environment to respond and process other
>>> events, that may be more critical to either the User Experience (UX) or
>>> integrity of the system (e.g. events that trigger saving data to a
>>> back-end).
>>>
>>> *Background Information* As Browser/CommonJS environments bring paradigms
>>> like UI event handling and back-end event handling into the same problem
>>> space, it is useful to apply common patterns used in Message-based
>>> Publish-Subscribe environments with message brokers, which is what the JS
>>> execution context often behaves as. The use case here is to ensure that
>>> one
>>> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t
>>> saturate
>>> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due
>>> to
>>> massive differences in event volume or conversely, expensive operations
>>> that block the execution thread in question.
>>>
>>> *Proposed Solution* Add metering options to the addEventListener
>>> *Options* configuration
>>> object. These options control how the JS execution environment controls
>>> the
>>> t

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Jonathan Zuckerman]

You’re probably aware there are libraries that offer functionality of this
sort (debounce and throttle in underscore/lodash is the one I’m most
familiar with) and the web community seems content to add a small
dependency when such functionality is required. How would you convince
browser vendors to implement this?
On Mon, Nov 27, 2017 at 18:05 Sylon Zero  wrote:

> *Core Problem Statement* Processor functions that subscribe to events via a
> topic string may need to be prioritized for processing based on the topic
> itself. Conversely, certain events may be more numerous but should not
> limit the ability of the JS environment to respond and process other
> events, that may be more critical to either the User Experience (UX) or
> integrity of the system (e.g. events that trigger saving data to a
> back-end).
>
> *Background Information* As Browser/CommonJS environments bring paradigms
> like UI event handling and back-end event handling into the same problem
> space, it is useful to apply common patterns used in Message-based
> Publish-Subscribe environments with message brokers, which is what the JS
> execution context often behaves as. The use case here is to ensure that one
> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
> massive differences in event volume or conversely, expensive operations
> that block the execution thread in question.
>
> *Proposed Solution* Add metering options to the addEventListener
> *Options* configuration
> object. These options control how the JS execution environment controls the
> throttling/firing of event handler instances in response to events that
> match the topic string of the subscription created by addEventListener.
>
> Proposed options:
>
>- maxInstances [Number / Function] used to decide how many event
>listeners can be invoked before throttling occurs. Throttling does not
> lose
>events but simply queues them.
>- throttlingQueueLength [Number] used to maintain an in-memory queue of
>un-processed events per Topic string, after throttling kicks in.
>- throttlingQueuePolicy [String] Values could be exception - throws an
>exception when the queue length is exceeded, rolling - drops the oldest
>events and pushes newer ones into the queue, expand- allow the queue to
>expand to cover all events.
>
> *Additional Options* It might be even more useful if the options allowed
> targeting or creation of Web Workers (or Node child processes, depending on
> the execution context) based on the event handler configuration. This could
> potentially target CPU cores and/or O/S child processes / threads
> (depending on the O/S terminology for parallel execution).
>
> *Related Thread* The proposal identified in the link below (by Šime
> Vidas) could
> be part of this solution as it defines other metering options around
> debounce (which improves scale around event handling, which is in the same
> problem space) and handling throttling through frequency, which should be
> one of the alternatives in addition to my proposal above (as I believe they
> are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
> g-and-debouncing-to-addeventlisteneroptions/2436/19
>
> Sai Prakash
> @SylonZero
>

Re: [whatwg] Security: emphasize that subdomain is not enough for user provided scriptable content

[Jonathan Zuckerman]

These domains are used specifically because they are reserved for that use
- https://www.iana.org/domains/reserved

If a non-reserved domain is used, it could be bought up by anyone and have
its content changed to something not appropriate for linking from official
spec documents.

The note is technically correct, but perhaps it could be written
differently to more clearly point out the necessity of a different TLD?

On Tue, Aug 28, 2018 at 8:33 AM Mikko Rantalainen <
mikko.rantalai...@peda.net> wrote:

> The page
>
>https://html.spec.whatwg.org/dev/iframe-embed-object.html
>
> contains an example that has "usercontent.example.net" instead of e.g.
> "video.example.com" used in the same chapter. It does have a warning
> saying
>
> > It is important to use a separate domain so that if the attacker
> > convinces the user to visit that page directly, the page doesn't run
> > in the context of the site's origin, which would make the user
> > vulnerable to any attack found in the page.
>
> but I think this should specifically mention that using a subdomain is
> not enough because JavaScript can lift any domain restrictions if only
> the subdomain is different. This difference may not be immediately
> obvious to casual reader especially because both examples also have
> different subdomains which is easier to notice.
>
> I'm not sure how wording should be put because technically
> "example.com." is subdomain of "com." top level domain. And we have
> stuff such as "co.uk.", which makes things even hairier.
>
> I guess that the spec would like to use .example.* domains in all the
> examples but perhaps one could use something more explicit such as
>
> https://example-usercontent.com/...
>
> for this example in addition to being more explicit about subdomains in
> the warning. That would prevent even casual reader from mixing
> a.example.com and b.example-usercontent.com.
>
> --
> Mikko
>