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

[Yay295]

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

[Yay295]

Maybe a solution then would be to provide a way to request more storage
space?

On Wed, Apr 19, 2017 at 1:35 PM, Joshua Bell  wrote:

> On Wed, Apr 19, 2017 at 8:23 AM, Roger Hågensen 
> wrote:
>
> > On 2017-04-19 11:28, Anne van Kesteren wrote:
> >
> >> I already pointed to https://wicg.github.io/entries-api/ as a way to
> >> get access to a directory of files and  as a way to
> >> get access to a sequence of files. Both for read access. I haven't
> >> seen any interest to go beyond that.
> >>
> >
> > Is this the Filesystem & FileWriter API ?
> >
>
> A small subset of the functionality specified in FileSystem was used by
> Chrome to expose directory upload. Support for that subset necessary for
> interop of directory upload has been implemented by Firefox and Edge. I put
> up the entries-api spec to try and re-specify just that subset. (It's a
> work in progress.)
>
>
> > This was added to Chrome/Opera under the webkit prefix 7 years ago, Edge
> > and Firefox has not picked this up yet (just the Reader part).
> > (as shown by http://caniuse.com/#search=file )
> >
>
> The market apparently demonstrates that a sandboxed file system storage API
> isn't high priority for browser vendors to implement.
>
>
> >
> > I avoid prefixed features, and try to use only features that latest
> > Edge/Chrome/Firefox support so that end users are more likely to not end
> up
> > in a situation where their browser do not support a app.
> >
> > And unless I remember wrong Firefox did support this at some point then
> > removed it again.
> >
> >
> > Take for example my soundbank app.
> >
> > A end user would want to either use a file selector or drag'n'drop to the
> > app (browser) window to add files to the soundboard.
> >
> > Let us assume that 30+ sounds are added (I don't even think the
> > filerequester handles multiselection properly in all browsers today)
> >
> > Would it be fair to expect the user to have to re-add these each time
> they
> > start/open the app? During a week that is a lot of pointless work.
> > Saving filenames is not practical, and even if it was there would be no
> > paths.
> >
> > And storing the sounds in IndexDB or localStorage is out of the question
> > as that is limited to a total of 5MB or even less in most browsers, 30+
> > samples easily consumes that.
> >
>
> You may want to check again. An origin typically gets an order of magnitude
> more storage than that for Indexed DB across browsers and devices.
>
> >
> > The ideal here is to make a html soundboard app locally (i.e file://)
> then
> > copy it as is to a webserver. Users can either use it from there (http://
> > or https:// online and/or offline) or "Save As" the document and use it
> > locally (file://) for preservation or offline use without server
> dependency.
> >
> > The only way to make this work currently is to make the user hand write
> > the path (full or relative) to each sound and store that in localStorage
> > along with volume and fade in/out.
> > But fade in and out is "faked" by adjusting the  volume as CORS
> > prevents processing the audio and doing a proper crossfade between sounds
> > which is possible but locked down due to CORS.
> >
> > I can understand limitations due to security concerns, but arbitrary
> > limitations to functionality baffles me.
> >
> > I do not see much difference between file:// http(s):// besides one
> > allowing serverside data processing and http headers, but these days most
> > apps are entirely clientside. A sample editor can be written that is
> fully
> > clientside, even including mic recording normalizing, FX, the server is
> not
> > involved in any stage except delivering the .html file + a few lines of
> > headers. The web app itself is identical (i.e. hash/checksum identical)
> be
> > it http(s): or file:
> >
> > The benefit is that "the app is the source code" which is a ideal goal of
> > open source as anyone can review and copy and modify as they please.
> > And in theory it could run just as well truly offline/standalone as it
> > could online without the need for a local webserver or similar.
> >
> > I'd dare say that thinking of a web app as something hosted only from a
> > server via http(s) is a antiquated idea.
> > These days a "web" app can be hosted via anything, want to open a webapp
> > that is served from a cloud storage like Dropbox? Not a problem.
> > Well, almost not a problem. a cloud storage probably do not have the
> > proper CORS header to allow a sample editor to process sound from local
> > files or files stored on a different cloud service.
> >
> > And a soundboard or a sample editor is just two examples, a image or
> video
> > edit would have similar issues. OR what about a game with mod support?
> > Being able to drag'n'drop a mod onto a game and then have the game load
> it
> > the next time you start the game would be a huge benefit.
> > But currently this can not be done, the mod would have to be uploaded to
> 

Re: [whatwg] Media query for bandwidth ??

[Yay295]

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;
> >}
> >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] possible new parameters to video.play() ?

[Yay295]

You can add an event listener to the video element on the `timeupdate`
event and pause the video when the videos' time is at/past the time you
want to stop, but your idea does sound more convenient.

On Sat, Sep 17, 2016 at 5:21 PM, Melvin Carvalho 
wrote:

> Apologies if this has come up before, but I was wondering if it would be
> possible to add simple parameters to the play() function.
>
> They would be
>
> play(start, end)
>
> Where start and end are the times in seconds.
>
> I know you can do
>
> video.currentTime = start ; video.play()
>
> But there's no real easy way to stop it to play a clip
>
> The media fragments URIs spec [1] handles this quite nicely by adding to
> the URI
>
> #t=start,end
>
> But yet there seems to be no way to do this in JS, resorting to changing
> location.hash and then doing a reload, which seems a bit of a kludge
>
> I may be missing something extremely obvious, if so, I'd love to know!
>
> [1] https://www.w3.org/TR/media-frags/
>

Re: [whatwg] JavaScript Hovers and Back Button

[Yay295]

*Windows*
IE11, Chrome: Navigation buttons are blocked while modal dialog is shown.
Firefox: Navigation buttons remain usable.

On Thu, Apr 14, 2016 at 8:34 AM, Majid Valipour 
wrote:

> > 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.
>
> Does 'hover' refer to modal dialog e.g., window.alert?
> That is the only way I know that you can block a user to click back button.
> Here is a simple page that does this: http://jsbin.com/fuwosaxefa
>
> That behavior is a side-effect of how a browser may decide to implement
> modal dialog which is dependent also on the OS. I tested a few browsers on
> Linux & Mac and this is what I found:
>
> *Mac*
> Firefox, Chrome, Safari: Navigation buttons are usable while modal dialog
> is shown.
> *Linux*
> Chrome: Navigation buttons are block while modal dialog is shown.
> Firefox: Navigation buttons remain usable.
> *Windows*
> 
>
> Perhaps this is worth a non-normative note in the spec in "user-prompt"
> section [1]
>
> [1] https://html.spec.whatwg.org/multipage/webappapis.html#user-prompts
>
> Majid
>
> On Thu, Apr 14, 2016 at 4:38 AM Delfi Ramirez 
> wrote:
>
> > Agree.
> >
> > May it be done within the History API spec?
> >
> > Just wondering.
> >
> > ---
> >
> > Delfi Ramirez
> >
> > My digital signature [1]
> >
> > +34 633 589231
> >  del...@segonquart.net [2]
> >
> > twitter: delfinramirez
> >
> >  IRC: segonquart Skype: segonquart [3]
> >
> > http://segonquart.net
> >
> > http://delfiramirez.info
> >  [4]
> >
> > On 2016-04-13 21:44, 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.
> >
> >
> > Links:
> > --
> > [1] http://delfiramirez.info/public/dr_public_key.asc
> > [2] mail:%20del...@segonquart.net
> > [3] skype:segonquart
> > [4] http://delfiramirez.info
> >
>

Re: [whatwg] VIDEO and pitchAdjustment

[Yay295]

On Tue, Sep 1, 2015 at 11:30 AM, David Singer  wrote:

> > On Sep 1, 2015, at 4:03 , Robert O'Callahan 
> wrote:
> >> On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks 
> wrote:
> >> QuickTime supports full variable speed playback and has done for well
> over
> >> a decade. With bidirectionally predicted frames you need a fair few
> buffers
> >> anyway, so generalising to full variable wait is easier than posters
> above
> >> claim - you need to work a GOP at a time, but memory buffering isn't the
> >> big issue these days.
> >
> > "GOP”?
>
> Group of Pictures.  Video-speak for the run between random access points.
>
> > How about a hard but realistic (IMHO) case: 4K video (4096 x 2160), 25
> fps,
> > keyframe every 10s. Storing all those frames takes 250 x 4096 x 2160 x 2
> > bytes = 4.32 GiB. Reading back those frames would kill performance so
> that
> > all has to stay in VRAM. I respectfully deny that in such a case, memory
> > buffering "isn't a big issue”.
>
> well, 10s is a pretty long random access interval.
>

There's no way to know the distance between keyframes though. The video
could technically have only one keyframe and still work as a video.


> >> What QuickTime got right was having a ToC approach to video so being
> able
> >> to seek rapidly was possible without thrashing , whereas the stream
> >> oriented approaches we are stuck with no wean knowing which bit of the
> file
> >> to read to get the previous GOP is the hard part.
> >
> > I don't understand. Can you explain this in more detail?
>
> The movie file structure (and hence MP4) has a table-of-contents approach
> to file structure; each frame has its timestamps, file location, size, and
> keyframe-nature stored in compact tables in the head of the file. This
> makes trick modes and so on easier; you’re not reading the actual video to
> seek for a keyframe, and so on.
>

I suppose the browser could generate this data the first time it reads
through the video. It would use a lot less memory. Though that sounds like
a problem for the browsers to solve, not the standard.

Re: [whatwg] VIDEO and pitchAdjustment

[Yay295]

On Fri, Aug 28, 2015 at 12:17 PM, Domenic Denicola d...@domenic.me wrote:

 From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert
 O'Callahan
  According to the spec it should work, but it's very low priority for us
 and
  implementing it would be very inefficient as Yay295 describes. So I don't
  think it's going to happen in Firefox in the forseeable future.

 I was looking in to this yesterday and it seems like the spec places
 absolute no limits on playbackRate. Am I right? This seems a bit bad.

 If nobody is supporting negative nor has any plans to, we should at least
 consider throwing for negative. I guess we can leave the upper limit
 unspecified, unless implementations all happen to agree on one.


playbackRate should also probably be set to 0 when the video is paused,
seeing as they accomplish the same task. Or better yet redefine pause() to
be setting playbackRate to 0. You would of course then have to keep a note
of what the playbackRate was before pause() was called, but it would fix
the issue of playbackRate being set to zero, yet video.paused returning
false. So video.pause() would save the current playbackRate and then set
playbackRate to 0, and video.play() would restore the playbackRate saved by
pause(). video.paused could then just return (playbackRate ? false : true).

Re: [whatwg] VIDEO and pitchAdjustment

[Yay295]

On Thu, Aug 27, 2015 at 12:02 PM, Garrett Smith dhtmlkitc...@gmail.com
wrote:

 Negative playbackRate, to watch videos backwards, currently crashes
 Safari 8; Firefox 40 says not implemented. I think it would be
 entertaining for example, to watch things like cars uncrashing. Should
 this work? And if so, shouldn't audio match the video speed for
 backwards playing? I think yes, and yes.


It would be much easier to re-encode the videos in reverse and provide two
versions of the video. Videos are made to be played in one direction, and
they use this assumption to improve their compression efficiency.
Basically, videos have two different types of frames; let's call them Full
frames and Partial frames. A Full frame contains all of the information
that a stand-alone image would have. If a video had only a single Full
frame, it would be able to display that image and show it for the length of
the video (incidentally, this is what a WebP image is). Partial frames, on
the other hand, do NOT have enough information to produce a full image.
They merely contain the information representing the difference between the
previous frame and the current frame. This obviously saves a lot of space
if the frames are similar. A video will contain a mixture of Full frames
and Partial frames, with many more Partial frames than Full frames (ex. 1
Full frame followed by 10 seconds of Partial frames (~240 partial frames)).
What this means is that when you play a video in the proper direction, it
must first decode a Full frame, but then it only has to decode Partial
frames (until the next Full frame). However, if you try to play a video in
reverse, it must decode a Full frame and ALL of the Partial frames up to
the current frame before it can display the current frame. To display the
frame before that, it must decode all of those frames again, and so on for
every frame of the video. You could of course store the decoded frames in
memory, but that will take a lot of space. 240 uncompressed frames at 720p
is over half a gigabyte of information. It's just not practical.