behavior vs content - why the distinction?

[rodneyrehm]

I'm currently fiddling with the buggyfill on Android Stock Browser 4.3 (which does not support viewport units at all). By overwriting the required callback to always return true, I could use the content hack to use viewport units on any property. (If viewport units are not supported, supportsVminmaxCalc is false, too).

This left me wondering what the distinction content and behavior was supposed to achieve in the first place. Should we not simply dumb it down to a single property (i.e. content)? Should we then replace use_content_hack: true; with a simple prefix (e.g. viewport-units-buggyfill:)?

Evaluating this property would be triggered by missing support for viewport-units in general, missing support of vmin and vmax and missing viewport-unit support in calc.

cc @zoltan-dulac

[zoltan-dulac]

Hey Rodney.

I replied to your private email about this issue, but I'll put the answer here as well: There is a small reason why you may not want to do this: IE9-10 does not support vmin/vmax, while the other browsers do. Removing the behavior hack may be a performance hit becuase of this, since you would have to use the content hack to use vmin/vmax units in IE9-10. This would work, but iOS would calculate vmin/vmax twice (once for vmin/vmax inside of regular CSS rules, and again inside the content hack CSS) unless we did some code to work optimize this (which is doable -- if the rule inside the content hack is a vmin/vmax rule, then don't implement it unless it is in a calc() expression).

If the above use-case is covered, I see no reason why not to use just content hacks and drop behavior.

I originally implemented behavior hacks behavior hacks because I originally thought I would only have to use such hacks in IE9. But then after I did this, I thought it would be cool to implement viewport units in calc formulas, and the only way to do this in iOS, that I could see was using the content hack. In retrospect, I should have just changed all the behavior hacks to content hacks and be done with it.

So -- you think it best to rip out the behavior hack and support just content ones?

Z

[zoltan-dulac]

One last question: if Android's stock browser doesn't support viewport units at all, maybe we set the hacks up this way:

1. we should only execute rules that contain vh/vw measures in content hacks only if the browser doesn't support viewport units
2. we should only execute rules that contain vmax measures for IE9-10, Safari for iOS <= 6, and browsers that don't support viewport units at all
3. we should only execute rules that contain viewport units in calc expressions if the browsers that support calc() but doesn't support viewport units in calc (we don't do this now, and I think we should ... I think this is detectable.

Note that Android Browser <= 4.3 doesn't support calc at all.

Just a thought: If you do support browsers that don't do viewport units natively, wouldn't this now be a polyfill instead of a buggyfill? I guess it only allows this with hacks turned on.

One last thing: If we get rid of behavior hacks, then may we can change the syntax of content hacks from this:

content: 'use_css_content_hack: true; font-size: 80vmax';

to this:

content: 'hack: true; font-size: 80vmax';

since it would make the hacks shorter.

Z.

[rodneyrehm]

Honestly, I don't think it's a very high penalty having a capable browser calculate vmin twice. It either gets viewport units right (Firefox, Chrome, iOS8) and nothing is done at all, or it fails some "edge-case" and we simply have it re-calculate everything in content. Figuring out what is what seems like a lot of hassle for no good reason.

I would treat content: 'viewport-units-buggyfill: property1: value1; property2: value2;'; as naively as possible - meaning what ever is in there, is dumped out to CSS. You would simply duplicate your regular CSS into this serialized form anyways:

.selector {
  width: calc(100vw - 123px);
  height: 80vmin;
  content: 'viewport-units-buggyfill: width: calc(100vw - 123px); height: 80vmin;';
}

In the end the content property serves the CSS author as a way to provide the buggyfill with the necessary data, so we don't have to include a full-blown CSS-parser.

I agree with "buggyfill" becoming a "polyfill". I'd keep the name though. Also I'd go back on having the hack(s) separated out into its own file - it kinda doesn't make sense anymore. I'd integrate them into a single file again…

I favor content: viewport-units-buggyfill: over content: hack: true; because it's unique (thus greppable).

[zoltan-dulac]

I agree with everything. One thing: would it be okay if we have a different delimiter for viewport-units-buggyfill than the colon? It seems like it should have a CSS value. Maybe:

content: 'viewport-units-buggyfill - width: calc(100vw - 123px); height: 80vmin;';

Just a small aesthetic thing in the code to make it more readable.

So ... did you want to do it, or shall I?

Z.

[rodneyrehm]

I'd go for the semi-colon: content: 'viewport-units-buggyfill; width: calc(100vw - 123px); height: 80vmin;';

If you want to try, go ahead!

[zoltan-dulac]

Hey ... got some of the work done. I'll fork the project again and send a pull request to you this weekend/early next week (I should finish it by then).

[rodneyrehm]

Hey @zoltan-dulac, I'm terribly sorry merging your PR took this long. :(
I cleaned up some stuff, fixed some more issues and pushed the changes in master to github. Please verify everything still works properly. I'll then release version 0.5.0 (instead of 0.4.2 because we introduced breaking changes)

[zoltan-dulac]

Hey Rodney.

When it rains, it pours. I am in the middle of something at the moment
(two things actually). Can I get back to you by this weekend?

Sorry
Z.

On Tue, Nov 25, 2014 at 3:17 PM, Rodney Rehm [email protected]
wrote:

Hey @zoltan-dulac https://github.com/zoltan-dulac, I'm terribly sorry
merging your PR took this long. :(
I cleaned up some stuff, fixed some more issues and pushed the changes in
master to github. Please verify everything still works properly. I'll then
release version 0.5.0 (instead of 0.4.2 because we introduced breaking
changes)

Reply to this email directly or view it on GitHub
#20 (comment)
.

Zoltan Hawryluk. Client-side web technology specialist.

e: [email protected] t: @zoltandulac
w: http://www.useragentman.com

[rodneyrehm]

… judging by the time it took me to get to your PR in the first place, I'd live with "some time next year"! (No hurry, get your stuff done first :)

[rodneyrehm]

Hey @zoltan-dulac are things looking up?

[zoltan-dulac]

Hey dude.

I was just about to call you ... I'll take a look tonight. Sorry for the
wait -- been crazy busy. Don't want this to drop to the floor.

Cheers,
Z.

On Tue, Dec 16, 2014 at 3:40 AM, Rodney Rehm [email protected]
wrote:

Hey @zoltan-dulac https://github.com/zoltan-dulac are things looking up?

Reply to this email directly or view it on GitHub
#20 (comment)
.

Zoltan Hawryluk. Client-side web technology specialist.

e: [email protected] t: @zoltandulac
w: http://www.useragentman.com

[zoltan-dulac]

Checked it out and it was all good. I did find a bug in IE11 (apparently
it still doesn't understand vmax!) so I checked in fix for that and sent
you a pull request. Once that is merged, we are all set! :-)

On Tue, Dec 16, 2014 at 9:21 AM, Zoltan Hawryluk [email protected]
wrote:

Hey dude.

I was just about to call you ... I'll take a look tonight. Sorry for
the wait -- been crazy busy. Don't want this to drop to the floor.

Cheers,
Z.

On Tue, Dec 16, 2014 at 3:40 AM, Rodney Rehm [email protected]
wrote:

Hey @zoltan-dulac https://github.com/zoltan-dulac are things looking
up?

Reply to this email directly or view it on GitHub
#20 (comment)
.

Zoltan Hawryluk. Client-side web technology specialist.

e: [email protected] t: @zoltandulac
w: http://www.useragentman.com

Zoltan Hawryluk. Client-side web technology specialist.

e: [email protected] t: @zoltandulac
w: http://www.useragentman.com

[rodneyrehm]

\o/

I'll take an older Android device home over Christmas to check if my initial goal (making viewport units available on systems that don't support it at all) also works

[zoltan-dulac]

I can check as well today (my employer has several). Pretty sure it's still
good.

Let me know if you find anything or not. Want to help if I can.
On Dec 17, 2014 3:55 AM, "Rodney Rehm" [email protected] wrote:

\o/

I'll take an older Android device home over Christmas to check if my
initial goal (making viewport units available on systems that don't support
it at all) also works

Reply to this email directly or view it on GitHub
#20 (comment)
.