Hacker News new | past | comments | ask | show | jobs | submit login

A previous solution based on explicit naming of "parts" of shadow DOMs was withdrawn several months ago. And update was given the the CSS WG last November that outlined the changes. FWIW, the "::part()" solution would have _worked_. It's entirely feasible that we could have improved the world by providing Shadow DOM with that as the primary styling mechanism. Not ideal, though. So we have been willing to change course in response to feedback.

Here's the Blink bug: https://code.google.com/p/chromium/issues/detail?id=309504

All of this happened in the open, in consultation with other vendors (not necessarily at WG meetings, which aren't where you design features anyway).

Remember the context here: Googlers have been doing the heavy lifting on this front for _years_. It's exciting that others are starting to pay attention to the problem space. That they don't think providing Shadow DOM to users is as urgent as we do is their right. We, however, are willing to take some pain in this (relatively small) instance, should they not be willing to help us work through the naming issue in short-order (which, as you can see from the thread, is the actual request; our goal is to improve things through web developers, preferably via collaboration.




The concern is shipping a non-standard solution and then encouraging developers to use it is the first step toward lock-in. No matter how much you flag something as experimental, it will be used, and the developers who built things using it will move on. When other browsers later implement the standard, nobody goes back to build it in to their projects- they're working on new projects now. This is how Firefox can support Web Audio and still not have it work on the majority of sites that use it. A differing implementation is just as bad as a prefix, and hurtful to future developers who will have to code for it to reach a compatibility matrix.


The problem is that it won't be your pain, it'll be other vendors' pain as they have to reverse engineer Blink's implementation.


The details of both the semantics and syntax in question have been widely discussed and understood. It's pure hyperbole to appeal to "reverse engineer Blink's implementation" (which, as you might be aware, is Open Source).

Here's a refresher for those who missed it: https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDb...


The fact that web developers will then need to worry about differing implementations across browsers and -- pray not -- across blink versions, on the other hand, is not hyperbole.

If it's ready to ship with nobody else agreeing on how it should work, please do everyone a favor and ship it with a prefix. If only as a courtesy to fellow developers who will need to deal with this mess. Nevermind that you don't want a prefix. Use one.

Better prefix hell than different implementations using the same syntax.


Problem is - even if something is open source, doesn't mean it will be easy to pull and implement in your code base...

Maybe cat/hat Shadow DOM depends on some C lib that causes incompatibility with a lib you use, which means you'll have integration problems.


> (which, as you might be aware, is Open Source)

Being open source has never been an excuse to break the standards process. It's disheartening to see open source being used to justify this behavior again (first with PNaCl, now this).


That's moving the goalposts. The full context of your statement was:

> it'll be other vendors' pain as they have to reverse engineer Blink's implementation

Which was the salient point I was replying to. Quoting out of context to imply I made statements I did not is...disheartening.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: