RE: [css-props-vals] First iteration of L1 spec

> You're assuming that all that is required is ordering, done by the author. 
> Multiple other domains have the exact same requirement, and are 
> causing problems right now.
> 
> One that springs to mind it requestAnimationFrame. Specifically, if the 
> things that needed to sense layout position registered first or last, then
> web pages would perform markedly better than they do (no spurious
> recalcs). Because of the nature of the web (mashups, loading 
> third-party code, etc.) this is pretty much impossible to make happen.
> 
> Why are these areas causing problems, if all that is required is a global author-provided order?

Because (in the cases you talk about) there's no way to specify an upfront global order. And no way to give the browser a "priority function" to perform the ordering on the go. No one is in control: neither the author (which cannot give global instructions to follow), nor the library authors (which have no way to find out who to collaborate with), nor the browser (which doesn't know which resources the task to schedule will require and can't try to provide some basic help).

This situation is actually the complete opposite of what I'm standing for, or so I think at least.



>> There’s a trick here. If you look at the steps I propose again, you’ll see 
>> that the registration I talk about is a DOMString registration (aka 
>> “StyleTransitionController’s types”). 
>> 
>> As such, this registration should not be done by the polyfill itself but by 
>> a script on the page that registers all the polyfills in order and at once [*]. 
>> The actual implementation is only created much later, when it’s actually 
>> needed. 
>
> So polyfills can never just register themselves? 
> And every web page requires, on every landing point, a list of polyfills that 
> need to be loaded, in the right order, declared inline (or loaded synchronously)?

Of course that's what we want! Consider the opposite case, where any third-party code can decide to register itself. That's a nightmare. Suddenly, some code will register itself for the "width" property and your other code will be refused access to the property. You are going to run into race issues because if an ads try to hook up a polyfill but is usually late and it fails, it may sometimes happen that the ads will load faster than your code and, booom, your site is now broken because you didn't handle the case where your registration fail.

Also, how do you make sure the same polyfill doesn't get registered multiple times? It's impossible. If you require upfront type registrations, you can reduce this issue by a large factor.

For what it's worth, that's how the web as worked since day one. If you use a plugin that needs jQuery, you have to include the jQuery script before that plugin script. And so on for inter-plugin dependencies. The only way to use asynchronous loading is to have your own script loader and dependencies, but you can't ask everyone to use the same polyfill loader, it's unrealistic. It will be even more so when people start to use web components.



> If you want that, it's trivial to recreate it on your own page using the current spec 
> (just monkey-patch apply). However, from my point of view this seems to be 
> making simple things hard without solving the hard cases.

Yeah, sure. And then I make sure every polyfill out there needs to provide an interface for my polyfill library (because as soon as you use one of my polyfills, no other polyfill will be able to load), and so does every other polyfill library. That's an amazing coordination story, really... People will have to choose between polyfills just because they are based on top of different libraries, or we will have to make metalibraries able to polyimplement the interfaces of all popular polyfill libraries (yuck!).  That sucks.


>> Finally, dealing with other people’s plugins is something that doesn’t
>> look much harder to me than supporting new native additions to the
>> platform. Many plugins or components you’ll find on the web today
>> assume “box-sizing: content-box” to work properly. 
>>
>> Adding any new property that affects layout will probably make it 
>> harder for polyfills to work properly; whether it’s a native property or
>> a polyfilled one doesn’t make it any different. 
>
> You're explicitly suggesting that we publish APIs through the CSSWG, 
> encourage people to use them, then break the web by releasing new
> features that cause those APIs to stop working on existing pages.
> We can't do that :)

I'm not sure I understand what you mean. I didn't make a suggestion here, just an observation. You can't ask a polyfill to be future-proof; the browsers will add new features, that's a fact, and those new features will sometime not be compatible with existing polyfills; that's a fact. Old content will not break, but new content may. That's why polyfills are not meant to last, or are bound to be continuously updated. My observation is that since this is true for browser-shipped features, I don't see why it is an issue with other-polyfills-related new features. That's it, I didn't make any suggestion out of that.



>> As you noted, if I want to animate the location of an object on the screen, 
>> I can use “transform” which transitions perfectly fine. The issue is that the 
>> “apply” hook will be run *after* transitions already took place. So, any 
>> change I’ll make to “transform” in the hook cannot possibly rely on the 
>> “transition” property to animate.
> 
> Unless the changes are themselves driven by a transition, in which case 
> everything should work fine because apply will be called on each frame.

Give this a second thought. I understand you don't like my more complex cases, but imagine simple cases like :

    #element { --border-width: 3px; --border-color: blue; transition: --border-width 3s; }
    #element:hover { --border: 5px green; }

How can I (in the apply hook of "--border") trigger a transition of "--border-width"?


> The specific use case that you talked about (moving things around in a 
> grid layout) is unworkable with just custom properties - grid layout is 
> not even computed until after style computation is well and truly 
> finished.

I didn't say "the" grid layout but more "some kind of" grid layout. I see no objection to imagine a restricted light-weight layout which can be performed at computation time by mapping a few custom properties to the position:absolute & top/left values.


> Also, polyfills will want to allow transitions from/to “auto” or “none” 
> values, which is why I believe since we have to provide the 
> “StyleTransitionController” with “from/to/currentTransitionPoint” 
> for all properties which have been updated or are transitionning.
> 
> Again, this is not currently possible with CSS for architectural reasons 
> (often because 'auto' implies 'calculate during layout').  

You think in terms of the current browser workflow. Polyfills might use other workflows which are equally fine and even better in some cases. Browsers have to be optimized to handle all possible cases, where polyfills can be used in controlled environments where assumptions that we know won't be violated allow for more features. Case in point: element queries are impossible in general-purpose css layout because of dependency cycles. If I define a subset of things you can do which makes those cycles go away, I can provide the feature.

Polyfills are about giving you options.

> When 'auto' can compute to an animatable value, compute hooks will solve this problem too.

Do you mean before "apply"? Because "apply" happens after transitions in the current model, right? That may work, but you have very few details about the element itself at that point.


>> Here’s something else I might want to do: a lightweight multiline layout 
>> with fixed-height variable-width boxes which relies on a 
>> “StyleTransitionController”, “position: absolute” and “transform” to work. 
>> Some custom properties controls the visibility state of items, and when 
>> the position of an element changes, I want to be able to initiate a transition
>> between the original location and final location of the items, following the
>> “transition” property normally % the “transform” property (so it may be 
>> ‘none’ for no transition, or ‘ease-in 3s’, or anything else). 
> 
> I don't think this is possible with custom properties alone - you really need to
> be able to hook layout to do this. Particularly, it looks like you want 'auto' to
> compute to a known pixel position - this just doesn't happen during style 
> computation.

... as of now, in a browser. I'm interested in polyfills because they will help people solve problems they face every day, not because I want to write browser code in JavaScript. I'm maybe pessimistic here, but if you don't help to solve people's problems, what's even the point of writing a polyfill API? Just to be a tool to prototype the specs in an easier way?

Trust me, I want Houdini features to land, really bad. But something that solves the second half of a quarter of the problem probably solves none of the problem in most cases.

Received on Monday, 22 June 2015 19:58:18 UTC