Re: [whatwg] High-density canvases
On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad wrote: > Hadn't thought of that. object-fit seems smells dangerous. I think we may > need to define explicit behaviors for renderedPixelWidth/Height for the > different object fit modes. I don't think so. Given renderedPixelWidth/Height returns the size of the content box, and the element's CSS width and height are not 'auto', then renderedPixelWidth/Height are not affected by object-fit or the intrinsic size, so there is no feedback loop. For example, with 'object-fit: contains', will the renderedPixelWidth/Height > be computed in a way to fill the element's content area, or will it > preserve the aspect ratio of the original intrinsic size? > The former. > Also, with object fit triggering a renderedsizechange event, the event > listener will presumably change the intrinsic size of the canvas, which > will invalidate style (because the object-fit computation depends on the > intrinsic size), and that causes a style invalidation feedback loop. We don't implement object-fit in Gecko yet, but when we do the change to the intrinsic size will trigger a relayout that will end up not change anything so there is no feedback loop. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 1:40 PM, Anne van Kesteren wrote: > On Thu, Jun 26, 2014 at 10:32 PM, Tab Atkins Jr. wrote: >> The spec does not suggest that it would be a simple color; it says to >> allow any CSS color. "simple color" in HTML is solely a 6-digit hex >> color. > > In that case you want the same code path uses. As well as > setting some kind of initial color so currentColor makes sense. My wording is a more specific version of what HTML currently says, and HTML should adopt something like it (rather than vaguely referring to "error-correction", which is no longer a thing). ~TJ
Re: [whatwg] brand-color meta extension
On 26 Jun 2014, at 22:37, Tab Atkins Jr. wrote: > On Thu, Jun 26, 2014 at 1:33 PM, Mathias Bynens wrote: >> On 26 Jun 2014, at 22:24, Mathias Bynens wrote: >> >>> Interesting to see this would be only the second HTML attribute value to >>> get parsed as a simple color >>> (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) >>> rather than a legacy color (the other one being `>> value=foo>`). >> >> Actually, the way it’s currently specced it wouldn’t be a parsed as a simple >> color value nor as a legacy color value. It should probably be one or the >> other (rather than introducing a third, new way to parse color values). >> https://github.com/whatwg/meta-brand-color/issues/1 > > Well, the third way is "as CSS", which already exists in the platform. Parsing a legacy color value is also “as CSS”, with some extra fallback logic in case that fails (which is currently undefined in the `brand-color` spec), and this logic is already used for the majority of HTML attributes that represent a color value.
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 10:32 PM, Tab Atkins Jr. wrote: > The spec does not suggest that it would be a simple color; it says to > allow any CSS color. "simple color" in HTML is solely a 6-digit hex > color. In that case you want the same code path uses. As well as setting some kind of initial color so currentColor makes sense. -- http://annevankesteren.nl/
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 1:33 PM, Mathias Bynens wrote: > On 26 Jun 2014, at 22:24, Mathias Bynens wrote: > >> Interesting to see this would be only the second HTML attribute value to get >> parsed as a simple color >> (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) >> rather than a legacy color (the other one being `> value=foo>`). > > Actually, the way it’s currently specced it wouldn’t be a parsed as a simple > color value nor as a legacy color value. It should probably be one or the > other (rather than introducing a third, new way to parse color values). > https://github.com/whatwg/meta-brand-color/issues/1 Well, the third way is "as CSS", which already exists in the platform. ~TJ
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 1:24 PM, Mathias Bynens wrote: > Interesting to see this would be only the second HTML attribute value to get > parsed as a simple color > (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) > rather than a legacy color (the other one being ` value=foo>`). The spec does not suggest that it would be a simple color; it says to allow any CSS color. "simple color" in HTML is solely a 6-digit hex color. ~TJ
Re: [whatwg] brand-color meta extension
On 26 Jun 2014, at 22:24, Mathias Bynens wrote: > Interesting to see this would be only the second HTML attribute value to get > parsed as a simple color > (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) > rather than a legacy color (the other one being ` value=foo>`). Actually, the way it’s currently specced it wouldn’t be a parsed as a simple color value nor as a legacy color value. It should probably be one or the other (rather than introducing a third, new way to parse color values). https://github.com/whatwg/meta-brand-color/issues/1
Re: [whatwg] brand-color meta extension
On 26 Jun 2014, at 20:45, Domenic Denicola wrote: > 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. Major +1 here, seeing as this feedback was ignored before. Just `color` is simpler and makes much more sense. Interesting to see this would be only the second HTML attribute value to get parsed as a simple color (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) rather than a legacy color (the other one being ``).
Re: [whatwg] Updated index of all HTML elements
> http://meiert.com/en/indices/html-elements/ Based on feedback from people on this list and public-html, the index now includes what appears to be the first version of HTML, irons out an inconsistency with respect to Strict and Transitional document types, and features a tiny bit more info. I recognize HTML 5 as maintained at the WHATWG as the latest and a living HTML spec and with that may or may not include HTML 5.1 in the near future. Feedback on this question is appreciated. If you need to compare HTML 5.1 today, Steve maintains a slightly different index, originally based on mine, that includes it: http://rawgit.com/w3c/elements-of-html/master/index.html/. (Apologies to those who’re subscribed to both WHATWG and W3C lists and who may see this message twice; the lists are separate on purpose, and yet this is related to both.) -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] `brand-color` meta extension
On June 26, 2014 at 2:17:22 PM, Ian Hickson (i...@hixie.ch) wrote: > > 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. I would be in favor of this. It would be good to support the legacy content as its use on the Web is significant. Search I did back in Oct 2013 found these proprietary tags appeared on something like 1% of pages in Alexa's top 78K pages (specially the msTileColor one is quite popular). I don't have the data any more, unfortunately - but could get it again if needed. The thing would be to see if it really does make sense to reuse those things in contexts where `brand-color` is to be used and not produce unexpected results. -- Marcos Caceres
Re: [whatwg] whatwg Digest, Vol 123, Issue 25
2557-06-27 2:08 GMT+07:00, whatwg-requ...@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-requ...@lists.whatwg.org > > You can reach the person managing the list at > whatwg-ow...@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 ashref="actualwaytoscript"> (??? ???) >6. Re: Proposal: defining script ashref="actualwaytoscript"> (Luis Farzati) > > > -- > > Message: 1 > Date: Thu, 26 Jun 2014 18:17:21 + (UTC) > From: Ian Hickson > To: "Tab Atkins Jr." > Cc: WHATWG , Marcos Caceres > Subject: Re: [whatwg] `brand-color` meta extension > Message-ID: > > 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. >> 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 > To: "whatwg@lists.whatwg.org" > Subject: [whatwg] Bridging between W3C && EMCAScript > Message-ID: > 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 > To: Ian Hickson > Cc: whatwg , Tao Bai > Subject: Re: [whatwg] brand-color meta extension > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Thu, Jun 26, 2014 at 11:13 AM, Ian Hickson 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 mista
Re: [whatwg] `brand-color` meta extension
On Jun 26, 2014, at 21:20, Marcos Caceres wrote: > On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: >>> Here's a first crack at a better spec: > > Moved your text here: > > https://github.com/whatwg/meta-brand-color Could we change the name to something a tad more neutral and extendable, e.g.: ua-background-color? Like that, people that use the Web for things other than brand promotion don't feel offended, and we can add ua-color once devs start requesting it while keeping consistent with CSS. --tobie
Re: [whatwg] Proposal: defining script as
On Thu, Jun 26, 2014 at 12:09 PM, Boris Zbarsky wrote: > On 6/26/14, 2:57 PM, Тимофей Маринин wrote: >> >> Do you mean "if style src were supported"? > > No, I mean what I said. But looks like
Re: [whatwg] `brand-color` meta extension
On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: > > Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color We can better capture issues, etc. there. I also updated the Wiki to point there as the "official" version. We can put the right license and allow more people to edit the document on GH (it was a read only Google doc, which is not great). I'm not volunteer to edit it :) -- Marcos Caceres
Re: [whatwg] Proposal: defining script as
On 6/26/14, 2:57 PM, Тимофей Маринин wrote: Do you mean "if style src were supported"? No, I mean what I said. But looks like
Re: [whatwg] Proposal: defining script as
+1 to either much more than
Re: [whatwg] Proposal: defining script as
Отправлено с iPhone > 26 июня 2014 г., в 19:31, Boris Zbarsky написал(а): > >> On 6/26/14, 10:39 AM, Tim Marinin wrote: >> If not, then why we need for css, only for legacy reasons? > > Pretty much, yes. If
Re: [whatwg] brand-color meta extension
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.
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 11:13 AM, Ian Hickson 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
[whatwg] Bridging between W3C && EMCAScript
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!
Re: [whatwg] `brand-color` meta extension
On Thu, 26 Jun 2014, Tab Atkins Jr. wrote: > On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Update and info!
On Thu, 26 Jun 2014, Anne van Kesteren wrote: > On Thu, Jun 26, 2014 at 7:36 PM, L2L 2L wrote: > > Could/is there [be] a mailing list that send out information on new updates > > on HTML tags, etc. and more? > > There's https://twitter.com/whatwg > > There's also a ton of GitHub repositories you can watch: > https://github.com/whatwg/ (some also have an associated Twitter > account). You can also subscribe to the spec itself to get update notifications; see the top left of the spec at: http://whatwg.org/html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] brand-color meta extension
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 10:40 AM, Chris Lilley wrote: >> Better integration of HTML and SVG (and blocking any further >> element copying beyond the four existing elements) is really >> important. > > Much more important than maintaining rendering of someone's "tried this > and it didn't do anything but I never took the tags out because they > were harmless" test page from years ago. Well, I remember one in particular was the page of some soccer club, and definitely not a test page. That said, I'm comfortable with breaking a small number of sites for this change. ~TJ
Re: [whatwg] `brand-color` meta extension
On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. 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). ~TJ
Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in
On 06/26/2014 01:18 AM, Mikko Rantalainen wrote: > However, the suggested hash signature is far from enough. Most popular > libraries have means to load additional files and plugins and the > suggested hash is able to "sign" only the main file. If you cannot > trust the CDN provider, you cannot trust that the rest of the files > have not been modified. An attacker could use *any* file in the CDN > network for an attack. If your signature cannot cover *all* files, > adding the signature is wasted effort. There's no need to provide any > additional tools for false sense of security. Couldn't the main file check any additional files it downloads, either by loading them via script tag with hash or by manually hashing them as they're downloaded (presumably easier once WebCrypto is adopted)?
Re: [whatwg] `brand-color` meta extension
On Thu, Jun 26, 2014 at 10:35 AM, Marcos Caceres wrote: > Folks at Mozilla and Google would like to standardize the `brand-color` meta > extension. The `brand-color` keyword has been added to the MetaExtensions > WHATWG wiki and a rough spec is below (prepared by some folks at Google). > > # Overview > > The browser will use this brand color when distinct color is needed, i.e. it > could be used as Web App’s title bar. > > Other browsers have similar features, but each defined as its own specific > meta tag, IE uses mapplication-navbutton-color, Safari’s is > apple-mobile-web-app-status-bar-style, they are all similar with brand-color, > but have a little different usage. > > # Syntax > > > > The content attribute can be any value defined in css color specification > http://www.w3.org/TR/css3-color/ , the value might be adjusted by browser if > it is not proper for display, i.e. extremely bright. the leading and trailing > whitespace (defined in http://www.w3.org/TR/html401/struct/text.html) is > permitted. > The brand-color meta tag must be in head element, If there are multiple > brand-color meta tags in head element, first one takes effect. > Brand color could be changed by script, browser shall respect this change. > > Relevant issues/discussions: > https://bugzilla.mozilla.org/show_bug.cgi?id=1013913 > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/IeXq74xUWzkJ Here's a first crack at a better spec: # Overview The 'brand-color' meta extension defines a suggested color that browsers and OSes displaying this page SHOULD use if they customize the display of individual pages in their UIs with varying colors. For example, a browser might color a web app's title bar with the specified 'brand-color' value, or use it as a color highlight in a task switcher. 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. # Syntax Example: The content attribute for the "brand-color" meta extension can take any valid CSS color. To find a page's brand color: 1. Let candidate elements be a list of all the "brand-color" meta elements on the page, in document order. 2. For each element in candidate elements: 1. Parse a component value from element's content attribute value. [[css-syntax]] 2. Attempt to parse the result as a CSS color. If it succeeds, return the parsed color. Note: This implies that the first successfully parsed "brand-color" meta element defines the page's "brand color". Any further "brand-color" meta elements have no effect. If "brand-color" meta elements are added or removed from the page, or have their content attribute changed, user agents MUST find the page's brand color again. When using the page's "brand color", user agents MAY adjust the color in UA-defined ways to make it more suitable for particular uses. For example, if a UA intends to use the "brand color" as a background and display white text over it, it may use a darker variant of the "brand color" for that purpose, to ensure adequate contrast. ~TJ
Re: [whatwg] brand-color meta extension
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. The "mapplication-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. - Michael On Thu, Jun 26, 2014 at 10:08 AM, Ian Hickson wrote: > On Thu, 26 Jun 2014, Tao Bai wrote: > > > > Hi, I have added brand-color meta extension in > > http://wiki.whatwg.org/wiki/MetaExtensions, and would like have your > > comment on it. Please check the detail on linked spec. > > The cited spec mentions "mapplication-navbutton-color" and > "apple-mobile-web-app-status-bar-style". Why don't we just register and > use those? > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] Update and info!
On Thu, Jun 26, 2014 at 7:36 PM, L2L 2L wrote: > Could/is there [be] a mailing list that send out information on new updates > on HTML tags, etc. and more? There's https://twitter.com/whatwg There's also a ton of GitHub repositories you can watch: https://github.com/whatwg/ (some also have an associated Twitter account). -- http://annevankesteren.nl/
[whatwg] Update and info!
Could/is there [be] a mailing list that send out information on new updates on HTML tags, etc. and more? Please tell!
[whatwg] `brand-color` meta extension
Folks at Mozilla and Google would like to standardize the `brand-color` meta extension. The `brand-color` keyword has been added to the MetaExtensions WHATWG wiki and a rough spec is below (prepared by some folks at Google). # Overview The browser will use this brand color when distinct color is needed, i.e. it could be used as Web App’s title bar. Other browsers have similar features, but each defined as its own specific meta tag, IE uses mapplication-navbutton-color, Safari’s is apple-mobile-web-app-status-bar-style, they are all similar with brand-color, but have a little different usage. # Syntax The content attribute can be any value defined in css color specification http://www.w3.org/TR/css3-color/ , the value might be adjusted by browser if it is not proper for display, i.e. extremely bright. the leading and trailing whitespace (defined in http://www.w3.org/TR/html401/struct/text.html) is permitted. The brand-color meta tag must be in head element, If there are multiple brand-color meta tags in head element, first one takes effect. Brand color could be changed by script, browser shall respect this change. Relevant issues/discussions: https://bugzilla.mozilla.org/show_bug.cgi?id=1013913 https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/IeXq74xUWzkJ Thanks! -- Marcos Caceres
Re: [whatwg] brand-color meta extension
On Thu, 26 Jun 2014, Tao Bai wrote: > > Hi, I have added brand-color meta extension in > http://wiki.whatwg.org/wiki/MetaExtensions, and would like have your > comment on it. Please check the detail on linked spec. The cited spec mentions "mapplication-navbutton-color" and "apple-mobile-web-app-status-bar-style". Why don't we just register and use those? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 6:48 PM, Tab Atkins Jr. wrote: > How many of these crazy sites were there? I'd hate to flounder on such > an important change due to just a handful of idiotically-authored > sites. Better integration of HTML and SVG (and blocking any further > element copying beyond the four existing elements) is really > important. I remember Ian showing a couple. Instrumenting Blink or Gecko probably gives you a better idea of such sites today. We could also consider making it opt-in somehow, , but that's somewhat ugly if it's only about different parsing behavior. -- http://annevankesteren.nl/
[whatwg] brand-color meta extension
Hi, I have added brand-color meta extension in http://wiki.whatwg.org/wiki/MetaExtensions, and would like have your comment on it. Please check the detail on linked spec. Best Regards - Michael
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 9:44 AM, Anne van Kesteren wrote: > On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. wrote: >> (The current proposal would place all the direct HTML children of SVG >> elements on top of each other, similar to abspos, but grandchildren >> would render normally, in a CSS layout model.) > > Isn't content outside of clipped though? Ugh, yeah, is overflow:hidden by default. How many of these crazy sites were there? I'd hate to flounder on such an important change due to just a handful of idiotically-authored sites. Better integration of HTML and SVG (and blocking any further element copying beyond the four existing elements) is really important. ~TJ
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. wrote: > (The current proposal would place all the direct HTML children of SVG > elements on top of each other, similar to abspos, but grandchildren > would render normally, in a CSS layout model.) Isn't content outside of clipped though? -- http://annevankesteren.nl/
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 9:11 AM, Ian Hickson wrote: > On Tue, 24 Jun 2014, Robert O'Callahan wrote: >> >> >> >> >> >> the elements "s" and "i" are put in the HTML namespace already. > > As siblings of the element, though, not descendants. > > This was required to get some level of compatibility with deployed content > while still allowing in HTML. There was content out there that, for > reasons that defeat me, had start tags (but not end tags). If we had > not introduced this limited trap door out of the foreign lands (it's a > hard-coded list of tag names that bail out in this way), it would have > caused the pages to be blank from the start tag to the end. That's assuming that HTML content doesn't render in SVG (or that the html tagnames are parsed as unknown SVG elements). Under the proposals for defining an SVG layout model that integrates properly with the other CSS layout models, the content would be displayed. (The current proposal would place all the direct HTML children of SVG elements on top of each other, similar to abspos, but grandchildren would render normally, in a CSS layout model.) ~TJ
Re: [whatwg] SVG cloning elements from HTML5
On Tue, 24 Jun 2014, Robert O'Callahan wrote: > > > > > > the elements "s" and "i" are put in the HTML namespace already. As siblings of the element, though, not descendants. This was required to get some level of compatibility with deployed content while still allowing in HTML. There was content out there that, for reasons that defeat me, had start tags (but not end tags). If we had not introduced this limited trap door out of the foreign lands (it's a hard-coded list of tag names that bail out in this way), it would have caused the pages to be blank from the start tag to the end. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: defining script as
On 6/26/14, 10:39 AM, Tim Marinin wrote: If not, then why we need for css, only for legacy reasons? Pretty much, yes. If
Re: [whatwg] Proposal: defining script as
2014-06-26 14:12 GMT+04:00 Anne van Kesteren : > On Thu, Jun 26, 2014 at 12:08 PM, Tim Marinin > wrote: > > I propose exact the same behaviour, as
Re: [whatwg] High-density canvases
Hadn't thought of that. object-fit seems smells dangerous. I think we may need to define explicit behaviors for renderedPixelWidth/Height for the different object fit modes. For example, with 'object-fit: contains', will the renderedPixelWidth/Height be computed in a way to fill the element's content area, or will it preserve the aspect ratio of the original intrinsic size? Etc. Also, with object fit triggering a renderedsizechange event, the event listener will presumably change the intrinsic size of the canvas, which will invalidate style (because the object-fit computation depends on the intrinsic size), and that causes a style invalidation feedback loop. If the event listener just sets the intrinsic size to renderedPixelWidth/Height, it's not so bad because the computation will stabilize after the first iteration, so we just end up with a two-pass style computation. But if there are tweaks beyond that, we could end-up in an oscillating state, and the style invalidation feedback loop that would hang the browser. -Justin On Wed, Jun 25, 2014 at 6:52 PM, Robert O'Callahan wrote: > On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan > wrote: > >> To clarify, I think a version of option #1 would be the best way to go. >> renderedPixelWidth would return the current canvas buffer width when the >> canvas element's CSS specified value for 'width' is 'auto', and similar for >> height. >> > > Actually, that would break some use-cases involving object-fit, so instead > renderedPixelWidth/Height should return the current canvas buffer width > only when *both* 'width' and 'height' are 'auto'. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w >
Re: [whatwg] Proposal: defining script as
On Thu, Jun 26, 2014 at 11:06 AM, Tim Marinin wrote: > Most often use for tag
[whatwg] Proposal: defining script as
Most often use for tag
