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

[Jonathan Garbee]

Is there a problem with using 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 
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.
>

Re: [whatwg] Media query for bandwidth ??

[Jonathan Garbee]

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

[Jonathan Garbee]

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

[Jonathan Garbee]

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

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

[Jonathan Garbee]

 > You’re making this more complicated than it needs to be. Simplify the
problem domain.

I think we can all agree, we don't want another App Cache on our hands for
a standard. Sorry you feel an idea can be thrown out, immediately accepted
and pushed through simply because it seems obvious. In the real world,
things aren't always boiled down to the simplest solutions. Sometimes, we
need to have a bit of complexity and extra overhead in setting something up
to make sure it is robust and effective in as many situations as possible.

As has been said before, build a polyfill to show off your idea. I don't
think many vendors want to spend time building this out in-browser to test
when it is easily done in existing JS to get the idea down. We also need to
stop thinking purely about how things were built two years ago. ES6 and Web
Components introduce a lot of ground-breaking changes in this area, we
should see how they play out with framework vendors before jumping into
throwing it all into HTML and hoping it works well.

> So saying this is a “hard problem” just reeks of Javascript developer
laziness

This sounds very disrespectful. You're telling the people who are, writing
the standards, paying attention to give input to new standards and
modifying existing ones that they are lazy. They do this for a reason, most
have been bitten by some poorly thought out standard. This could end up
just another one. This kind of response does not encourage people to
continue to have a conversation on the proposal with you.

On Mon, Mar 30, 2015 at 9:08 AM, Andrea Rendine <
master.skywalker...@gmail.com> wrote:

> Bobby, the major criticism you have received about your proposal is that
> you aren't considering at all any other party involved in this subject.
> Correct me if I'm wrong, you cite no user agent responsible for support,
> nor working groups or anything loosely resembling to that.
> You are providing a very useful insight on how *you* see the web. And you
> also provide a feedback based on the experience of high-school Tumblr girls
> (why should she learn how to use Angular? However, there's nothing bad if
> she learns something new).
>
> The fact is, your proposal cannot be labeled as HTML6 Web needs something
> new. And however your last messages do show that the proposal itself is not
> strictly related to read/write Web as you claim. In fact, the main reasons
> you cite behind your proposal are responsiveness and full-page reload
> latency. Which are real problems, for sure, but not in the sense of
> read/write, they're rather a matter of UX. A relative matter which does not
> make the Web "largely unusable", and if you have doubt about it just have a
> look at ChromeExperiments and see what can be done with current poor
> methods.
>
> If what you need is localised content load, you have some features you can
> use as of now. For example, you can use nested browsing contexts, which
> also offer a layer of protection in the form of CORS restrictions,
> sandboxing and MIME type declaration.
>
> You want to get rid of these things? Use XHR, its support is native. As you
> said, you are not against JS itself, but against "writing more Javascript
> than necessary". If you have the means, push towards a more pervasive
> standardisation of current JS implementation, so that there will be
> decreasing need for polyfills and syntax standardisers (with your proposal,
> there'd be a need for a polyfill as well until it doesn't become supported
> on new UA versions *and* new UA versions completely or substantially
> replace legacy versions).
>
> You still want more? Don't focus on changing a web page content. HTML is
> still a declarative language after all, and there's nothing bad with it.
> It's the purpose which originated it. Of course there's more now, but the
> examples of websites or web apps you cited don't generally change the
> content of a page, they integrate it, adding more items to the page as time
> passes and events happen. So, as I said some messages ago, why not focusing
> on ? It can add new elements to the existing document, it's HTML5
> so you will have no chance of proposing "your" language, but you can still
> work fairly well with it and with its margins for improvement. Current spec
> suggests how to use it with a JS framework, why don't you elaborate a
> proposal where  is able to load and parse "its" own
> content-to-be"? (Of course you can even imagine loading a page which is
> initially empty, with just a declaration for a template, which adds content
> at runtime. But it is different from altering current content, a kind of
> operation that no web designer would desire to be natively executed).
>
> And finally, consider that JS complexity and JS memory load are 2 different
> aspects you will have to face with a brand-new language or featureset:
>  - complexity deals with richness of use cases. When dealing with external
> content load you have to consider its origin, format, language, connec

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

[Jonathan Garbee]

Let's just leave the sharing out of this. There is no data as to *why* it
is being shared. All that is is a red-herring to the technical discussion.

Web Components are what you are looking for. Problem is, JS required.
However that isn't a deal-breaker in most projects. You make a custom
element that contains within it the standard paragraphs, headers, asides,
etc. and you can feed data into that. No problem. It is *exactly* what you
are describing except it takes an extra step of making a custom component.

> 75 million Wordpress sites and 200 million Tumblr blogs out there that
treat web pages as basic documents.

There is nothing restricting these sites from implementing web components
under the hood.

> And besides, there’s still the problem of having to download huge power
inefficient Javascript libraries.

No problem with web components, they are *built into the browser.*

> ... break semantics with custom elements ...

Semantics are only broken if you implement custom elements in a bad way.
Making your own custom element just to put data into an  is doing it
incorrectly.

On Mon, Mar 23, 2015 at 8:57 AM, Bobby Mozumder 
wrote:

>
> On Mar 23, 2015, at 7:04 AM, Jonathan Garbee  wrote:
>
> The buzz mostly comes from throwing of "HTML6" into the title. HTML5 is a
> buzzword and this creates new buzz for the "next version" to act as
> click-bait for ad views. It also went viral from the mention since people
> were mocking the idea of HTML6 (and the single-page app system proposed.)
> As far as I know, HTML6 won't ever be an actual thing for any foreseeable
> time to come. HTML5 is now the "Living Standard" of HTML and will continue
> on indefinitely until it dies.
>
>
> Also, you’ll find that people share things that they like.  Editors might,
> but readers have no vested interest in click-bait.
>
> -bobby
> ---
> Bobby Mozumder
> *Editor-in-Chief*
> FutureClaw Magazine
> mozum...@futureclaw.com
> +1-240-745-5287
> www.futureclaw.com
> twitter.com/futureclaw <https://www.twitter.com/futureclaw>
> www.linkedin.com/in/mozumder
>
>

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

[Jonathan Garbee]

The buzz mostly comes from throwing of "HTML6" into the title. HTML5 is a
buzzword and this creates new buzz for the "next version" to act as
click-bait for ad views. It also went viral from the mention since people
were mocking the idea of HTML6 (and the single-page app system proposed.)
As far as I know, HTML6 won't ever be an actual thing for any foreseeable
time to come. HTML5 is now the "Living Standard" of HTML and will continue
on indefinitely until it dies.

The idea is interesting yes, however it currently ends up in a sticky
situation. You are recreating custom elements using HTML only and they
aren't as expansive. Most of the conversation I have seen around this topic
(while it is little) boils down to this as to why it isn't worth having.

Your thoughts on JS Frameworks all trying to do this and failing, is why
new standards are being made to address it. These are the pieces of web
components [1]. Once full browser support exists for these JS will have
direct power over what the frameworks are doing under the hood. With the
bonus of any frameworks using the standards creating inter-compatible
components with other technologies if they do things well enough.

For right now, the proper move isn't to get rid of JS for these actions but
let browser vendors know that developers what the web component features.

-Garbee

[1] http://webcomponents.org/

On Mon, Mar 23, 2015 at 6:11 AM, Bobby Mozumder 
wrote:

>
>
> > On Mar 23, 2015, at 5:33 AM, Nils Dagsson Moskopp <
> n...@dieweltistgarnichtso.net> wrote:
> >
> > XForms, Microdata and XSLT all do different things. Note that no widely
> > used browser supports XForms in its default configuration; while Chrome,
> > Firefox, Internet Explorer, Safari and Opera all support XSLT. Can you
> > explain the “clear usability & design issues” you have seen in XSLT?
> >
> > If so, please do.
>
> There’s no locally persistent model object. It’s not an MVC framework.
> It’s a view layer.
>
> And it’s not just me.  There’s a reason Angular, React, Ember, and so on
> don't use XSLT in trying to solve the single-page app problem, probably
> because it doesn’t have a locally persistent model object.
>
> > I certainly did not. I would like to see an implementation of your
> > proposal and several demonstrations. Do you have something on hand?
>
>
> Are you familiar with MVC design patterns?  This would be what it is.
>
> Sorry, don’t have an implementation on me.  What’s the process going
> forward?  Do people need to write a web browser for every proposal?
>
> > I agree in that buzz does not necessarily mean your proposal has merit.
>
> Did you ask the people talking about it?  What were their opinions?
>
> -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 
>
>

Re: [whatwg] Forced subtitles

[Jonathan Garbee]

I think it should be up to the developer to chose the default subtitles
they want. What if someone is trying to localize a page, and the default
subtitle is always English when they want Spanish? If not specified, the
default subtitle should be the language specified of the page or video.
But, if a specific subtitle language is told to the browser it should use
that.


On Thu, Apr 11, 2013 at 7:35 PM, Eric Carlson wrote:

>
> On Apr 11, 2013, at 3:54 PM, Silvia Pfeiffer 
> wrote:
>
> > I think Eric is right - we need a new @kind="forced" or
> @kind="forcedSubtitles" value on track elements, because they behave
> differently from the subtitle kind:
> > * are not listed in a track menu
> > * are turned on by browser when no other subtitle or caption track is on
> > * multiple forced subtitles tracks can be on at the same time (see
> discussion at https://www.w3.org/Bugs/Public/show_bug.cgi?id=21667 )
> >
> > I only wonder how the browser is meant to identify for which language it
> needs to turn on the forced subtitles. If it should depend on the language
> of the audio track of the video rather than the browser's default language
> setting, maybe it will need to be left to the server to pick which tracks
> to list and all forced tracks are on, no matter what? Did you have any
> ideas on this, Eric?
> >
>   I believe it should be the language of the video's primary audio track,
> because forced subtitles are enabled in a situation where the user can
> presumably understand the dialog being spoken in the track's language and
> has not indicated a preference for captions or subtitles.
>
> eric
>
>
> >
> > On Fri, Apr 12, 2013 at 4:08 AM, Eric Carlson 
> wrote:
> >
> >  In working with real-world content with in-band subtitle tracks, I have
> realized that the spec doesn't accommodate "forced" subtitles. Forced
> subtitles are used when a video has dialog or text in a language that is
> different from the main language. For example in the Lord of the Rings,
> dialog in Elvish is subtitled so those of us that don't speak Elvish can
> understand.
> >
> >  This is only an issue for users that do not already have
> subtitles/captions enabled, because standard caption/subitle tracks are
> expected to mix the translations into the other captions in the track. In
> other words, if I enable an English caption track I will get English
> captions for the dialog spoken in English and the dialog spoken in Elvish.
> However, users that do not typically have subtitles enabled also need to
> have the Elvish dialog translated so subtitle providers typically provide a
> second subtitle track with *only* the forced subtitles.
> >
> >   UAs are expected to automatically enable a forced-only subtitle track
> when no other caption/subtitle track is visible and there is a forced-only
> track in the same language of the primary audio track. This means that when
> I watch a version of LOTR that has been dubbed into French and I do not
> have a subtitle or caption track enabled, the UA will automatically show
> French forced subtitles if they are available.
> >
> >  Because forced subtitles are meant to be enabled automatically by the
> UA, it is essential that the UA is able to differentiate between "normal"
> and "forced" subtitles. It is also important because forced subtitles are
> not typically listed in the caption menu, again because the captions in
> them are also in the "normal" subtitles/captions.
> >
> >  I therefore propose that we add a new @kind value for forced subtitles.
> "Forced" is a widely used term in the industry, so I think "forced" is the
> appropriate value.
> >
> > eric
> >
> >
> >
>
>

Re: [whatwg] IRC and WWW integration proposal

[Jonathan Garbee]

I'll actually follow up my last post with this.

Is there any scenario where something can be done with these changes, or
any one of them, that today isn't possible with the current specifications?
I simply don't see one myself. If you could give a scenario, then could you
possibly make an example page and write a polyfill that would show the
use-case? It may help us better understand any other use-case that is
currently not possible and show us what functionality to look at in order
to create something for the (a?) spec that would work.


On Sun, Feb 17, 2013 at 4:10 PM, Jonathan Garbee  wrote:

> Usecase 1: This can already be covered by having the bot/engine look for
> an irc protocol link on the page.
>
> Usecase 2 part one: Operating systems already do this. They see an irc://
> protocol and ask what to open it with or use their already assigned option.
> No need for a browser to take this over.
>
> Usecase 2 part two: Most browsers offer extension platforms, someone can
> easily create one to look for irc:// links and display something based on
> that.
>
> I personally am not seeing any major benefit by having the proposed
> additions added into spec(s). Just more work for developers both on
> browsers and websites if they chose to support this.
>
> -Garbee
>
>
>
>>   Usecase 1: I search for python and see a link to their website in
>> search results, and the search engine looks up both title and IRC info - so
>> I see webpage title, and a link to its irc network or channel.
>>   Usecase 2: Browsers implement some interface to display IRC channel
>> link or window when user visits a page. Advantages:
>>   - The websites will benefit from this and will not have to manually
>> embed qwebirc or Mibbit instances into their webpages anymore[1], leaving
>> the IRC client preference to the user (choose from locally installed
>> clients, or a client provided by the website).
>>   - User would not have to skim a page of text to locate and click an
>> irc:// link manually, as such links would be a part of browser interface
>> (an IRC icon like RSS feed icon?).
>>
>>
>

Re: [whatwg] IRC and WWW integration proposal

[Jonathan Garbee]

Usecase 1: This can already be covered by having the bot/engine look for an
irc protocol link on the page.

Usecase 2 part one: Operating systems already do this. They see an irc://
protocol and ask what to open it with or use their already assigned option.
No need for a browser to take this over.

Usecase 2 part two: Most browsers offer extension platforms, someone can
easily create one to look for irc:// links and display something based on
that.

I personally am not seeing any major benefit by having the proposed
additions added into spec(s). Just more work for developers both on
browsers and websites if they chose to support this.

-Garbee



>   Usecase 1: I search for python and see a link to their website in search
> results, and the search engine looks up both title and IRC info - so I see
> webpage title, and a link to its irc network or channel.
>   Usecase 2: Browsers implement some interface to display IRC channel link
> or window when user visits a page. Advantages:
>   - The websites will benefit from this and will not have to manually
> embed qwebirc or Mibbit instances into their webpages anymore[1], leaving
> the IRC client preference to the user (choose from locally installed
> clients, or a client provided by the website).
>   - User would not have to skim a page of text to locate and click an
> irc:// link manually, as such links would be a part of browser interface
> (an IRC icon like RSS feed icon?).
>
>