Re: dynamic states and pseudo elements for inline styles

*> Second, adding the ; to the end of the style blocks is bad.  It makes>
the style blocks gratuitously different from stylesheets, and for a> pretty
weak reason - solely so that you can freely mix declaration and> blocks,
and still have all the declarations recognized in legacy> browsers.
Recommending that authors just put their plain styles first> handles this
just fine, *and* is a good idea anyway (it makes it> easier to read), and
preserves the ordinary grammar of CSS> stylesheets.*

That sounds fine to me, I had just been searching for incompatibilities and
figured that would be the best way of fitting in. But requiring them to
come last seems totally reasonable.

I can update the spec to have the {}'s removed, and can work through any
problems it may have. Can someone point me in the right direction to do
that?

Thanks


On Tue, Nov 8, 2016 at 2:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, Nov 7, 2016 at 10:52 AM, James Kyle <me@thejameskyle.com> wrote:
> > Hello
> >
> > I would like to revive this draft from 2002, which adds the following
> syntax
> > to style="...".
> >
> > <a href="http://www.w3.org/"
> >           style="{color: #900}
> >           :link {background: #ff0}
> >           :visited {background: #fff}
> >           :hover {outline: thin red solid}
> >           :active {background: #00f}">...</a>
> >
> >
> > This makes a lot of sense today due to a growing percentage of web
> > developers writing styles inline rather than in separate stylesheets.
> >
> > - https://speakerdeck.com/vjeux/react-css-in-js
> > - https://formidable.com/blog/2015/03/01/launching-radium/
> > - https://docs.angularjs.org/api/ng/directive/ngStyle
> > - https://github.com/smyte/jsxstyle
> > - https://github.com/threepointone/glamor/blob/
> master/docs/createElement.md
> >
> > However, as you can see in some of those links there has been a lot of
> > effort around making :states, ::pseudo elements, and @media queries work
> > with inline styles.
> >
> > Most of these would be solved by that proposal (minus media queries -
> which
> > are less of a concern)..
> >
> > Although I'd like to suggest the following changes:
> >
> > <a href="http://www.w3.org/"
> >           style="color: #900;
> >           :link {background: #ff0};
> >           :visited {background: #fff};
> >           :hover {outline: thin red solid};
> >           :active {background: #00f};">...</a>
> >
> >
> > - No curly { } braces around the existing inline styles - this prevents
> the
> > browsers from rendering them today
> > - A semicolon after { } blocks so that style="color: red; :hover {...};
> > text-decoration: underline; works in browsers today.
>
> I like most of this; I'll comment on some bits of it.
>
> First, removing the {} from the plain styles is good. It means the
> grammar is just an extension of the previous style='' grammar, making
> it easier to learn and to adapt existing code into.  Now, *in
> general*, we can't intermix declarations and style blocks, as they're
> grammatically ambiguous, but if we limit the selectors to solely being
> pseudoclasses (which makes sense - all the other selectors are just
> DOM qualities, which don't do anything useful when applying a style
> directly to an element), we eliminate that ambiguity.  This is the
> same thing that allows us to mix at-rules with declarations - the @ or
> : characters can't appear at the start of a declaration, so we know
> immediately what we're dealing with.
>
> Second, adding the ; to the end of the style blocks is bad.  It makes
> the style blocks gratuitously different from stylesheets, and for a
> pretty weak reason - solely so that you can freely mix declaration and
> blocks, and still have all the declarations recognized in legacy
> browsers.  Recommending that authors just put their plain styles first
> handles this just fine, *and* is a good idea anyway (it makes it
> easier to read), and preserves the ordinary grammar of CSS
> stylesheets.
>
> I wouldn't mind helping to revive this idea.
>
> ~TJ
>