Re: [whatwg] metadata (and royalty reporting for some weird reason)
Hi all: * I agree with the exposure of issues Andy presents. I do sympathize with his approach, too. * getMetadata sounds reasonable to me. The choice that a final user/client of a web service, or a streaming service, can add some data sounds reasonable to me. And I am not meaning the user/client as human being here. Machine talks ( streams) to a machine using a browser based solution, being precise. * Voice is de facto the new way human beings browse the web. Humans search for things and interests out of work with her/his voices commands. These voices have and hold meta-data. And I do not mean any karaoke silly scenario, being more precise. * Concerning to all servers, radio/stations and other initial committers. * I am not pretty we should lay on them the responsibility to add or remove metadata * there was an issue, citing by memory an example, with that Soundcloud music browser based platform on the treatment of its meta-data, while streaming audio, I guess. (http://preview.tinyurl.com/issue-metadata ) _"In fact SoundCloud was initially started with the mission to be the world's largest database of sounds and it seems as if it never properly adapted their architecture"_ * The example of Soundcloud looks to me what a browser based software ( radio service or music service) offers streaming its data, and may take real advantage of any future API enhancement or the tag we are trying to improve in this written talk. * the link provided before is another solution built by two mates who are, maybe, as much experienced dealing with files as Roger is. https://www.orfium.com/press/ * I wonder , Shall not be profitable or interesting to ask those engineers, to know a bit of their browser based service solution? * Returning to the technical aspects, and according with Andy,considering a getMetadata() class is a plus Cheers --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] On 2017-04-23 20:55, Roger Hågensen wrote: > On 2017-04-23 18:58, Andy Valencia wrote: Reporting Only "artist" and "title" > are required for royalties reporting for > internet radio. > I'm sorry for a bit of topic drift on this list, and I'm sure requirements > vary by nation. I do reporting for a local station and among the > requirements I have to meet: > https://www.soundexchange.com/service-provider/reporting-requirements/ > This is the last thing I'll say on this tangent. That has nothing to do with a web browser or related standards. That type of reporting is done at the admin side of a streams server via listener/performance logs. Icecast do these, and AFAIK so can Shoutcast v2. And in any case most streaming service providers use Centovacast which has it's own performance log. A radio broadcaster can also choose (and it's probably better) to log locally in the radio software they use. There is a lot of radio software out there and even the more crappier ones let you do song logs. Also note that it is possible to pay a extra yearly fee to avoid the reporting for smaller stations. Also note that services like StreamLicensing.com do all the reporting for you it is fully automated and do Total Listener Hour calculations for you. And they do fetch stats directly from a Shoutcast v1 or v2 or KH-Icecast server, although not in an ideal way. They are for US based radio station only though and only handle the royalty reporting/paying, the rest you have to handle yourself. For Canada SoniXCast.com might be a good all in one solution (royalties/streaming/website hosting). Also you say a local station. IF you are local (is it DAB/DAB+/DRM or something else? Is it simulcast FM and Internet? Over-The-Air stations that also broadcast via the internet has to follow different rules than internet only stations. And there is no "local" station on the internet, anyone anywhere in the world can tune in. Unless it's gated behind a paywall or similar. > The Icecast/Streamcast "metastream" format is the > only technique I've ever encountered. The industry is quickly shifting > to the so-called "Shoutcast v2" format due to: > https://forums.developer.apple.com/thread/66586 Chrome had that issue (forgot which version maybe Chrome v55) but added some workaround code so old Invalid Shoutcast v1 HTTP responses will work in both Chrome and Firefox (which has a different workaround), also most streaming providers has a port 80 proxy option available which will make the stream work with Chrome 55. And never heard of StreamCast, all I see is a (dead?) project on sourceforge. If you are talking about the Shoutcast metadata then that is Shoutcast v1 only (and slightly changed for Shoutcast v2 str
Re: [whatwg] metadata
Hi Roger, hi all:
* "_passing metadata in a stream so that a HTML webplayer can show
artist and title_" can be accomplished extracting the ID3 tags from the
file and presenting them as JSON values, for example
* Sound.load(new URLRequest("07 - audio.mp3"));
* Some old tricks on the issue were done in the past. here the link of
an ECMAScript derivative from the past, if it serves you as a model ID3
tags Get/Receive [6].
But, please take in consideration:
* Not all webplayers stream music by obligation. Not all webplayers
are designed to play music.
* Sounds: Rings and bleeps of a mobile device or a computer device.
Audio meta tags should be applicable to the webplayer ( one file vs.
multiple files ).
* Streaming on the web: As I noticed to this group in my last email,
in our present days there is a growing demand for streaming by
scientific communities to publish audio conferences or talks.
* Concerning to my references WIPO et al, yes I agree , technology
should be considered neutral.
* The only important issue to consider would be the five seconds
minimum lenght.
Cheers
---
Delfi Ramirez -- At Work
My digital signature [1]
0034 633 589231
del...@segonquart.net [2]
twitter: @delfinramirez [3]
IRC: segonquart
Skype: segonquart [4]
http://segonquart.net
http://delfiramirez.info
[5]
On 2017-04-16 13:54, Roger Hågensen wrote:
> On 2017-04-16 03:01, Delfi Ramirez wrote:
>
>> * WIPO stands for _World Intellectual Property Organization_, and the
>> ...
>> * Meta-Data: Following the indications of the WIPO ( focusing on a
>> World Wide Web service ) that now, services like Pandora are not allowed
>> to stream ( are de facto banned ) in earth places like Africa, Europe,
>> or The East. May it be due to not meet the legal requirements.
>
> The reason for services like Pandora geoblocking is because the PROs are
> basically trying to carve out regions (like region blocking for DVDs and
> BlueRay), it's greedy and stupid. The EU is working on legislations to limit
> or do away with this for online stuff.
>
> Also, metadata sent to the user/listener has very little to do with royalty
> reporting. The reporting must be done by the webmaster at the webserver level
> or by the DJ at the encoding level.
> These logs are then passed independently of what the the listener see/hear.
>
> One thing that could be useful to show to the listener is a copyright hint
> like indicating if the stream is CC BY (Creative Commons Attribution) for
> example.
>
> May I also point out that this has gone very offtopic (I should probably be
> the last person to point this out though).
>
> WHATWG has very little to do with PROs/WIPO/Royalties/rights, a different
> fora should be used for that.
>
> I'd like to get back on topic and to the discussion of passing metadata in a
> stream so that a HTML webplayer can show artist and title (and maybe
> year/album if present) to the listener and have this be changed/updated when
> this info changes in the stream (usually at song change but can occur more
> often to provide special non-song messages as well).
>
> Firefox seems to support it (though I have not had the time to test it yet)
> but it is uncertain what formats it works on and if it works for streams at
> all.
>
> --
> Roger Hågensen,
> Freelancer, Norway.
Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info
[6]
http://help.adobe.com/en_US/as2/reference/flashlite/WS5b3ccc516d4fbf351e63e3d118ccf9c47f-7bc8.html
Re: [whatwg] metadata
Hi Roger, hi all:
My fault WPI, was horrendous mistake due to the keyboard, and other
thingsin mind : WIPO, I meant.
here below the info to avoid future re-works in the API and teh
tag, if it helps.
* WIPO stands for _World Intellectual Property Organization_, and the
IP acronym for them, mean _royalties. _Speaking in our technical terms,_
funding_.
* http://www.wipo.int/wipo_magazine/en/2015/02/article_0001.html
* The international legal rule is featured in the Article 15 of the
treaty :
[6]http://www.wipo.int/treaties/en/text.jsp?file_id=295578#P126_16257
Addenda:
I did not want to be rude, neither to pray for extra efforts by the team
at WHATWG. just put in common knowledge , based on my past personal (
say vane ) professional experience.
Jut three final observations to serve and to help
* Length: Five seconds MAY be the minimum legal.
* (5") Five seconds of 'stolen' / Ring sounds that are digitised audio
files/Different mixes/edits seconds/et cetera of is the minimum
for a wannabe-lawyer to go to court.. Please, keep this fact in mind.
* Meta-Data: Following the indications of the WIPO ( focusing on a
World Wide Web service ) that now, services like Pandora are not allowed
to stream ( are de facto banned ) in earth places like Africa, Europe,
or The East. May it be due to not meet the legal requirements. Because
of, sadly, streaming besides the neutrality of the technique is a unique
sales channel.
* IRSC: "_The MP3 format does allow rights management information like
ISRC to be included however it is rarely used. What is used is the ID3
system of tags, which is not part of the international standard, but
does enable ISRC to be encoded. It is therefore recommended that an ISRC
be encoded into the ID3 tag._" Uh.
* files may not just to streaming songs or bleeps, but to
scientific talks and college conferences. which may be radio live
transmitted.
* Thus, the (Title - Author) binomial proposed, in this clear need,
does not works.
just mumbling
Cheers
---
Delfi Ramirez -- At Work
My digital signature [1]
0034 633 589231
del...@segonquart.net [2]
twitter: @delfinramirez [3]
IRC: segonquart
Skype: segonquart [4]
http://segonquart.net
http://delfiramirez.info
[5]
On 2017-04-15 20:21, Roger Hågensen wrote:
> On 2017-04-15 14:00, Delfi Ramirez wrote:
>
>> Some information that may be of use, concerning to the WPI rules for
>> royalties et al in files.
>
> I have no idea what/who WPI is.
>
> But StreamLicensing.com (which has a deal with ASCAP/BMI/SESAC/SoundExchange)
> Only require artist and title, and that artist and title is viewable by the
> listener.
> One of the PROs (Performance Royalty Organization) did want album but waived
> that requirement.
>
>> Meta elements required
>>
>> * Title : 100%
>> * Artist ( Interpreter): 12%
>> * Time: lenght of the piece. Royalties are assigned by time
>> sequences.
>> * Year: (_Objective Reason: It use to happen that some__ files
>> have the same name, thus causing a mistake in the attribution to the
>> artist as it happen in the past_)
>> * Composer: 20%
>> * Arrangements: 20%
>> * Producer: 40%
>
> Artist and title is always required. But I assume that by title you the field
> itself as in it being "Some Artist - Some Song" where spacedashspace (" - ")
> is a separator for artist and title.
> As to length, any listened time longer than 30 seconds is counted, and I
> forge the max time.
> You also forgot about mentioning ISRC which is a globally unique identifier
> for tracks, radio stations may use ISRC when sending in performance logs.
>
> I'm not sure a end listener would need all this meta data though, such info
> should be logged separately by the radio station or by the streaming server
> itself.
> The listener would only be interested in (minimum) artist and title, album,
> year and artwork being a bonus. And lyrics being a nice surprise.
> Although I'd argue that artist and title (+ album and year) could be used to
> fetch artwork and lyrics using XHR upon user interaction instead.
>
> I'm not going to comment further on the royalty stuff as this is weering
> quite off-topic now.
>
> --
> Roger Hågensen,
> Freelancer, Norway.
Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info
[6] http://www.wipo.int/treaties/en/text.jsp?file_id=295578#P126_16257
Re: [whatwg] metadata
Hi All: Some information that may be of use, concerning to the WPI rules for royalties et al in files. What we know as rights. Uh, Meta elements required * Title : 100% * Artist ( Interpreter): 12% * Time: lenght of the piece. Royalties are assigned by time sequences. * Year: (_Objective Reason: It use to happen that some__ files have the same name, thus causing a mistake in the attribution to the artist as it happen in the past_) * Composer: 20% * Arrangements: 20% * Producer: 40% * Label: It depends on the contract, but as an agent collects all the rights * Software: Last but not least, some software use in the production of audio has its own rights. Uh. Hope this information it helps for the meta-tag issues _BTW . There is a new start-up company named orfium.com, which CEOs now all this issues, there is the cahnce ask them for more info._ Cheers --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] On 2017-04-15 13:46, Roger Hågensen wrote: > On 2017-04-14 22:23, Andy Valencia wrote: > >> Ok. Note that this data structure suffices to encode the baseline >> information from Shoutcast/Icecast. It does not, for instance, >> encode "Label", needed to do licensing reporting in the USA. >> "Year" is another datum often of interest. > > Only "artist" and "title" are required for royalties reporting for internet > radio. > But "album" and "year" provides additional information that helps. > Commercial radio and TV uses at minimum the artist and title, and if lucky > the listener (digital radio) and viewer get to also see album and year. > Also royalty reporting is done in a earlier stage, what a listener sees is > not what is logged/given for royalties reporting. > > Ogg (Vorbis or Opus) should in theory be easily supported as metadata is > given in a sidestream right? So is therefore independent of the audio stream. > > Mozilla has audio.mozGetMetadata() > https://developer.mozilla.org/en/docs/Web/API/HTMLMediaElement > > I have no idea if that fires once or each time more metadata is passed in the > stream. > > https://developer.mozilla.org/en-US/docs/Web/Events/loadedmetadata > Only says that it is fired when the metadata is loaded. > I'm assuming it's only at stream start though. > > So with a few "tweaks" Firefox could support Icecast Ogg metadata, if the > browser is compliant with the Ogg standard then support is very easy to add. > > Shoutcast v1 would require parsing of the audio stream, Shoutcast v2 is a > little different and can pass info like album and year and artwork. > The only Shoutcast v2 compatible player I'm aware of is the aging Winamp, the > majority of Shoutcast streams are v1 streams. > > So while Firefox almost is able to provide stream meta updates, all the other > browsers do not though and would require polyfill which as you point out has > it's own issues with having to reset the stream as the buffer fills up. > > Maybe support for enabling a large cyclic buffer could be used, triggered by > a "stream" parameter for html audio maybe. > There would still be a issue with metadata possibly being partly in the > current buffer and partly in the next buffer so any javascript would need to > splice that together. > > Ogg seems simple enough > https://www.xiph.org/ogg/doc/oggstream.html > And parsing of this metadata should be in the ogg source (libogg?) so any > browser that supports Ogg should be able to get that metadata. > > -- > Roger Hågensen, > Freelancer, Norway. Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] https://twitter.com/delfinramirez [4] skype:segonquart [5] http://delfiramirez.info
Re: [whatwg] Accessing local files with JavaScript portably and securely
Dera Patrick, Dear David , dearest all: Nowadays, there is an agreement this may become an sterile debate, if the issue is that there is no time to invest, neither and agreement on what should be done. I propose, if there is any interest on the matter we are arguing, to open a branch, and those of us who have the will, who see the need, and dispose of some spare time to invest in a possible solution ( to be presented in a future as an enhancement or a recommendation), put our hands to work. Count me in, _if there is a small group of devoted volunteers who want to extend or put his hands dirt as an __exercise,_ for file and ftp URLs [6 [6]] in the fetch spec featured in WHATWG. Sundays I'm on. Regards --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] On 2017-04-14 20:45, Patrick Dark wrote: > David Kendal 於 4/14/2017 11:58 AM 寫道: On 11 Apr 2017, at 19:50, Patrick Dark > <whatwg.at.whatwg@patrick.dark.name> wrote: > > The "world wide web" is the user-facing portion of the Internet. Files > on a CD or USB drive are not part of that. You are continuing to dodge this > problem by redefining the WHAT WG's > responsibilities. Please don't do that. > > If you can't take my word for it, how about the inventor of the > web itself? <https://gitter.im/solid/chat?at=58ed246d408f90be66aeeb30> > (Thanks to a correspondent, who I presume prefers to remain unnamed, > for sending this to me off-list.) "Appeal to authority" is a logical fallacy. An authoritative source doesn't make an argument true. I disagree with the idea that HTML files on offline media or a closed intranet are part of the "world wide web". Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] https://twitter.com/delfinramirez [4] skype:segonquart [5] http://delfiramirez.info [6] https://url.spec.whatwg.org/#concept-url
Re: [whatwg] Accessing local files with JavaScript portably and securely
Hi all: Agreed, David Thank you very uch for pointing us to the URL https://fetch.spec.whatwg.org/#basic-fetch BTW: It's not our mission to discourage users ( netters) to --ehem -- use a modern browser featured in her/his personal device for personal purposes ( as it is the exercise to access internal HTML files, linked internally or externally either to JSON data, text data --uh that old CDROMs -- or another linked HTML files -- CSS and jS comes to mind here -- ). This discouragement, seems quite the opposite as what is defined in the spec "_For now, unfortunate as it is, file and ftp URLs [6]__ are left as an exercise for the reader._" Just mumbling. Cheers. --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] On 2017-04-14 18:58, David Kendal wrote: > On 11 Apr 2017, at 19:50, Patrick Dark > <whatwg.at.whatwg@patrick.dark.name> wrote: > >> The "world wide web" is the user-facing portion of the Internet. Files >> on a CD or USB drive are not part of that. > > You are continuing to dodge this problem by redefining the WHAT WG's > responsibilities. Please don't do that. > > If you can't take my word for it, how about the inventor of the > web itself? <https://gitter.im/solid/chat?at=58ed246d408f90be66aeeb30> > (Thanks to a correspondent, who I presume prefers to remain unnamed, > for sending this to me off-list.) > > As the divinely-appointed guardians of the HTML spec, the responsibility > of the WHAT WG is to ensure that HTML is a useful platform for documents > and applications wherever HTML files can be opened from, whether that's > HTTP(S), FTP, or local files. Where 'the web' starts and stops in this > spectrum of possible protocols is of no import. > > On that note I also see that the Fetch API has stubbed out the > specification of file: and ftp: URL semantics for definition in the > future at <https://fetch.spec.whatwg.org/#basic-fetch>. > > -- > dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/ > In politics, obedience and support are the same thing. > -- Hannah Arendt Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] https://twitter.com/delfinramirez [4] skype:segonquart [5] http://delfiramirez.info [6] https://url.spec.whatwg.org/#concept-url
Re: [whatwg] Accessing local files with JavaScript portably and securely
David: Agreed. Shall we start to think on the native modern browsers, desktops ( which are integrated with the DOM, as much as I have perceived ) TouchScreen, connected to the web, and ASF or other networks (IoT comes to mind) ? A modern DOM update version of the known trick [autorun] shellexecute=path\to\htmlfile.html will be of use. Kind regards --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] On 2017-04-11 18:46, David Kendal wrote: > On 11 Apr 2017, at 17:01, Domenic Denicola <d...@domenic.me> wrote: > >> Bingo. This mailing list is for developing technology for the world >> wide web, not for peoples' local computers. > > The World Wide Web includes peoples' own computers. file:// is a URI > scheme for exactly that reason. Every browser since WorldWideWeb.app > for the NeXT has supported it, and every browser will support it > forever, I hope. (Until it gets the treatment, I suppose, > since the current generation of web standards writers seem to regard > the idea of platform stability with extreme contempt.) > > You cannot escape this simply by redefining what you consider 'the web' > to be. > > (file:// is even 'world wide', to some extent. On computers with AFS > installed, all URIs beginning with file:///afs/ will always resolve to > the exact same files.) > > -- > dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/ > If one meets a powerful person [...] one can ask five questions: what > power do you have; where did you get it; in whose interests do you > exercise it; to whom are you accountable; and, how can we get rid of > you? Anyone who cannot answer the last of those questions does not > live in a democratic system. -- Tony Benn, Commons deb., 16 Nov. 1998 Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] https://twitter.com/delfinramirez [4] skype:segonquart [5] http://delfiramirez.info
Re: [whatwg] Accessing local files with JavaScript portably and securely
Dear all: I agree with the need to consider file:// ( or at least re-consider the missing functionality) applicable to exec files / directories with HTML documents, stored on physical devices ( like USBs or CD-DVDs), even it might sound uselessness in the _cloudy_ times we live. This HTML docs MUST be viewable using a modern browser and listening to DOM events. This required or proposed functionality ACCOMPLISHES well according to standards, in the following scenarios: If the HTML document (static or don't ) links to any other docs published at the WWW, ( as it was usual in DVDs and CDs from the ages of the multimedia hype), like videos or external sites. Accessibility for earth places where you or the receiver needs to storage and view HTML content, and where a direct connection speed may not be as we know (_ It comes to mind a friend who just came back from her NGO's mission not far away from our places -- the term 'slow connection' becomes there an euphemism_ ). Just mumbling , if it means for the goals. Kind Regards ### Note on Patrick's et al: WWW is a protocol for the HTTP (S) via TCP/IP * _USB storage devices: fdisk, mkfs, mount/umount, file operations, play a DVD movie and record a DVD-R media._ * _USB keyboards and USB mice._ * _USB webcams and USB speakers._ * _USB printers, USB scanners, USB serial converters and USB Ethernet interfaces_... A GENERAL USB DEVICE SHARING SYSTEM OVER IP NETWORK ACCOMPLISH THE WWW PROTOCOL. --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] On 2017-04-11 20:50, Patrick Dark wrote: > David Kendal 於 4/11/2017 11:46 AM 寫道: On 11 Apr 2017, at 17:01, Domenic > Denicola <d...@domenic.me> wrote: > > Bingo. This mailing list is for developing technology for the world > wide web, not for peoples' local computers. The World Wide Web includes > peoples' own computers. file:// is a URI > scheme for exactly that reason. Every browser since WorldWideWeb.app > for the NeXT has supported it, and every browser will support it > forever, I hope. (Until it gets the treatment, I suppose, > since the current generation of web standards writers seem to regard > the idea of platform stability with extreme contempt.) > > You cannot escape this simply by redefining what you consider 'the web' > to be. > > (file:// is even 'world wide', to some extent. On computers with AFS > installed, all URIs beginning with file:///afs/ will always resolve to > the exact same files.) The "world wide web" is the user-facing portion of the Internet. Files on a CD or USB drive are not part of that. Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] https://twitter.com/delfinramirez [4] skype:segonquart [5] http://delfiramirez.info
Re: [whatwg] What's the element for a paragraph label?
Hi Brenson:
<_span_> works great, unfortunately, plese correct me if I am wrong,
semantics of this tag have been diminished ( see _schema.org_ for
interaction microdata literature, and doubts).
labeling, even being a common practice used by developers targeting some
modern devices in opur days, it is not 'semantic' as you well mention,
and should be always nested as a child of the_ form_ tag.
To resolve your needs, I,a s mentioned, agreed _strong _will acomplish
them.
Best
---
Delfi Ramirez -- At Work
My digital signature [1]
0034 633 589231
del...@segonquart.net [2]
twitter: @delfinramirez [3]
IRC: segonquart
Skype: segonquart [4]
http://segonquart.net
http://delfiramirez.info
[5]
On 2016-09-07 18:49, Domenic Denicola wrote:
> Hi Brenton, great to have you here.
>
> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of brenton
> strine
>
>> Is there a semantic element that can be used in a situation like this? If
>> so, I
>> propose adding "label" to the specification for that element.
>>
>> Then again, maybe this most appropriately a .
>
> The question is largely about what you're trying to accomplish. What will be
> interpreting your HTML's semantics? I can think of a few options:
>
> - If this is part of a series of labeled paragraphs, perhaps you are looking
> for dl/dt/dd
> - A heading could indeed be appropriate in some cases
> - strong is probably most generally what you are looking for. Indeed,
> https://html.spec.whatwg.org/multipage/semantics.html#the-strong-element uses
> it in the very first example ("Importance" and the "Example" paragraph after
> that).
> - If this is purely a stylistic label, span indeed makes sense.
Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info
Re: [whatwg] Galleries revisited
On 2016-07-14 18:21, Domenic Denicola wrote: >> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of >> i...@hansschmucker.de > >> _The remaining issue for me seems that the interaction between this "viewer" >> and the page is completely unspecified and that items like descriptions and >> copyright notices which may be required to make sense of an image may or may >> not be shown._ >> >> _ Also, an image may represent an item of any kind or offer actions on it >> (for example "Download the PDF", "View the subgallery", "Show related >> images", "Go to full description"), which the page may be unable to perform >> if there is no standardized way to interact with the UA._ > > I don't think the below proposal is a good way to address this. I'd suggest > creating your own library to implement the desired functionality, possibly > using microformats for the semantic aspects, and seeing if it gets adoption. > If it becomes very popular, maybe we could consider asking implementers if > they are interested in adding it to the platform, like they have done with > aspects of other popular libraries such as jQuery. But I think you are still > too quick to jump to asking implementers to implement a new element. agree --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] https://twitter.com/delfinramirez [4] skype:segonquart [5] http://delfiramirez.info
Re: [whatwg] [proposal] Gallery element
Hi Hans, et al. _IF there is consensus that this IS worth investigating, then I'd gladly help_ _write up a few proposals and sample implementations._ agree. _A gallery should be a _a series of related pictures which have a combined topic,_ _as well as an individual message.__ agree. I would suggest "a series of related _frames_". 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. agree with the assertion and the objective need of gestures: _"but with appropriate gestures in place."_ Desktop users are used to menu-less thumbnail overviews with lightboxes for full-size images, because zooming is not a huge priority Please, take in consideration, r_elated frames_ from a Gallery may concern collections of objects which are not necessarily _photos._ _Suggested: if Desktop users hold a deep knowledge or an expertise in the field of Fine Arts , these users may find zooming a priority. Consider to what it serves and for what is useful the act of zooming._ _Suggested:_ There is still in our days, both in web design as in web code, to failure to develop and treat "thumbnails" ( an object or frame) like "buttons". Pretty 1997-esque. A mistake in behaviour and DOM interaction. _A gallery should be a _a series of related pictures which have a combined topic,_ _as well as an individual message.__ agree _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__ agree _(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)._ uhm. disagree. _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)._ agree. _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.._ completely agree, refer above. Cheers --- Delfi Ramirez -- At Work My digital signature [1] 0034 633 589231 del...@segonquart.net [2] twitter: @delfinramirez [3] IRC: segonquart Skype: segonquart [4] http://segonquart.net http://delfiramirez.info [5] On 2016-07-13 14:12, 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
Re: [whatwg] JavaScript Hovers and Back Button
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] We need more colors in CSS
Not really, Alex. We have more colours now through _SYNAESTHESIA_, thanks to the tag ;) --- 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-01 21:49, Alex Vincent wrote: > I read today's thread about and I disagree - we have a higher > priority to deal with. > > We really need to replace RGB with RGBU: red, green, blue, ultraviolet. > After all, some people have cones in their eyes to detect ultraviolet > light. I believe the technical term is "tetrachromacy", or something like > that. It's the reverse of color-blindness in a sense: we're not serving > the full spectrum that some people can see! > > Pros: > * This helps women who actually can distinguish the ultraviolet colors. > * Instead of 24 bits for color (a non-standard word size in computer > science), we could use 32 bits (which is much more common in computer > programming). > * The fourth argument in the color: and background-color rules, being > ultraviolet and thus beyond the normal range of vision, becomes optional. > > Cons: > * Computer monitors aren't built to show ultraviolet colors. (Here, > though, we'd get ahead of the hardware, and let vendors catch up.) > * Ultraviolet rays from the Sun have been shown to cause skin cancers... so > medical studies would have to be done to determine a safe maximum to emit > from the monitor. The 255 level of ultraviolet should not come close to > that. > > Why not infrared, to show warmth? Because the RGB pattern goes from lower > frequencies to higher ones; to support infrared it would change to IRGB, > breaking backwards compatibility with RGB pretty badly. Sorry, romantics: > your monitors must remain, at least on the surface, very cold. Blame us in > the standards community for that. > > Alex Vincent > Hayward, CA > > -- > "The first step in confirming there is a bug in someone else's work is > confirming there are no bugs in your own." > -- Alexander J. Vincent, June 30, 2001 Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] skype:segonquart [4] http://delfiramirez.info
Re: [whatwg] New tag
Garrett et al: I really appreciate your delicate sense of humour. Not sure if all the people in the list does the same. We all know a computer-- opossite to we human beings - is unable to interpret correctly, unconciently, the information pheromones and smells have. I am speaking now like that old student of Biology Sciences who is not anymore. But you have hit the nail with your delicate sense of humour. Really. Kind regards --- 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-01 18:09, Garrett Smith wrote: > There has been good progress in HTML5 for and . > > But the tag has been missing -- why? > > Well no longer, now thanks to a new game-changing proposal: > > > But it occurred to me: This could be huge paradigm shift in towards Internet > Odorous Things. > > boolean `navigator.isSmellEnabled` > > Thank you, > -- > Garrett > Guitar Videos https://www.youtube.com/channel/UCY_uK9hur86KEuiG8s7yvWw > @xkit Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] skype:segonquart [4] http://delfiramirez.info
Re: [whatwg] Signature Link Relation for Cryptographic Resource Verification
+1 --- 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 2015-12-08 16:44, Sean B. Palmer wrote: > https://www.ietf.org/id/draft-palmer-signature-link-relation-00.txt > > -- > Sean B. Palmer Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] skype:segonquart [4] http://delfiramirez.info
Re: [whatwg] Site-Wide Heading Element
Hi all: There was mentioned logo as a descendant element of the sectioning header element, just as an idea to solve the needs of the unacurate use of the header element it seems it occurs in our daily use, with the current spec. I could imagine other semantic elements,as long as e undertand the new uses population make of websites and the web. A logo element seems reasonable to me, both in a semantical and in a structural mode. Imagine: * Representing the page in other pages or directories ( through an API that crawls, search and makes an scrutiny of the pages, brands and its referenced logos ) . Solves the exposed in nightly spec, mentioned in my last mail. * logo As a possible linked reference or representation for new gTLDs. * Linked Correspondence between the logo and the icon an app has , or a bookmark visualizes, in a mobile scenario. Think of weareables connected to web pages. * A element acting as a reference for an object, that takes the weight offto other header elements descendants like img and h1, which, in my consideration are heavily misused, due to old practices. Stop my verbosity. Thank you for taking time in reading these notes. Cheers --- Delfi Ramirez My digital signature [3] +34 633 589231 del...@segonquart.net [4] twitter: delfinramirez IRC: segonquart Skype: segonquart [5] http://segonquart.net [1] http://delfiramirez.info [2] On 2015-07-01 22:24, Pontus Horn af Rantzien 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 [1] [4] http://delfiramirez.info [2] [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-transfo rm : 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
Re: [whatwg] Site-Wide Heading Element
Pontus, you are right noticing the domain HAD or HAS nothing to do necessarily, and the idea exposed before here in this thread was just this, _an idea_. a WILL or a MIGHT. Just keep in mind these _gTLD_ are new -- we would have not imagine years ago, one will have to deal with specific domains like dev which will open new uses for the web. New IPv6, comes in mind. My observations were just annotations to what is defined in the section 4.3.7 of the living HTML5.1 spec for the element _header_. In our modern era of linked data, I just noticed there is a certain misuse, and some unresolved circumstances , for structural elements presented in a website. And the HTML spec SHOULD have to solve these inaccuracies. Of course, as it has been mentioned in this thread before, we do have structural elements like div or span that can handle well our needs of_ flowing content_. Surfing the web through a weareable, not a device, makes this requirement, expressed above, more clear._ Siri , find me the logo of the company XXX, an place it in the upper left of the page providers featured in my website_. A logo tag would be nice for the search of Siri, wouldn't be? Solution: Taking in consideration, if I am not wrong, that an HTML element is _not just a tag_, probably, an ARIA _role logo_ would accomplish these needs easily. My suggestion -- and logo was just one -- goes far from this solution, it is for a future extension of what represents a_ non-sectioning_ element like _header_,_ footer_ wrapping _sectioning_ content, like the element h1. To apply the same methods done in HTML3.1 , in our century, when we are making websites and see the rendered result in a browser, makes no sense to me.But who knows. Apologies for the verbosity Cheers --- Delfi Ramirez My digital signature [5] +34 633 589231 del...@segonquart.net [6] twitter: delfinramirez IRC: segonquart Skype: segonquart [7] http://segonquart.net [3] http://delfiramirez.info [4] On 2015-07-01 23:18, Pontus Horn af Rantzien wrote: The domain does not necessarily correspond to or have any relation to the website name. Furthermore, the domain is not necessarily readable language - how does a screen reader know how to pronounce alistapart.com [1]? It could just as well read Ali's Tap Art. You're right that it could have some security implications if presented as trustworthy, but I'd argue there are ways to hinder that as long as it's taken into account in specification. Pontus On Wed, 1 Jul 2015 at 22:31 Jonathan Zuckerman j.zucker...@gmail.com wrote: 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 [2] del...@segonquart.net [2] twitter: delfinramirez IRC: segonquart Skype: segonquart [3] http://segonquart.net [3] [4] http://delfiramirez.info [4] [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
Re: [whatwg] Site-Wide Heading Element
I agree with Gary, perfect solution. But, as I reach to understand, there is -- or there will be -- the need, as devices and uses of web pages evolve, for thinking on or considering some new descendant element tags of the ancestor header. May we extend the definition of the header element beyond_ a group of introductory or navigational aids_? The common and ordinary use that developers and publishers do of a header are , for example, to place banners, logos, asides, etcetera, which follow the behavioural pattern of the physical life Shall we do not take in consideration these use for future representations in sectioning elements? I do not see clear the presented in the nightly spec, substep 1.1 http://www.w3.org/html/wg/drafts/html/master/semantics.html#outline [1] _create AN IMPLIED HEADING and let that be the heading for the current section._ An implied heading created,with no semantic content in, does not look 'comfortable' to me. Cheers Links: -- [1] http://www.w3.org/html/wg/drafts/html/master/semantics.html#outline
Re: [whatwg] Site-Wide Heading Element
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
Re: [whatwg] Input and spell check/keyboard settings
Hello all: On language detection and allowing the device to serve your needs: lang and hreflang work well inside the data , but -- as far as I have tested it -- they do not interact with the OS language, neither the browser ( not to mention keyboards or peripherals) I guess it was Adobe, who has this _System.capanilities.language_ implementation, a ECMAScript variane, used in software for the web. Excellent, by the way. Would'nt it be nice to polyfill it ( this is, to adopt the class as a native object for devices/browsers) to implement it, not as an applet or plugin but as a standard for futures specs? Anyone here in this list from Adobe that would like to bring some light on the matter? Cheers --- 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-18 12:01, Florian Rivoal wrote: On 18 Jun 2015, at 10:58, cha...@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@opera.com: A possible solution: If we had support for setting a standardized context attribute on the input element, the browser could keep a small database with configured settings per context. There is an attribute called lang that probably has what you want, if you set up the spellcheck etc to read it. The HTML code in a web page doesn't know what the context is, until you script up something to make that happen. At which point, you may as well change the lang attribute as anything else. Note that some systems auto-detect language being entered - for example both yandex.translate and MacOS do this for me, and I suspect that the future tends that way rather than trying to guess whether I should write to you in english or norwegian... Would it make sense to add an 'auto' value to the lang attribute, explicitly instructing the UA to try and guess what language is being entered? Remembering what was used last time being a legitimate way to guess, but looking at what keyboard you're using, or at the content of what you're typing being others. UAs that don't know how to guess would be no worse off than today, but for those that do, you'd get the benefits that Jonny was talking about, plus any language dependent css being applied correctly... The mechanics of it aren't hard to polifyll, so maybe leaving it up to author provided js is good enough, but a js implementation would have access to less information to base its guess on. For instance, if you're using a typical mobile on-screen keyboard, it wouldn't know which language the keyboard is in, which provides a big clue as to what you're typing. Also, good language detection isn't that trivial, so any random author would probably have a hard time pulling this off, but that's probably not a showstopper, since nothing's stopping them form using third party libraries or services to do the job. - Florian 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
Re: [whatwg] Input and spell check/keyboard settings
Hello All:Same solution than before. I knew there a library in the spec of Adobe and its scripting languages ( a derivative of ECMA/DOM) that implemented IME as well. Like a charm. For virtual kybrds , specially. As before, It would be nice that someone at Adobe Inc. could introduce us to this possible solution . Cheers --- 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-18 13:17, Florian Rivoal wrote: On 18 Jun 2015, at 13:07, Jonny Rein Eriksen jon...@opera.com wrote: On 18.06.2015 12:01, Florian Rivoal wrote: Would it make sense to add an 'auto' value to the lang attribute, explicitly instructing the UA to try and guess what language is being entered? Remembering what was used last time being a legitimate way to guess, but looking at what keyboard you're using, or at the content of what you're typing being others. UAs that don't know how to guess would be no worse off than today, but for those that do, you'd get the benefits that Jonny was talking about, plus any language dependent css being applied correctly... The mechanics of it aren't hard to polifyll, so maybe leaving it up to author provided js is good enough, but a js implementation would have access to less information to base its guess on. For instance, if you're using a typical mobile on-screen keyboard, it wouldn't know which language the keyboard is in, which provides a big clue as to what you're typing. This is another part of the problem. There is currently no way to set which keyboard you would like to use on iOS/Android if I understand correctly. We could maybe get a standardized API which could solve this. Having support in desktop browsers first for handling spell check better would probably help in achieving this though. If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). Not sure if any spec change is needed for that. - Florian 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
Re: [whatwg] Passwords
Hi Anne, hi All: Here, in EEA I've noticed and see the same reasons that Glenn exposes, with subtle emphasis on the reasons three , four and five. Regards --- 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 2014-10-19 19:35, Glenn Maynard wrote: On Sat, Oct 18, 2014 at 2:50 PM, Anne van Kesteren ann...@annevk.nl wrote: I'd be interested in hearing why sites such as forums have not made the switch yet. If you're hosting passwords it seems downright irresponsible at this point to not use TLS. The most common reasons I've seen are: - People asking why would this page need encryption?, which is always the wrong question. (The right question is why does this page need to not have encryption?) - People don't want to jump the hoops to get a certificate and install it. I still have to search to find the right OpenSSL magic commands, and it still takes fiddling to get TLS enabled on web servers. (It should require editing two or three lines to enable it on Apache, not uncommenting dozens of lines of sample configuration then figuring out how to sync it up to your HTTP configuration. I suspect Apache can do this much more simply, and that the sample configurations that come with installations are just garbage...) - People don't want to pay for a certificate. (There's StartSSL, but when I tried it, it was so bad that I prefer to pay GoDaddy. That should say a lot given how bad *that* site is...) - They don't want the additional latency that TLS causes. I assume this is why Amazon puts most of the storefront on HTTP, and only selectively switches to HTTPS. (They've put a lot of design behind making this secure, but most authors can't do that, and it still has a big privacy cost.) This is at least a valid issue. - Some web services don't support HTTPS. (There's no excuse for this, but saying that doesn't make the problem go away. I don't recall particular examples.) 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
Re: [whatwg] getting rid of anonymizing redirects
Thank you vm, Anne Van --- Delfi Ramirez My digital signature [3] +34 633 589231 del...@segonquart.net [4] twitter: delfinramirez IRC: segonquart Skype: segonquart [5] http://segonquart.net [6] http://delfiramirez.info [7] On 2014-10-07 14:06, Anne van Kesteren wrote: On Tue, Oct 7, 2014 at 1:58 PM, Peter Lepeska bizzbys...@gmail.com wrote: Some web site developers use redirects to strip out referrer headers from requests issued from users clicking links on their site. This causes a blocking round trip and so has a really big impact on web performance. Can we give developers an alternative to this technique that will not incur a performance penalty? For instance, can linkable elements support a ³no-referrer² attribute or something similar? https://html.spec.whatwg.org/multipage/semantics.html#link-type-noreferrer [1] http://w3c.github.io/webappsec/specs/referrer-policy/ [2] Links: -- [1] https://html.spec.whatwg.org/multipage/semantics.html#link-type-noreferrer [2] http://w3c.github.io/webappsec/specs/referrer-policy/ [3] http://delfiramirez.info/public/dr_public_key.asc [4] mail:%20del...@segonquart.net [5] skype:segonquart [6] http://segonquart.net [7] http://delfiramirez.info
