- From: Sylvain Galineau <galineau@adobe.com>
- Date: Fri, 23 Aug 2013 16:23:51 -0700
- To: François REMY <francois.remy.dev@outlook.com>, Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
On 8/23/13 3:47 PM, "François REMY" <francois.remy.dev@outlook.com> wrote: >> Again, the main point is not that your request is not useful for >> polyfilling. What I suggest is that you shouldn't assume easier > >It's not about easier. It's about possible VS impossible. There's a >nuance. Makes no difference to the argument. Making a CSS polyfill involves several pieces, resolving what CSSStyleDeclaration.parentElement would do being one of them. CSS polyfilling would still be hard once this is exposed; if there is no other use for it then 'not very compelling' is a reasonable assessment imo. > >I've an entire file full of things I believe the web platform should >provide us, yet this is the *one* thing I decided to report because >that's the only one I had no even-somehow-ugly option to work around >properly; and it happens the spec is being rewritten at the time. Fwiw I think having to re-download stylesheets and re-parse them to find unknown properties/values makes CSS polyfilling super-ugly. Since the spec is being rewritten, we could also argue it should define a way to access features that were ignored. It's more work but I'd argue it'd save polyfill writers buckets of time and make all CSS polyfills faster and thus more usable. We also know that would be useful to build editors, for instance. Still, 'no other solution' is a fair point here. That's always much worse than 'it's hard and requires writing a lot of code'. > > > > > >> polyfilling is sufficient to make a new API worthwhile vs all the other >> things that need to get done. > >Prioritize 5 lines of code? Like... really? Yes, really. >(I know: tests, reviews, all that stuff, but in this case this is trivial >as hell, we're talking about at grand max 3x3x10min to get all browsers >on the page, and this is making the supposition that someone write a >patch for this single change only and does not batch-in other changes in >the CSSOM that will need to be done anyway). > >Sometimes, I wonder if I shouldn't just do it myself and commit patches >to the browsers directly... Most likely outcome: reviewer will you ask which spec defines the property you're adding, and then reject it if the answer is 'none yet'. > Bummer that those dev environments are incredibly hard to setup. Well, I can't recall ever working on projects that large that were easier to set up, fwiw. > > > > > >Nonetheless, if this is really the best use I can make of my time, I'll >try to find other use cases during the weekend, we'll see what comes out >of it. But, seriously, being able to access the element you're supposed >to compute the style for... The more I think about it, the more I'm >surprised this is even a debatable matter to start with. If it's so obviously useful and undebatable then why isn't it already there? Especially if, as you noted, browsers already have the info internally and the cost is minimal? Something here is not adding up. When reality contradicts theory it is usually wiser to question the theory...
Received on Friday, 23 August 2013 23:24:25 UTC