Re: [whatwg] whatwg Digest, Vol 123, Issue 25

2557-06-27 2:08 GMT+07:00, whatwg-request@lists.whatwg.org
<whatwg-request@lists.whatwg.org>:
> Send whatwg mailing list submissions to
>  whatwg@lists.whatwg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>  http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
> or, via email, send a message with subject or body 'help' to
>  whatwg-request@lists.whatwg.org
>
> You can reach the person managing the list at
>  whatwg-owner@lists.whatwg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of whatwg digest..."
>
>
> When replying to digest messages, please please PLEASE update the subject
> line so it isn't the digest subject line.
>
> Today's Topics:
>
>    1. Re: `brand-color` meta extension (Ian Hickson)
>    2. Bridging between W3C && EMCAScript (L2L 2L)
>    3. Re: brand-color meta extension (Adam Barth)
>    4. Re: brand-color meta extension (Domenic Denicola)
>    5. Re: Proposal: defining script as <link rel="script"
>       href="actualwaytoscript"> (??????? ???????)
>    6. Re: Proposal: defining script as <link rel="script"
>       href="actualwaytoscript"> (Luis Farzati)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 26 Jun 2014 18:17:21 +0000 (UTC)
> From: Ian Hickson <ian@hixie.ch>
> To: "Tab Atkins Jr." <jackalmage@gmail.com>
> Cc: WHATWG <whatwg@lists.whatwg.org>, Marcos Caceres <w3c@marcosc.com>
> Subject: Re: [whatwg] `brand-color` meta extension
> Message-ID:
>  <alpine.DEB.2.00.1406261815290.1057@ps20323.dreamhostps.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Thu, 26 Jun 2014, Tab Atkins Jr. wrote:
>> On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>> > This feature has been developed in the past under multiple proprietary
>> > names, such as "mapplication-navbutton-color" for Internet Explorer
>> > and "apple-mobile-web-app-status-bar-style" for Mobile Safari.
>> > Authors MUST NOT use the proprietary variants of this meta extension.
>> > User agents that support proprietary variants of this meta extension
>> > must, if "brand-color" is specified, use "brand-color" for these
>> > purposes, and ignore any proprietary variants.
>>
>> In another thread, Hixie asks why we don't just standardize these
>> proprietary variants.  I think "because they're horridly named" is a
>> sufficient answer, but there's a weaker proposal inside of that which
>> I think is potentially valid: should we define that
>> "msapplication-navbutton-color" and
>> "apple-mobile-web-app-status-bar-style" are required-support variants?
>>
>> This requires a bit of additional parsing work, but it's not a big deal:
>>
>> * "msapplication-navbutton-color" only allows named and hex colors.
>> * "apple-mobile-web-app-status-bar-style" appears to accept the values
>> "default", "black", and "black-translucent", which we can define as
>> meaning, respectively, that the page has no brand color, that the
>> brand color is black, or that the brand color is rgba(0,0,0,.5)
>> (spitballing here, if someone can provide the real alpha that would be
>> great).
>
> I think it would make sense to allow vendors to treat these all as
> independent values (in particular, we wouldn't want IE to be forced to
> extend their interpretation of "msapplication-TileColor" and
> "msapplication-navbutton-color" to be redundant), but I do think it would
> make sense to encourage UAs to draw colours from whichever values are
> provided, so that authors don't have to include different values for each
> browser.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 26 Jun 2014 14:26:45 -0400
> From: L2L 2L <emanuelallen@hotmail.com>
> To: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
> Subject: [whatwg] Bridging between W3C && EMCAScript
> Message-ID: <BAY402-EAS242D654414A09159DFDB80EDE180@phx.gbl>
> Content-Type: text/plain; charset="us-ascii"
>
> JavaScripture.com a bridge between W3C && EMCAScript.
>
> Please take a look, this site make it easy to navigate in W3C and
> EMCAScript.
>
> The only thing it's missing is WHATWG!
>
> ------------------------------
>
> Message: 3
> Date: Thu, 26 Jun 2014 11:42:53 -0700
> From: Adam Barth <w3c@adambarth.com>
> To: Ian Hickson <ian@hixie.ch>
> Cc: whatwg <whatwg@whatwg.org>, Tao Bai <michaelbai@google.com>
> Subject: Re: [whatwg] brand-color meta extension
> Message-ID:
>  <CAJE5ia_m-ELnGpP7X=P_LCxb+rUVV9Y92VTW6K31FVaaspe3Ew@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Jun 26, 2014 at 11:13 AM, Ian Hickson <ian@hixie.ch> wrote:
>> On Thu, 26 Jun 2014, Tao Bai wrote:
>>> The brand color is super set of them and not limited to use in the
>>> navbutton or status bar, furthermore, not all browsers have navbutton or
>>> status concept, it makes developer confused.
>>
>> I don't think it confuses authors any more, and possibly a lot less, than
>> having three ways to do essentially the same thing.
>>
>>> The "msapplication-navbutton-color" and
>>> "apple-mobile-web-app-status-bar-style" are prefix and browser specific,
>>> brand-color is general and could be standard for all browsers.
>>
>> That the keywords are prefixed is a mistake made by the relevant vendors,
>> but I don't think it should stop us from using them if they are
>> appropriate.
>>
>> Looking at those two keywords more closely, it seems that
>> "apple-mobile-web-app-status-bar-style" wouldn't work because it doesn't
>> take a CSS colour, it takes some specific keywords. However,
>> "msapplication-navbutton-color", and, maybe better,
>> "msapplication-TileColor", seem like pretty good fits to me. I don't
>> really understand why one would avoid just reusing those, either instead
>> of, or at least as well as, a newer more generic term.
>
> If I were trying evangelize the use of this feature, I wouldn't want
> to recommend that web developers use a vendor-prefixed feature.  I
> wish either Apple or Microsoft hadn't used a vendor-prefixed name, but
> they both did.
>
> Adam
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 26 Jun 2014 18:45:06 +0000
> From: Domenic Denicola <domenic@domenicdenicola.com>
> To: Tao Bai <michaelbai@google.com>, "whatwg@whatwg.org"
>  <whatwg@whatwg.org>
> Subject: Re: [whatwg] brand-color meta extension
> Message-ID: <1403808308119.99915@domenicdenicola.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I would like to reiterate that "brand-" is not a good prefix for this
> purpose. It has nothing to do with brands, and much more to do with the app
> or with system integration.
>
> ------------------------------
>
> Message: 5
> Date: Thu, 26 Jun 2014 22:57:29 +0400
> From: ??????? ??????? <marinintim@gmail.com>
> To: Boris Zbarsky <bzbarsky@MIT.EDU>
> Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
> Subject: Re: [whatwg] Proposal: defining script as <link rel="script"
>  href="actualwaytoscript">
> Message-ID: <4B9E9891-0CE4-404C-A925-10690D0FA294@gmail.com>
> Content-Type: text/plain; charset=koi8-r
>
>
>
> ?????????? ? iPhone
>
>> 26 ???? 2014 ?., ? 19:31, Boris Zbarsky <bzbarsky@MIT.EDU> ???????(?):
>>
>>> On 6/26/14, 10:39 AM, Tim Marinin wrote:
>>> If not, then why we need <link> for css, only for legacy reasons?
>>
>> Pretty much, yes.  If <style> were allowed in <head>, we could just do
>> <style src> (and in fact Gecko had support for that at one point).
>>
> Do you mean "if style src were supported"? Because otherwise I don't
> understand: a lot of sites uses inline styles in head, e.g. Jsfiddle's
> iframe.
>
> ------------------------------
>
> Message: 6
> Date: Thu, 26 Jun 2014 16:05:49 -0300
> From: Luis Farzati <lfarzati@gmail.com>
> To: ??????? ??????? <marinintim@gmail.com>
> Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Boris Zbarsky
>  <bzbarsky@mit.edu>
> Subject: Re: [whatwg] Proposal: defining script as <link rel="script"
>  href="actualwaytoscript">
> Message-ID:
>  <CAJVf_xoEqmxLpUwPHs+pKmsNCYb8f=h7cbMB8JoDY2vDSditiw@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> +1 to either <link rel="script"> much more than <style src="">.
>
>
>
>
> On Thu, Jun 26, 2014 at 3:57 PM, ??????? ??????? <marinintim@gmail.com>
> wrote:
>
>>
>>
>> ?????????? ? iPhone
>>
>> > 26 ???? 2014 ?., ? 19:31, Boris Zbarsky <bzbarsky@MIT.EDU> ???????(?):
>> >
>> >> On 6/26/14, 10:39 AM, Tim Marinin wrote:
>> >> If not, then why we need <link> for css, only for legacy reasons?
>> >
>> > Pretty much, yes.  If <style> were allowed in <head>, we could just do
>> <style src> (and in fact Gecko had support for that at one point).
>> >
>> Do you mean "if style src were supported"? Because otherwise I don't
>> understand: a lot of sites uses inline styles in head, e.g. Jsfiddle's
>> iframe.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> whatwg mailing list
> whatwg@lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
>
>
> ------------------------------
>
> End of whatwg Digest, Vol 123, Issue 25
> ***************************************
>

Received on Thursday, 26 June 2014 19:55:31 UTC